Creative Labs Sound Blaster Audigy cards (snd_emu10k1 driver) expose
mixer controls named 'PCM Front', 'PCM Rear', etc. in addition to the
more common 'Front', 'Rear', etc. The latter seem to be intended for
a stereo-to-all-speakers mirroring mode that we do not use, and have
no effect when we adjust them.
https://docs.kernel.org/sound/cards/audigy-mixer.html
We therefore define a custom mixer path for Audigy devices, using the
PCM mixer controls.
This has been tested on an Audigy 5/Rx. Based on a brief look at the
ALSA driver, I think all Audigy devices (vendor 0x1102, device 0x0004
or 0x0008) have the same PCM controls, making this change probably safe
for our existing Audigy udev rules.
Relevant kernel files:
sound/pci/emu10k1/emu10k1_main.c
sound/pci/emu10k1/emufx.c
include/sound/emu10k1.h
Fixes#2934
Add check for running the the loop context and thread.
Add checks in filter and stream to avoid doing things when not run from
the context main-loop because this can crash things when doing IPC from
concurrent threads.
-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.
