-To select between non-native(via control channel) and native modes(via audio
adapter ). The control port will be opened only in the non-native mode.
-To select different sample and sample step sizes. The Legacy non-native
mode also uses these params now.
-To provide the alsa device.
Use the ISO IO helpers to get synchronized BAP output, and rate match to
the ISO schedule.
The rate matching is necessary, since the driver may be ticking at a
corrected rate, different from the ISO interval rate.
Add factored out helper for ISO socket I/O.
ISO sockets need synchronization of writes and audio position for
different stream fds in the same isochronous group, and it's easier to
separate out the part that coordinates it.
Avoiding unnecessary release + reacquire when nodes restart makes sense
for all transport types. Do timed releases for all transport types, not
only SCO.
Ensure that we clear the rate matching when we are not using the
converter. This will make the follower use the quantum instead of the
dummy unused rate matching area.
Exit when we can't make an internal converter because then things really
are not going to work. Remove some of the pointless NULL checks.
For IRQ based scheduling we might otherwise be woken up after we only
added one of the fds to the poll loop and then we get an error when we
try to update it afterwards. Instead, add the fds from the data thread
to get things nicely in sync.
In IRQ mode, disable the ALSA fds while we wait for the graph to produce
data. Otherwise we will wake up very quickly over and over.
When we get more data, we activate the sources again to start the next
cycle.
Provides configuration to disable timer-based scheduling. This can be
useful at low latencies, for example, where period-based interrupts
might be more reliable than timers.
A driver node should use the target_duration and target_rate to adjust
the quantum and rate when the graph starts.
The camera nodes don't currently support any of this and simply enforce
a specific rate and duration for the graph clock. Mark this with a
FIXME. Otherwise, pipewire will complain that the node is ignoring the
configured graph rate.
We should really look at the graph target rate/quantum and only produce
a buffer when it is inside the current graph cycle. This would make it
possible to join audio and camera nodes and have them be in sync.
Do transport release synchronously for simplicity. BlueZ handles
releasing while acquire is pending, but acquire while release is pending
would fail the acquire.
Otherwise we need to maintain an operation chain to handle trying to
acquire/release while the other operation is pending. This makes things
complex with little gained, as releases generally don't block for a long
time.
Start and stop the timers in the data_loop. Otherwise we might be trying
to stop a timer while the data loop is starting it and we end up with
"ready non-active node" messages.
Drivers should only read the target_ values in the timeout, update the
timeout with the new duration and then update the position.
For the position we simply need to add the previous duration to the
position and then set the new duration + rate.
Otherwise, everything else should read the duration/rate and not use
the target_ values.
Place the target rate and duration in the io clock area.
The driver is meant to read these new values at the start of the cycle
and update the position rate and duration.
This used to be done by the pipewire server when it received the ready
callback from the driver but this is in fact too late. Most driver would
start processing and set the next timeout based on the old rate/duration
instead of the new pending ones.
There is still a fallback for the old behaviour (with a warning) when
the driver doesn't yet update the position.
But instead ship config override files to enable it again.
The idea is that distros can make extra packages that can than be
installed to enable the upmixing.
Also ship a config file to enable more samplerates.
Fixes#3081
The code that removes the mixer path if probing fails can be called in
the path that sets a non-off device profile on hotplug *before*
card->active_profile is updated, which results in spuriously removing
the mixer path. By this point, context->ucm->active_verb would be set
to the same as the profile name, so we can use that instead to avoid
the issue.
On Apple Silicon machines with the UCM profiles in the Asahi Linux repo,
this manifests as the headphones jack having hardware volume controls
*only* if PA is started with headphones connected and until they are
disconnected. Hotplugs end up triggering the bad codepath, and it falls
back to software volume (which is particularly a problem when the
hardware volume happens to be very low or 0 at that point).
Fixes: a9cc1373e2a7 ("alsa: ucm - update the mixer path also after volume probe")
Signed-off-by: Hector Martin <marcan@marcan.st>
The ucm_get_device_property() function adds to each UCM device's
playback_volumes (or capture_volumes) hash map an associated volume
mixer keyed with the UCM verb. These key-value pairs are then iterated
over in various places which assume the key is a profile name. This
assumption is no longer true since we can generate multiple profiles to
use conflicting devices.
A previous commit 45278904167f ("alsa-ucm: Stop conflating profile name
with UCM verb name") fixes some instances of this assumption, but misses
the relation explained above. Fix more instances of misleading
"profile"s where the UCM verb name is actually meant.
Fixes: 45278904167f ("alsa-ucm: Stop conflating profile name with UCM verb name")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
