This macro compares if the given two strings, with the maximum length
of n, are equal. Useful for strings that are not NULL-terminated.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
Constants should be declared simply with "const". With struct members,
"static" means that all struct instances share the same variable, i.e.
all instances always see the same value. That's of course already
implied in the concept of "constant". Newer Vala versions don't allow
mixing "const" and "static".
In alsa-lib, snd_pcm_hw_params() internally calls snd_pcm_prepare(), thus
user space applications have no need to call snd_pcm_prepare() after calls
of snd_pcm_hw_params(). An explicit calls of snd_pcm_prepare() is expected
in a case to recover PCM substreams.
Current implementation of PulseAudio modules for ALSA playbacking/capturing
results in double calls of snd_pcm_prepare(). The second call for hw plugin
of alsa-lib executes ioctl(2) with SNDRV_PCM_IOCTL_PREPARE command in state
of SNDRV_PCM_STATE_PREPARED for the PCM substream. This has no effects to
the PCM substream as long as corresponding drivers are implemented
correctly.
This commit removes the second call for the reason.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Issue: When HFP/HSP profile is used with certain BT chipsets, the
audio sounds heavily distorted, with very slow playback full of noise.
During recording, the samples are dropped and it distorts the recorded
audio samples.
The root cause of both the issues are related to the fixed MTU sizes
in the PA stack, which is 48 bytes. Here, the BT chipset CC256x had
180 bytes MTU and it was being under-utilized and the rate at which
the samples were being accepted where not matching the expected rate,
and hence the distortion.
Solution: The appropriate solution to this problem is by reading the
MTU size of the SCO socket using getsockopts dynamically.
BugLink: http://bit.ly/2gDpGPv
BugLink: http://bit.ly/2hQsARK
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.
The autoreconf invocation below will already pick up any overrides the
user might have made to their LIBTOOLIZE variable. Overriding it here
will break on Darwin systems where libtoolize is not called glibtoolize,
and is not necessary, so just remove it.
X11 has its own bell volume setting, controlled with the "xset b"
command. If we use that volume, then the "System Sounds" slider in
pavucontrol doesn't affect the x11-bell sample volume, which in my
opinion is a bad thing. Ignoring the volume suggestion from X11 allows
module-stream-restore to apply the "event" role volume.
Any compiler flags should be set before asking the compiler to check for
thread-local storage with AX_TLS, since compiler flags (in this case
-mmacosx-version-min=10.5) can influence the outcome of that check.
* remove suggestion of '-C' due to incorrect ordering of options for
_arguments
* avoid suggesting multiple options
* add suggestion of "--", followed by executable programs
* after "--server=<hostname>" or "-s <hostname>" suggest "--"
* after "-- <program>" continue standard tab completion
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=98639
Not all VOIP applications (specially those which use alsa) set media.role to
phone. This means we need some heuristic to determinate if we want to switch
from a2dp to hsp profile based on number and types of source output (recording)
streams.
And also some people want to use their bluetooth headset (with microphone) as
their default recording device but some do not want to because of low quality.
This patch implements optional heuristic which is disabled by default. It is
disabled by default to not break experience of current pulseaudio users because
heuristic cannot be optimal. Heuristic is implemented in module-bluetooth-policy
module and decide if pulseaudio should switch to a hsp profile or not. It checks
if there is some source output with pass all these conditions:
* does not have set media.role
* does not use peak resample method (which is used by desktop volume programs)
* has assigned client/application (non virtual stream)
* does not record from monitor of sink
And if yes it switch to hsp profile.
By default this heuristic is disabled and can be enabled when loading module
module-bluetooth-policy with specifying parameter auto_switch=2
Because it is disabled by default nobody will be affected by this change unless
manually change auto_switch parameter.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
In the current RTSP implementation, there is a vulnerable window
between the RTSP object creation and the URL initialization.
If any RTSP command is issued during this period, it will lead to
crash by assertion violation.
This patch introduces pa_rtsp_exec_ready(), which returns if it is
safe to issue RTSP commands.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
Add a function performing a call to the OPTIONS request; also,
in some special cases, tuning transport parameters is required (default:
"RTP/AVP/TCP;unicast;interleaved=0-1;mode=record") ! The RAOP client for
example needs to overwrite them.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
pa_ioline_close does not free the ioline structure itself, so we
have to unref the structure if we want to free it.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
pa_socket_client_new_string() did not work as expected when an IPv6
address string like "2001:db8::1" is passed as the "name" parameter.
This is because the name parameter is then passed to pa_parse_address(),
which thinks the last colon as a separator between hostname (or address)
and a port number. To prevent pa_parse_address() from doing this, an IPv6
address must be bracketed with "[]" (e.g. "[2001:db8::1]"). [1]
This patch fixes pa_socket_client_new_string() so that it internally
adds brackets to an IPv6 address. This decision is based on a
discussion at [2].
[1]: http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-October/022010.html
[2]: http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-November/022401.html
Reviewed-by: Anton Lundin <glance@acc.umu.se>
The intuitive meaning of "missing" would be the difference between
tlength and the current queue length, and that's how memblockq-test
assumed pa_memblockq_pop_missing() to define the term "missing", but
that was an incorrect assumption, causing the last
pa_memblockq_pop_missing() return value assertion to fail.
This patch fixes the failing assertion and adds some comments about how
the "missing" and "requested" variables in memblockq work.
The function isn't used anywhere else than memblockq-test. Also, the
function is confusing, because it defines "missing" differently than
pa_memblockq_pop_missing(). pa_memblockq_missing() calculated the
missing amount like this:
missing = tlength - length,
where "length" is the current queue length. pa_memblockq_pop_missing(),
on the other hand, calculates the missing amount like this:
missing = tlength - length - requested,
where "requested" is an internal variable that keeps track of how much
the server has requested data from the client and how much of the
requests are yet to be fulfilled by the client.
memblockq-test is broken at the moment, because it assumes that
pa_memblockq_pop_missing() calculates "missing" the same way that
pa_memblockq_missing() used to calculate it. A patch for fixing that
will follow.
This reverts commit 74251f0786.
The reverted commit was not intended to make any behavioral changes, but
it broke at least the case where a client writes more data than the
server has requested.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=99211
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>
Streams are detached when they are removed or moved away from a device,
or when a filter device that they're connected to is removed or moved.
If these cases overlap, a crash will happen due to "double-detaching".
This can happen if a filter sink is removed, and a stream connected to
that filter sink removes itself when its sink goes away.
Here are the steps in more detail: When a filter sink is unloaded, first
it will unlink its own sink input. This will cause the filter sink's
input to be detached. The filter sink propagates the detachment to all
inputs connected to it using pa_sink_detach_within_thread(). After the
filter sink is done unlinking its own sink input, it will unlink the
sink. This will cause at least module-combine-sink to remove its sink
input if it had one connected to the removed filter sink. When the
combine sink removes its sink input, that input will get detached again,
and a crash follows.
We can relax the assertions a bit, and skip the detach() call if the
sink input is already detached.
I think a better fix would be to unlink the sink before the sink input
when unloading a filter sink - that way we could avoid the
double-detaching - but that would be a much more complicated change. I
decided to go with this simple fix for now.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=98617
The functions that call attach()/detach() for all streams on a sink or
source didn't update the "attached" flag accordingly. Since the flag is
only used in assertions, this omission didn't cause any harm in normal
use.
The "attached" flag is only used for asserting that the stream is in the
expected state when attaching or detaching.
Sometimes the flag was checked and updated before calling the attach or
detach callback, and sometimes after. I think it makes more sense to
always check it before calling the callback.
At the time the "unlink post" hook is fired, the stream is not any more
connected to its old device, so it makes sense to reset the sink/source
pointer to NULL before firing the hook. If this is not done, the pointer
may become stale during the "unlink post" hook, because
module-bluetooth-policy does a card profile change in its "unlink post"
callback, so even if the pointer is valid when module-bluetooth-policy's
callback is called, it will be invalid in subsequent callbacks.
In the "unlink post" hook it's not guaranteed that the stream's old
device exists any more, so let's use the "unlink" hook that is safer.
For example, module-bluetooth-policy does a card profile change in the
source-output "unlink post" hook, which invalidates the source-output's
source pointer.
When the "unlink" hook is fired, the stream is still linked to its
device, which affects the return values of the check_suspend()
functions. The unlinked streams should be ignored by the check_suspend()
functions, so I had to add extra parameters to those functions.
This fixes a crash that happens if the bluetooth headset is the only
non-monitor source in the system and the last "phone" stream dies.
When the stream dies, the native protocol calls pa_source_output_unlink()
and would call pa_source_output_unref() next, but without this patch,
things happen during the unlinking, and the unreffing ends up being
performed on a stream that is already freed.
pa_source_output_unlink() fires the "unlink" hook before doing anything
else. module-bluetooth-policy then switches the headset profile from HSP
to A2DP within that hook. The HSP source gets removed, and at this point
the dying stream is still connected to it, and needs to be rescued.
Rescuing fails, because there are no other sources in the system, so the
stream gets killed. The native protocol has a kill callback, which again
calls pa_source_output_unlink() and pa_source_output_unref(). This is
the point where the native protocol drops its own reference to the
stream, but another unref call is waiting to be executed once we return
from the original unlink call.
I first tried to avoid the double unreffing by making it safe to do
unlinking recursively, but I found out that there's code that assumes
that once unlink() returns, unlinking has actually occurred (a
reasonable assumption), and at least with my implementation this was not
guaranteed. I now think that we must avoid situations where unlinking
happens recursively. It's just too hairy to deal with. This patch moves
the bluetooth profile switch to happen at a time when the dead stream
isn't any more connected to the source, so it doesn't have to be
rescued or killed.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97906
Bug 96741 shows a case where an assertion is hit, because
pa_asyncq_new() failed due to running out of file descriptors.
pa_asyncq_new() is used in only one place (not counting the call in
asyncq-test): pa_asyncmsgq_new(). Now pa_asyncmsgq_new() can fail too,
which requires error handling in many places. One of those places is
pa_thread_mq_init(), which can now fail too, and that needs additional
error handling in many more places. Luckily there weren't any places
where adding better error handling wouldn't have been easy, so there are
many changes in this patch, but they are not complicated.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96741
pa_memblockq_push() expects all memchunks to be aligned to PCM frame
boundaries, and that means both the index and length fields of
pa_memchunk. pa_rtp_recv(), however, used a memblock for storing both
the RTP packet metadata and the actual audio data. The metadata was
"removed" from the audio data by setting the memchunk index
appropriately, so the metadata stayed in the memblock, but it was not
played back. The metadata length is not necessarily divisible by the PCM
frame size, which caused pa_memblock_push() to crash in an assertion
with some sample specs, because the memchunk index was not properly
aligned. In my tests the metadata length was 12, so it was compatible
with many configurations, but eight-channel audio didn't work.
This patch adds a separate buffer for receiving the RTP packets. As a
result, an extra memcpy is needed for moving the audio data from the
receive buffer to the memblock buffer.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96612
When unloading a module, lt_dlclose() may remove the module from memory.
If a module unloads itself, it's not safe to call lt_dlclose()
synchronously from pa_module_unload(), because the execution may return
to the module code that was removed from memory. To avoid this
situation, let's postpone lt_dlclose() until it's safe to call it.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96831
The module doesn't build any more[1], and when starting to investigate
the build failure, I asked the module author if he'd know something
about the breakage. He said that he didn't know about backward
compatibility problems with libxen, but more importantly, he said that
the module probably doesn't have any users[2]. It doesn't make sense to
keep maintaining a module that doesn't have users, so let's drop it.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=98793
[2] https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-November/027172.html
SW: Pulseaudio 8.0 / BlueZ 5.39
Symptoms:
While disconnecting/reconnecting a paired bluetooth headset (LG HBS750)
audio fails roughly on every other connection.
On a failed connection "pactl list cards" shows the bluetooth device's
card but "Active Profile: off". Issuing "pacmd set-card-profile X
a2dp_sink" makes audio work immediately.
I realized that when this happened, the previous disconnection did not
remove the card, instead it was only configured for "Active Profile:
off" but otherwise left in place.
Upon looking at PA debug logs I saw that the transport for the a2dp_sink
was first set into disconnected state and then into idle state. In
"device_connection_changed_cb()" this causes the
"pa_bluetooth_device_any_transport_connected()" return true and the
module-bluez5-device is not unloaded.
Further investigation shows that this is caused by a race of
module-bluez5-device.c:thread_func() and
MediaPoint1::ClearConfiguration().
When the FD in thread_func() is closed (POLLHUP) an
BLUETOOTH_MESSAGE_STREAM_FD_HUP message is sent into the main thread.
The handler of this message unconditionally sets the transport into IDLE
state. This is a problem if it has already been set into DISCONNECTED
state.
Executing below command will not produce any audio:
pacat --channels=3 /dev/urandom
Turns out that pa_stream_write() breaks large audio buffers into
segments of the maximum memblock size available -- a value which
is not necessarily frame aligned.
Meanwhile the server discards any non-aligned client audio, as a
security measure, due to some earlier reported daemon crashes.
Thus divide sent audio to the expected aligned form.
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
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>
