This adds a Dockerfile to generate a Docker image with the required
dependencies on top of the standard Ubuntu 18.04 image. The Gitlab CI
then runs the PulseAudio build within this image.
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>
I looked for outdated links related to the GitLab migration. These are
the only ones I found. There were also some links to various bug
reports in the old Bugzilla, but those don't really need updating, since
Bugzilla should stay readable for a long time.
We move over helper functions to get rate, channels, channel map and
sample format (if PCM) in the public API, so users of the extended API
are more easily able to pull out these values from pa_format_info.
We can provide a better overall user experience with Bluetooth cards by
always choosing the higher audio quality profile (A2DP) by default and
updating the profile selection dynamically according to which streams
are active at a certain moment. The default initial selection has been
addressed by "85daab272 bluetooth: set better priorities for profiles"
and the dynamic profile selection is covered by module-bluetooth-policy.
In addition, module-card-restore's database entries for Bluetooth devices
are retained after a device is removed from the system, leading to the
previously selected profile being restored after a new pairing with the
same device, with no way for the user to erase this memory and reset the
default profile except manually fiddling with module-card-restore's
database.
This commit adds a module argument to have module-card-restore ignore
Bluetooth profiles and this behavior is set as default.
The internal operation_set_state function already returns early if the
new state is the same as the existing state. The attached patch extends
this to return early if already in a finalised (done/cancelled) state,
i.e. blocks attempts to re-finalise into a different state.
This helps avoid unlinking more than once (or crashing on ref count
assertion).
I was not certain whether an assertion would be a better alternative -
with such a crash helping highlight usage problems...
The situation that lead to this was the thought of someone stupidly
trying to pa_operation_cancel() a callback within the callback
execution itself, while designing a solution for a memory leak related
to cancellation within my Rust binding. While no-one should do such a
thing, if they did, they'd either trip up a ref count assertion, or the
operation would be unlinked twice, which would be bad. It's a simple
thing to catch and mitigate, and could prove to be a useful
bulletproofing measure for this function in general.
We recently changed the umask of the daemon from 022 to 077, which broke
module-pipe-sink in the system mode, because nobody was allowed to read
from the pipe.
module-pipe-source in the system mode was probably always broken,
because the old umask of 022 should prevent anyone from writing to the
pipe.
This patch uses chmod() after the file creation to set the permissions
to 0666, which is what the fkfifo() call tried to set.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=107070
Having a single level macro for stringizing LADSPA_PATH doesn't work,
because the '#' preprocessor operator doesn't expand any macros in its
parameter. As a result, we used the string "LADSPA_PATH" as the search
path, and obviously no plugins were ever found.
This adds a two-level macro in macro.h and uses that to expand and
stringize LADSPA_PATH.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=107078
Add configuration option 'stream_name' for stream/session name so user
will see it on receiver side as RTP Strean ($stream_name)
ex: load-module module-rtp-send source=rtp.monitor stream_name=MyServerMedia
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.
pa_sink_input_get_state() and pa_source_output_get_state() just return
the state variable. We can as well access the state variable directly.
There are no behaviour changes, except that some filter sources accessed
the main thread's state variable from their push() callbacks. I fixed
them so that they use the thread_info.state variable instead.
The only thing that the drained state was being used for was "pacmd
list-sink-inputs". In all other cases the drained and running states
were treated as equivalent. IMHO, this usage doesn't justify the
complexity that the additional state brings.
This patch was inspired by a bug report[1] that pointed out an error in
an if condition in pa_sink_input_set_state_within_thread(). The buggy
code is now removed altogether.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=106982
