In a former commit 37358e42c4 ("alsa: Suppress udev detection of sound
card for some units on IEEE 1394 bus"), PulseAudio has udev rules to
suppress handling some units on IEEE 1394 bus for a below issue:
Bug 199365 - repeating bus resets on Firewire bus with Focusrite Saffaire 26/io
https://bugzilla.kernel.org/show_bug.cgi?id=199365
However, I found that the rules match another model; Focusrite Liquid
Saffire 56. For detail, refer to below patch for Linux sound subsystem:
[alsa-devel] [PATCH] ALSA: bebob: use more identical mod_alias for
Saffire Pro 10 I/O against Liquid Saffire 56
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/146003.html
For PulseAudio, the udev rule should be improved, because Liquid Saffire 56
(an application of TCAT TCD2200 ASIC, a.k.a Dice Jr.) can be handled by
pulseaudio without the issue.
This commit changes udev rule with model name instead of model_id from
configuration ROM. Below is data on udevd for Liquid Saffire 56, for
your information:
$ udevadm info -q all -p /sys/bus/firewire/devices/fw1.0/sound/card2/
P: /devices/pci0000:00/0000:00:01.2/0000:03:00.2/0000:04:07.0/0000:0a:00.0/0000:0b:00.0/fw1/fw1.0/sound/card2
E: DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:03:00.2/0000:04:07.0/0000:0a:00.0/0000:0b:00.0/fw1/fw1.0/sound/card2
E: ID_BUS=firewire
E: ID_FOR_SEAT=sound-pci-0000_0b_00_0
E: ID_ID=firewire-0x00130e04018001e9
E: ID_MODEL=LIQUID_SAFFIRE_56
E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express]
E: ID_MODEL_ID=0x000006
E: ID_PATH=pci-0000:0b:00.0
E: ID_PATH_TAG=pci-0000_0b_00_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=0x00130e04018001e9
E: ID_SERIAL_SHORT=0x00130e04018001e9
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:
E: USEC_INITIALIZED=9802422583
Fixes: 37358e42c4 ("alsa: Suppress udev detection of sound card for some units on IEEE 1394 bus")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Similar to module-tunnel-sink-new, module-virtual-source did not create
a rtpoll for the uplink sink. This lead to a crash when the uplink sink
was used by module loopback, because module-loopback relies on the sink
to provide a rtpoll. Additionally, the sink was not unlinked when the
module was unloaded.
This patch fixes both issues. The rtpoll created is never run by the sink,
so the patch is no real fix but just a workaround to make module-loopback
happy.
If one device tries to use PulseAudio to send audio over A2DP to another
device with bluez-alsa, that doesn't work because PulseAudio uses an
incorrect RTP payload type and bluez-alsa checks that the RTP payload
type is correct. According to the A2DP spec, the payload type should be
set to a number between 96 and 127.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/591
I can't promise that the logic is *exactly* the same as the logic
currently in use with the autotools, but it seems correct to me.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
If `x11-xcb` is found, then let's force other X11 dependencies to be
there as well. That makes things a bit easier, and that's also what is
done in the autotools build system.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
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>
Before this commit ucm_port_contains() was using a strncmp to compare
UCM-device-names without first checking that the part of the port_name
being compared and the device-name have the same length, this was causing
it to return true for both "InternalMic-IN1" and "InternalMic-IN12" when
port_name contained "InternalMic-IN1".
We hit this with the bytcr_rt5651 UCM profile which has "InternalMic-IN1",
"InternalMic-IN2" and "InternalMic-IN12" devices, for devices with their
internal mic connected to IN1, or IN2, or using stereo internal mics
connected to both. This problem resulted in various problems including
the RECMIXL? BST2 switch getting turned on when selecting only
"InternalMic-IN1", as well as confusing the gnome-control-center sound
panel, which could not figure out which device is selected in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The previous commit introduces logic in module-switch-on-port-available
that may change a card's active profile when its availability changes to
PA_AVAILABLE_NO. To choose the new active profile, it needs a consistent
view of the new availability of all profiles, so this commit changes the
order which the ALSA driver updates all profiles' availability to ensure
the active profile is last.
This is not generic enough to cover cases were we may want to take an
action on availability changes of profiles other than the active one
that also need a consistent view of all profiles' availability. But we
don't have any callbacks implementing such action at the moment.
When a port becomes unavailble its profile may also become unavailable.
If that profile is the card's active profile, we need to switch the
card's active profile to a different one.
If we don't do that a card may get stuck on a profile without available
ports, but its sink and source will still exist, preventing
module-rescue-streams to move the streams to a different card with
available ports.
The relation between port availability and profile availability is
defined by the driver, and for the ALSA driver a profile is considered
available if there is at least one (available || unknown) port for each
direction implemented by the profile. Because of that we can only check
the profile's availability and priority when looking for the best
profile and don't need to look at port's priorities.
https://phabricator.endlessm.com/T24904
It is helpful to improve reproducibility build [1] since
PA_SRCDIR/PA_BUILDDIR contains build path,
--disable-running-from-build-tree could drop these macros at
precompilation.
[1] https://reproducible-builds.org/
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
HDMI ports are normally present on cards connected to an internal bus,
and module-switch-on-connect should switch to them when a HDMI monitor
is plugged.
This is specially relevant on setups where the HDMI port of a machine is
connected to a different audio card then the analog outputs, which is
the case for machines with AMD graphics cards.
When reviewing another change in rsa_encrypt(), Felipe Sateler pointed
out some deficiencies in error handling. This patch adds error handling
for all openssl calls in rsa_encrypt().
This patch doesn't propagate the error all the way up to the
pa_rtsp_client owner, because there's no mechanism for doing that. I
could implement such mechanism myself, but I think it's better I don't
make such complex changes to the RAOP code, because I don't have any
RAOP hardware to test the changes. The result is that module-raop-sink
will just sit around without doing anything. I think this is still
better than having no error handling at all.
Sample format(e.g. 16 bit, 24 bit) was not considered even if the
avoid-resampling option is set or the passthrough mode is used.
This patch checks both sample format and rate of a stream to
determine whether to avoid resampling in case of the option is set.
In other word, it is possble to use the stream's original sample
format and rate without resampling as long as these are supported
by the device.
pa_sink_input_update_rate() and pa_source_output_update_rate() are
renamed to pa_sink_input_update_resampler() and pa_source_output
_update_resampler() respectively.
functions are added as below.
pa_sink_set_sample_format(), pa_sink_set_sample_rate(),
pa_source_set_sample_format(), pa_source_set_sample_rate()
Signed-off-by: Sangchul Lee <sc11.lee@samsung.com>
Headphones should have higher priority than lineout. Many people have
speakers always connected to lineout, and when plugging in headphones,
the audio should move to the headphones, which requires headphones
to have higher priority than lineout.
Previously this was handled by marking lineout unavailable when plugging
in headphones, but we don't do that any more.
This reverts commit 66f97c35bd. The commit
message was:
alsa-mixer: Disable line-out if headphone jack is plugged
Line-out gets muted when headphones are plugged in on HDA cards, encode
this in the line-out path so pulse can match that state.
I don't think the mentioned auto-muting happens any more by default,
and some users want to use lineout while having headphones plugged in.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/583
webrtc.cc:202:19: warning: comparison of integer expressions of different signedness:
'int' and 'std::vector<webrtc::CartesianPoint<float> >::size_type' {aka 'long unsigned int'}
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>
Please notice that the bluez5 version seems wrong in the dependency
declaration: `>= 4.x`, while we're talking about version 5.
The ofono part will need to be made optional when we start to work on
the meson_options file.
I follow the current configure.ac to define 'HAVE_BLUEZ', but it looks
like this part would benefit from a bit of rework. Setting HAVE_BLUEZ
when we have dbus+sbc sounds weird, there's probably a better name for
this variable.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This is unlike the autotools where we check that a header exist, here we
use pkgconfig because upstream ships a pkgconfig. I don't know from
which version though...
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This flag will make the loader fail if symbols are not resolved. It
seems to be our best bet to uncover every missing module dependencies.
For more details, I recommend to read:
<http://www.kaizou.org/2015/01/linux-libraries/>
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
