Muting is a special case that is explicit and separated from volume
within PulseAudio, but merged together into a single variable over the
A2DP AVRCP connection.
Most devices report either 0 or 1 as their lowest volume.
Note that capital Volume in the following paragraphs refer to the Volume
property on org.bluez.MediaTransport1.
This commit deals with the following cases:
1. When the PA stream is muted, notify the peer by setting Volume to 0.
While the stream is muted real_volume should _not_ be updated in the
callback when Volume changes to <= 1, or unmuting will _not_ return
to the original volume.
2. When locally changing stream volume, and muting is enabled, do _not_
send updates to the peer. The peer should stick with Volume = 0.
3. When locally changing stream volume (and sending that to the peer)
any resulting updates on the Volume property should _not_ turn on
muting.
4. When the peer changes Volume, turn off muting (if enabled) when
Volume > 1.
5. When the peer changes Volume, turn on muting when Volume <= 1.
Such an implementation matches what happens on an Android device.
Muting sets the shared volume to 0, and upping the volume on the peer
(in case of headphones which usually only have up/down buttons) will set
it a single increment above that. Unmuting the stream from PA however
will return the stream back to the original volume, and notify the peer
of the same.
The discrepancy between merged and separate muting+volume results in a
conflict between point 3. and 5.: The peer (and/or dbus API) always
responds with the Volume property changing after PA writes it. If PA's
stream volume is decreased to a point where the callback triggers with
Volume <= 1 the stream is consequently muted, in accordance to point 5.
This is especially problematic when decreasing the local volume too far
(whether intentionally or not), as muting is not turned off by default
when the stream volume is increased afterwards.
This case is dealt with by preventing any Volume lower than 2 to be sent
to the device at any given point. Only the device itself can return a
Volume lower than that to enable implicit muting.
However, when point 5. happens, it is important to note that it can only
be unmuted by explicitly unmuting the stream from PA, _or_ increasing
the volume on the peer.
Commit c6d6ca541 ("bluetooth/gst: Replace buffer accumulation in adapter
with direct pull") removed the `timestamp` parameter from GStreamer
transcoders due to being unused, but these should instead be propagated
to the GStreamer encoding buffers.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/494>
Bluetooth codecs should always have fixed in/output and are hence able
to have their results directly read from the codec, instead of
accumulating in a buffer asynchronously that is subsequently only read
in the transcode callback. The Bluetooth backends calling encode/decode
also expect these fixed buffer sizes.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/494>
Handling multiple threads does not come without overhead, especially
when the end-goal is to ping-pong them making the whole system run
serially. This patch rips out all that thread handling and instead
"chains" buffers to be encoded/decoded directly into the pipeline,
making them execute their work on the current thread. The resulting
buffer can be pulled out from appsink immediately without require extra
locking and signalling. While the overhead on modern systems is found
to be negligible or unnoticable, code complexity of such locking and
signalling systems is prevalent making it the main drive behind this
refactor.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/494>
Drop rtpldacpay and payload the LDAC encoded output manually in the
RTP header.
The RTP payload seems to be required as it carries the frame count
information. Right now, rtpldacpay does not add this so construct
the RTP header and payload manually.
Strangely some devices like Shanling MP4 and Sony XM3 would still
work without this while some like the Sony XM4 does not.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/689>
If UCM defines the private alsa-lib configuration, the ELD controls
are expected to use this device configuration too.
With this change:
I: [pulseaudio] alsa-util.c: Successfully attached to mixer '_ucm0009.hw:Loopback'
Without:
I: [pulseaudio] alsa-util.c: Successfully attached to mixer '_ucm0009.hw:Loopback'
I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:4'
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/673>
The hw: device can be addressed using the card index (hw:0)
or the card identifier (ASCII string - hw:Loopback). Both
mixers are equal.
The previous code was fine for the mixers without the UCM
private prefixes (_ucmXXXX). Make code more robust, create
two aliased mixer structures in the mixers array.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/673>
This makes it possible to define multiple sinks/sources on detection
of the jack server. This allows one to for example create a separate
sink for conferencing software and route that in jack to another
channel on their audio interface.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/669>
Even though the file name is currently behringer-umc22.conf, the USB ID
actually belongs to Texas Instruments PCM2902, which is a generic chip
used in multiple products. Some products have true mono input unlike
Behringer UMC22, which has two mono inputs combined into one stereo PCM
device.
This patch removes the "mono,mono" mapping from Behringer UMC22, which
hopefully won't be missed too much (there are still "mono,aux1" and
"aux1,mono" mappings available for mono recording).
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/667>
If the preferred ports are not set in this function, the
entrys_equal() always returns false in the card_put_hook_callback().
This will make the entry be written into the metadata and the
preferred ports will be cleaned by a mistake.
And we met a hdmi audio bug which has sth to do with this issue, on
the machines with the legacy HDA audio driver, the hdmi port has lower
priority than speaker, users need to manually select the hdmi to be
active output port, then the preferred output port is hdmi for this
sound card, after reboot, the card_put_hook_callback() in the
module-card-restore.c will be called and the preferred ports are
cleaned by a mistake, then the hdmi output port or hdmi sink couldn't
switch to be active after reboot or resume automatically. That is
because the preferred ports are cleaned and hdmi port has lower
priority than speaker, the profile_good_for_output() in the
module-switch-on-port-available.c always returns false.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
