This patch fixes the following error:
$ pacat --file-format=ogg -r test.ogg
Failed to open audio file.
$ parecord sep.flac
Failed to open audio file.
libsndfile errors out if a WAV or OGG file is set to have anything but
SF_ENDIAN_FILE:
f4d1646e5c
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/526>
For better readability, "pactl list message-handlers" is introduced which
prints a formatted output of "pactl send-message /core list-handlers".
The patch also adds the functions pa_message_params_read_raw() and
pa_message_params_read_string() for easy parsing of the message response
string. Because the functions need to modify the parameter string,
the message handler and the pa_context_string_callback function now
receive a char* instead of a const char* as parameter argument.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/51>
This was being done automatically by autotools, now we need to manually
specify this for each executable/library with a dependency in a
non-standard directory.
- Rename "pulsedspdir" to the same "padsplibdir" that Autotools uses.
- Add a new option "pulsedsp-location" that is only used for padsp.in,
just like Autotools' --with-pulsedsp-location.
- Use 'set' instead of 'set_quoted' to avoid PULSEDSP_LOCATION getting
quoted twice.
This is to avoid using the construct 'join_paths(prefix, get_option(...))'
everywhere in the meson files. It's better to settle the paths question
once and for all at the beginning.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Regarding the module:
This is unlike the autotools where liboss-util is built as a library,
here we build everything in the oss module, as apparently there's no
other consumer for liboss-util.
Regarding padsp:
Setting the install mode for padsp requires meson 0.47, so instead we
set padsp.in as executable in the git repository (which is what glib
does for gdbus-codegen btw).
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This is a working implementation of a build with meson. The server,
utils, and most modules build with this, and it is possible to run from
a build tree and play/capture audio on ALSA devices.
There are a number of FIXMEs, of course, and a number of features that
need to be enabled (modules, dependencies, installation, etc.), but this
should provide everything we need to get there relatively quickly.
To use this, install meson (distro package, or mesonbuild.com) and run:
$ cd <pulseaudio src dir>
$ meson <builddir>
$ ninja -C <builddir>
If only part of the buffer is written into stdout by stdout_callback,
the buffer_index variable is increased by the number of written bytes,
buffer_length variable is decreased while the allocated buffer size
remains the same. That suggests that the current allocated size is
calculated as (buffer_index + buffer_length). However the current
stream_read_callback implementation writes new data to the start of the
buffer and allocates too little space, so that (buffer + buffer_index +
buffer_length - 1) could actully point outside of the allocated buffer.
for example, in case HAVE_MEMFD is #undef, checking with #if HAVE_MEMFD
gives a warning (gcc 5.4.1, Ubuntu)
pulsecore/shm.c: In function 'sharedmem_create':
pulsecore/shm.c:208:5: warning: "HAVE_MEMFD" is not defined [-Wundef]
#if HAVE_MEMFD
use #ifdef or #if defined() to check for presence of a #define
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
The current build script hardcodes the $pkglibdir in the padsp command.
This works and is a reasonable default. However, distributions that
know where they install, can override this path and thus make padsp
work for any architecture that has the library installed by using the
following configure argument:
--with-pulsedsp-location='/usr/\\$$LIB/pulseaudio'
This works because ld.so considers $LIB a variable that will expand to
several location paths, depending on the architecture of the binary
being executed.
In debian, for example, this would work for libpulsedsp.so installed in
/usr/lib/x86_64-linux-gnu/ for amd64 and /usr/lib/i386-linux-gnu/ for
i386, with a single padsp command.
Current pacat code reads whatever available from STDIN and writes
it directly to the playback stream. A minimal buffer is created
for each read operation; no further reads are then allowed unless
earlier read buffer has been fully consumed by a stream write.
While quite simple, this model breaks upon the new requirements of
writing only frame-aligned data to the stream (commits #1 and #2).
The kernel read syscall can return a length much smaller than the
frame-aligned size requested, leading to invalid unaligned writes.
This can easily be reproduced by choosing a starved STDIN backend:
pacat /dev/random pa_stream_write() failed: EINVAL
echo 1234 | pacat pa_stream_write() failed: EINVAL
or by playing an incomplete WAV file in raw, non-paplay, mode.
So guard against such incomplete kernel reads by writing only in
frame-aligned sizes, while caching any trailing partial frame for
subsequent writes.
Other operation modes are not affected. Non-raw paplay playback is
handled by libsndfile, ensuring complete reads, and recording mode
just writes to the STDOUT fd without any special needs.
CommitReference #1: 22827a5e1e
CommitReference #2: 150ace90f3
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=98475
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=77595
Suggested-by: David Henningsson <diwic@ubuntu.com>
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Users reported pacat crashes when playing certain multi-channel
audio. For example:
pacat --channels=2 /dev/zero works
pacat --channels=3 /dev/zero pa_stream_write() failed: EINVAL
pacat --channels=4 /dev/zero works
pacat --channels=5 /dev/zero pa_stream_write() failed: EINVAL
pacat audio playback is pipe-like, from STDIN to PA write stream.
Meanwhile STDIN "ready to read" events got regularly triggered
before the write stream was even created, or at moments where the
stream could not accept any more audio.
In these out-of-sync cases, the write stream could not report the
appropriate buffer lengths it accepts, thus a default of 4K bytes
was chosen -- compatible by luck with some channel counts and
incompatible with others.
Instead of choosing a faulty default in these scenarios, mute the
the STDIN events until the write stream is available & queriable.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=98475
Reported-by: Tanu Kaskinen <tanuk@iki.fi>
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>