A bug was filed to bugzilla.kernel.org for a quirk of some models which
ALSA BeBoB driver supports.
Bug 199365 - repeating bus resets on Firewire bus with Focusrite Saffaire 26/io
https://bugzilla.kernel.org/show_bug.cgi?id=199365
Some models (two models as long as I know) have a quirk to disappear from
IEEE 1394 bus at disconnections of packet streaming. Corresponding
character devices are removed according to 'remove' callbacks of relevant
drivers from Linux dd core. Then the models re-appear on the bus by
generating bus resets and corresponding character devices are added
according to 'probe' callbacks from Linux dd core.
In a view of ALSA applications, this looks that plug-out/plug-in occur in
a sequential order for the models when they stop playback/capture substream.
For most applications, this doesn't cause large issue. However, this quirk
is not good for combination of below modules in PulseAudio. PulseAudio
enters endless loop to detect the models and start/stop PCM substream.
- module-udev-detect
- module-alsa-card
- module-suspend-on-idle
In detail, please read my comment no.6:
https://bugzilla.kernel.org/show_bug.cgi?id=199365#c6
This commit suppressed udev detection of sound card for the issued models.
For the models, 'PULSE_IGNORE' flag is added to udev rules, then
module-udev-detect don't handle the models and PulseAudio never uses the
models automatically. In a scenario for users to load
module-alsa-card/module-alsa-sink/module-alsa-source by hand, although
these modules can still stop PCM substreams with module-suspend-on-idle,
PulseAudio never enters the endless loop because udev detection doesn't
work for the models. In this case, as long as special files for ALSA
character devices for these models are the same, corresponding sinks and
sources are available even if the voluntary plug-out/plug-in occur.
(Focusrite Saffire Pro 10 i/o with systemd 237)
$ udevadm info -q all -p /devices/pci0000:00/0000:00:07.0/fw1/fw1.0/sound/card1
P: /devices/pci0000:00/0000:00:07.0/fw1/fw1.0/sound/card1
E: DEVPATH=/devices/pci0000:00/0000:00:07.0/fw1/fw1.0/sound/card1
E: ID_BUS=firewire
E: ID_FOR_SEAT=sound-pci-0000_00_07_0
E: ID_ID=firewire-0x00130e01000606e0
E: ID_MODEL=Pro10IO
E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express]
E: ID_MODEL_ID=0x000006
E: ID_PATH=pci-0000:00:07.0
E: ID_PATH_TAG=pci-0000_00_07_0
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_INTERFACE_FROM_DATABASE=OHCI
E: ID_PCI_SUBCLASS_FROM_DATABASE=FireWire (IEEE 1394)
E: ID_SERIAL=0x00130e01000606e0
E: ID_SERIAL_SHORT=0x00130e01000606e0
E: ID_VENDOR=Focusrite
E: ID_VENDOR_FROM_DATABASE=Texas Instruments
E: ID_VENDOR_ID=0x00130e
E: SOUND_INITIALIZED=1
E: SUBSYSTEM=sound
E: SYSTEMD_WANTS=sound.target
E: TAGS=:systemd:seat:
E: USEC_INITIALIZED=957089064
(Focusrite Saffire Pro 26 i/o with systemd 237)
$ udevadm info -q all -p /devices/pci0000:00/0000:00:07.0/fw1/fw1.0/sound/card1
P: /devices/pci0000:00/0000:00:07.0/fw1/fw1.0/sound/card1
E: DEVPATH=/devices/pci0000:00/0000:00:07.0/fw1/fw1.0/sound/card1
E: ID_BUS=firewire
E: ID_FOR_SEAT=sound-pci-0000_00_07_0
E: ID_ID=firewire-0x00130e0100030cdd
E: ID_MODEL=Pro26IO
E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express]
E: ID_MODEL_ID=0x000003
E: ID_PATH=pci-0000:00:07.0
E: ID_PATH_TAG=pci-0000_00_07_0
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_INTERFACE_FROM_DATABASE=OHCI
E: ID_PCI_SUBCLASS_FROM_DATABASE=FireWire (IEEE 1394)
E: ID_SERIAL=0x00130e0100030cdd
E: ID_SERIAL_SHORT=0x00130e0100030cdd
E: ID_VENDOR=Focusrite
E: ID_VENDOR_FROM_DATABASE=Texas Instruments
E: ID_VENDOR_ID=0x00130e
E: SOUND_INITIALIZED=1
E: SUBSYSTEM=sound
E: SYSTEMD_WANTS=sound.target
E: TAGS=:systemd:seat:
E: USEC_INITIALIZED=1071026684
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
There has been a function to get supported sample rates from alsa and
an array for it in userdata of each module-alsa-sink/source. Similarly,
this patch adds a function to get supported sample formats(bit depth)
from alsa and an array for it to each userdata of the modules.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
pa_sink_get_state() and pa_source_get_state() just return the state
variable. We can as well access the state variable directly.
There are no behaviour changes, except that module-virtual-source
accessed the main thread's sink state variable from its push() callback.
I fixed the module so that it uses the thread_info.state variable
instead. Also, the compiler started to complain about comparing a sink
state variable to a source state enum value in protocol-esound.c. The
underlying bug was that a source pointer was assigned to a variable
whose type was a sink pointer (somehow using the pa_source_get_state()
macro confused the compiler enough so that it didn't complain before).
I fixed the variable type.
A bit hacky approach, but it allows to preserve LFE output position
even in reduced output modes 2.1 and 4.1.
Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
If a sound card doesn't have the "front" device defined for it, we have
to use the "hw" device for stereo. Not so long ago, the analog-stereo
mapping had "hw:%f" in its device-strings and everything worked great,
except that it caused trouble with the Intel HDMI LPE driver that uses
the first "hw" device for HDMI, and we were incorrectly detecting it as
an analog device. That problem was fixed in commit ea3ebd09, which
removed "hw:%f" from analog-stereo and added a new stereo fallback
mapping for "hw".
Now the problem is that if a sound card doesn't have the "front" device
defined for it, and it supports both mono and stereo, only the mono
mapping is used, because the stereo mapping is only a fallback. This
patch makes the mono mapping a fallback too, so the mono mapping is used
only if there's absolutely nothing else that works.
This can cause trouble at least in theory. Maybe someone actually wants
to use mono output on a card that supports both mono and stereo. But
that seems quite unlikely.
Previously, the "avoid-resampling" option of daemon.conf is to make the
daemon try to use the stream sample rate if possible for all sinks or
sources.
This patch applies this option to module-udev-detect and module-alsa-card
as a module argument in order to override the default value of daemon.conf.
As a result, user can use this argument for more fine-grained control.
e.g.) set it false in daemon.conf and set it true for module-udev-detect
or a particular module-alsa-card in default.pa.(or vice versa)
To set it, use "avoid_resampling=true or false" as the module argument.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
There are only stereo and 5.1 output modes supported natively on this
sound card, but with this config more modes like 2.1, 4.0, 4.1 and 5.0
are now exposed. Also profiles list is cleaner now with all profiles
explicitly specified.
Last thing is removed support for microphone on Linux kernels older than
4.3-rc1, which shouldn't be an issue with future version of PulseAudio
likely be installed on newer kernels anyway.
Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
When a new card shows up (during pulseaudio startup or hotplugged),
pulseaudio needs to pick the initial profile for the card. Unavailable
profiles shouldn't be picked, but module-alsa-card sometimes marked
unavailable profiles as available, causing bad initial profile choices.
This patch changes module-alsa-card so that it marks all profiles
unavailable whose all output ports or all input ports are unavailable.
Previously only those profiles were marked as unavailable whose all
ports were unavailable. For example, if a profile contains one sink and
one source, and the sink is unavailable and the source is available,
previously such profile was marked as available, but now it's marked as
unavailable.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102902
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>
The iec958 output uses device 2 and the iec958 input uses device 0. The
USB configuration in alsa doesn't set up the device numbers correctly,
which is why we need custom configuration in PulseAudio. Ideally this
would be fixed in alsa, but trying to get help for that wasn't
successful.
jack->melem can be null if the jack disappears between probing the card
and the init_jacks() call. I don't know if jacks actually ever disappear
like that (seems unlikely), but this check is in any case needed as long
as init_jacks() has proper handling for the jack disappearing case
(rather than just an assert).
There was a crash report[1] that indicated that card_suspend_changed()
called report_jack_state() with a null melem. I don't know if that was
because the jack actually disappeared, or is there some other bug too.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=104385
The commit "alsa-util: Set ALSA report_delay flag in pa_alsa_safe_delay()"
broke the build on ALSA versions below 1.1.0 because the time stamp
configuration function was introduced in 1.1.0.
This patch makes the usage of snd_pcm_status_set_audio_htstamp_config()
dependent on ALSA version.
The current code does not call snd_pcm_status_set_audio_htstamp_config()
to configure the way timestamps are updated in ALSA. In kernel 4.14 and
above a bug in ALSA has been fixed which changes timmestamp behavior.
This leads to inconsistencies in the delay reporting because the time
stamp no longer reflects the time when the delay was updated if the
ALSA report_delay flag is not set. Therefore latencies are not calculated
correctly.
This patch uses snd_pcm_status_set_audio_htstamp_config() to set the
ALSA report_delay flag to 1 before the call to snd_pcm_status(). With
this, time stamps are updated as expected.
Reconfiguration callback should also be set in case of avoiding resampling
option. This patch set the callback for every case because the callback
has already conditions to leave if it is not needed.
Also unnecessary codes of setting alternate sample rate to 0 are removed.
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
The alsa sink calls pa_sink_suspend() from the set_port() callback.
pa_sink_suspend() can only be called from the main thread, but the
set_port() callback was often called from the IO thread. That caused an
assertion to be hit in pa_sink_suspend() when switching ports.
Another issue was that pa_sink_suspend() called the set_port() callback,
and if the callback calls pa_sink_suspend() again recursively, nothing
good can be expected from that, so the thread mismatch was not the only
problem.
This patch moves the mixer syncing logic out of pa_sink/source_suspend()
to be handled internally by the alsa sink/source. This removes the
recursive pa_sink_suspend() call. This also removes the need to have the
mixer_dirty flag in pa_sink/source, so the flag and the
pa_sink/source_set_mixer_dirty() functions can be removed.
This patch also changes the threading rules of set_port(). Previously it
was called sometimes from the main thread and sometimes from the IO
thread. Now it's always called from the main thread. When deferred
volumes are used, the alsa sink and source still have to update the
mixer from the IO thread when switching ports, but the thread
synchronization is now handled internally by the alsa sink and source.
The SET_PORT messages are not needed any more and can be removed.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=104761
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
There are no behaviour changes, the code from almost all the SET_STATE
handlers is moved with minimal changes to the newly introduced
set_state_in_io_thread() callback. The only exception is module-tunnel,
which has to call pa_sink_render() after pa_sink.thread_info.state has
been updated. The set_state_in_io_thread() callback is called before
updating that variable, so moving the SET_STATE handler code to the
callback isn't possible.
The purpose of this change is to make it easier to get state change
handling right in modules. Hooking to the SET_STATE messages in modules
required care in calling pa_sink/source_process_msg() at the right time
(or not calling it at all, as was the case on resume failures), and
there were a few bugs (fixed before this patch). Now the core takes care
of ordering things correctly.
Another motivation for this change is that there was some talk about
adding a suspend_cause variable to pa_sink/source.thread_info. The
variable would be updated in the core SET_STATE handler, but that would
not work with the old design, because in case of resume failures modules
didn't call the core message handler.
build_pollfd() isn't likely to fail, but if it does, pa_sink/source_put()
will crash on an assertion failure. I haven't seen such crash happening,
this is just something that I noticed while studying the state change
code.
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
This removes the need to hardcode the ELD device index in the path
configuration. The hardcoded values don't work with the Intel HDMI LPE
driver.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
We have so far assumed that HDMI always uses device indexes 3, 7, 8, 9,
10, 11, 12 and 13. These values are hardcoded in the path configuration.
The Intel HDMI LPE driver, however, uses different device numbering
scheme. Since the indexes aren't always the same, we need to query the
hw device index from ALSA.
Later patches will use the queried index for HDMI jack detection and ELD
information reading.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
This is based on a patch by Rolo <rolo@wildfish.com> that replaced the
old ID with the new one. I deemed it better to leave the old ID in use
(I can't verify if the old ID was correct or not).
The original commit message:
Every time I reinstall or update Ubuntu I have to make this change
to get it to recognise my Native Instruments Traktor Audio 6
external soundcard.
Each time I remember the change by hunting down this forum post in
German,
https://forum.ubuntuusers.de/topic/traktor-audio-6-erkannt-aber-nicht-anwaehlbar/3/#post-8759808
(I don't speak German).
I'm not sure if the ID is just incorrect or if perhaps the hardware
identifies itself differently on slightly different models, so
perhaps we need to duplicate the line - I'm well outside of my
comfort zone here and I know barely anything about how hardware
works on Linux but figured if it helps me it would help others so I
should put it forward.
Thanks!
The Intel HDMI LPE driver works in a peculiar way when the HDMI cable is
not plugged in: any written audio is immediately discarded and underrun
is reported. That resulted in an infinite loop, because PulseAudio tried
to keep the buffer filled, which was futile since the written audio was
immediately consumed/discarded.
This patch adds special handling for the LPE driver: if the active port
of the sink is unavailable, the sink suspends itself. A new suspend
cause is added: PA_SUSPEND_UNAVAILABLE.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
Previously max_rewind was always set to the full hw buffer size, but
the actual maximum rewind amount is limited to the part of the hw buffer
that is in use.
The rewind request that was done when lowering the sink latency had to
be moved to happen before updating max_rewind.
The practical benefit of this change: When using a filter source on a
monitor source, the filter source latency is increased by max_rewind.
Without this change the max_rewind of an alsa sink is often
unnecessarily high, which leads to unnecessarily high latency with
filter sources.
Monitor sources themselves don't suffer from the latency issue, because
they use the current sink latency instead of max_rewind for the extra
buffer that they keep to deal with rewinds.
This rejigs the update_rate() logic to encompass changes to the sample
spec as a whole, as well as passthrough status. As a result,
sinks/sources provide a reconfigure() method which allows
reconfiguration as required.
The behaviour itself is currently unchanged -- alsa-sink/-source do not
actually implement anything other than rate updates for now (nor are
they ever requested to). This can be modified in the future, to allow,
for example 24-bit output when incoming media supports it, as well as
channel count changes for passthrough sinks.
Another related change is that passthrough status is now part of
sink/source reconfiguration, and we can stop doing a suspend/unsuspend
when entering/leaving passthrough state. So that part is now divided
in two -- pa_sink_reconfigure() sets the sink in passthrough mode if
required, and pa_sink_enter_passthrough() sets up everything else
(this currently means only volumes, but could disable other processing)
for passthrough mode.
This reverts commit ca63fbc1d8.
I applied the patch too hastily. force-speaker.conf is supposed to be
used only when the alsa mixer doesn't contain any elements that would
indicate the existence of a speaker port, but the reverted patch is a
workaround for a different problem. On the two affected EeePC machines
the Headphone element needs to be unmuted when using speakers. The
analog-output-speaker-always path happens to do that, but that's
unintentional. analog-output-speaker was changed[1] to mute the
headphone output when using the speaker port, and
analog-output-speaker-always should have been changed too, but that was
forgotten.
The kernel driver is buggy if it has a Headphone mixer element that
mutes both headphones and speakers, so this should be fixed in alsa. If
we end up having a workaround in PulseAudio for the broken driver, it
should be implemented with a new profile set and path configuration
files.
[1] https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=22aac4e9fdb3786178f7815a0cb2150f588b1582
Pulseaudio tries to pick the best profile (on startup or
hotplugged), the best profile is the profile with the highest
priority which isn't unavailable.
Due to the facts that iec958 ports available status always (?)
is unknown, and that it is generally more likely that a user use
hdmi than iec958, lets prioritze hdmi over iec958.
This patch shift the analog-* mappings +5 and hdmi-* mappings +5.
Some sound cards don't have any alsa-lib configuration, but they used to
work well enough up to PulseAudio 10. PulseAudio 11 stopped using "hw:0"
for the analog-stereo mapping, and instead defined it as a fallback
mapping without any mixer handling. As a result, switching between
headphones and speakers stopped working without changing the mixer
settings manually at least on Toshiba Chromebook 2. This patch adds the
mixer handling back to the fallback mapping.
I also renamed "unknown-stereo" to "stereo-fallback", because I like
that name more.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102560
to_alsa_dB() returns a result rounded to two decimal places (instead of
using integer truncation) to avoid small errors when converting between
dB and volume.
Consider playback at -22 dB (which is supported by ALSA) but results in
the higher level of -21 dB plus software attenuation.
pa_sw_volume_from_dB(-22) = 28172
pa_sw_volume_to_dB(28172) = -21.9997351
to_alsa_dB(-21.9997351) = -2199
ALSA value 106 = -2200
ALSA value 107 = -2100
...
rounding = +1 /* "accurate or first above" */
snd_mixer_selem_ask_playback_dB_vol(me, -2199, rounding, &alsa_val)
alsa_val = -2100
Signed-off-by: Ian Ray <ian.ray@ge.com>
It was reported that on a certain USB card, identified as
"0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device",
the "PCM Capture Source" element had to be set to "IEC958 In" before
the iec958 input would work.
The iec958-stereo-input.conf file didn't exist before, although the path
was referenced in the default.conf profile configuration file.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=101973
There are one headset jack on the front panel of TB16, through this
jack, we have one stereo headphone output (hw:%f,0,0) and one mono
headset-mic input (hw:%f,0,0); and there is one speaker output jack
(hw:%f,1,0) on the rear panel of TB16.
The detail information of the Dell dock TB16:
http://www.dell.com/support/article/sg/en/sgbsdt1/SLN301105
Signed-off-by: Hui Wang <hui.wang@canonical.com>
There are two reasons for this change:
1. If it is a Dell desktop machine with the realtek codec, and there
is no internal microphone on it, there is one physical audio jack
which can support headphone, headset and microphone, but this audio
jack does not have hardware capability to distinguish what is plugged
in, after users plug in a headphone and select headphone from UI
program, the headphone can't output any sound. There are many reasons
for this issue, one of them is the active_port of pa_source is set
to headphone-mic, that means the kernel audio driver will configure
this audio jack to be a microphone jack instead of headphone jack.
If we make the priority of headset-mic a bit higher than headphone-mic,
the headset-mic will be the active_port of pa_source unless users
select the headphone-mic on purpose, then this issue will be fixed.
2. Nowadays, the headset is more popular than traditional microphone,
It is highly possible that users plug in a headset instead of
microphone, it makes sense to make the headset-mic's priority higher
than headphone-mic's.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Previously, if front:x didn't work, we would try to use hw:x for analog
stereo output. There's no guarantee that hw:x is an analog output,
however. For example, the Intel HDMI LPE driver uses hw:x for HDMI
output, and PulseAudio incorrectly created analog profiles for that
card, because front:x doesn't work but hw:x does.
This patch changes things so that the analog stereo mapping doesn't any
more use hw:x as a fallback. A separate "unknown stereo" fallback
mapping is added to handle the rare case where hw:x is the only PCM
device that works.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
The reported latency of source or sink is based on measured initial conditions.
If the conditions contain an error, the estimated latency values may become negative.
This does not indicate that the latency is indeed negative but can be considered
merely an offset error. The current get_latency_in_thread() calls and the
implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
latencies because they do not make sense from a physical point of view. In fact,
the values are truncated twice, once in the message handler and a second time in
the pa_{source,sink}_get_latency_within_thread() call itself.
This leads to two problems for the latency controller within module-loopback:
- Truncating leads to discontinuities in the latency reports which then trigger
unwanted end to end latency corrections.
- If a large negative port latency offsets is set, the reported latency is always 0,
making it impossible to control the end to end latency at all.
This patch is a pre-condition for solving these problems.
It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow
negative return values. Truncating is also removed in all implementations of the
PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
original behavior is not altered in most cases. Only if a positive latency offset
is set and the message returns a negative value, the reported latency is smaller
because the values are not truncated twice.
Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
for monitor sources because the source gets the data before it is played.
If the ALSA device supports granular pointer reporting, we end up in a
situation where we write out a bunch of data, iterate, and then find a
small amount of data available in the buffer (consumed while we were
writing data into the available buffer space). We do this 10 times
before quitting the write loop.
This is inefficient in itself, but can also have wider consequences. For
example, with module-combine-sink, this will end up pushing the same
small chunks to all other devices too.
Given both of these, it just makes sense to not try to write out data
unless a minimum threshold is available. This could potentially be a
fragment, but it's likely most robust to just work with a fraction of
the total available buffer size.
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>
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
