While trying to figure out device subsets that have aren't internally
contain conflicting devices, we walk through all possible subsets and
check each set if it satisfies ConflictingDevices/SupportedDevices
listed in UCM configuration. For a better user experience, we want to
skip subsets that are fully included in another valid subset we will
also generate.
The iterate_device_subsets() function that achieves the former is
intentionally in iterative form to avoid a stack overflow, since it will
walk through 2^n sets. However, the iterate_maximal_device_subsets()
function that skips incomplete sets is in recursive form, as I had
assumed tail-call optimization would take care of the potential problem.
Convert iterate_maximal_device_subsets() to an iterative form, because
the recursion seems to trigger a segfault with more than 16 devices on
PulseAudio. It doesn't seem to happen on PipeWire, but it's better to
not leave it to luck.
Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/838
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The alsa/acp code already supports getting a user-friendly monitor name
using the EDID-Like Data (ELD) information available from cards that follow
the Intel HDA specification.
This patch adds support for also parsing the SAD fields of the ELD, and
exposing the results as a "iec958.codecs.detected" property on the
corresponding node, which should make it possible to provide more
user-friendly configuration UIs and defaults.
The default value will take effect if the session manager does not set a
different value.
Brief example:
test@test:~/checkouts/pipewire$ pw-dump | grep -E "(iec958.codecs.detected|iec958.codecs)\":"
"iec958.codecs": "[\"PCM\",\"AC3\",\"EAC3\",\"TrueHD\"]",
"iec958.codecs.detected": "[\"PCM\",\"AC3\",\"EAC3\",\"TrueHD\"]",
<after powering on my receiver>
test@test:~/checkouts/pipewire$ pw-dump | grep -E "(iec958.codecs.detected|iec958.codecs)\":"
"iec958.codecs": "[\"PCM\",\"DTS\",\"AC3\",\"EAC3\",\"TrueHD\",\"DTS-HD\"]",
"iec958.codecs.detected": "[\"PCM\",\"DTS\",\"AC3\",\"EAC3\",\"TrueHD\",\"DTS-HD\"]",
Big thanks to Pauli Virtanen <pav@iki.fi>, who also wrote large paths of the
code for this patch.
These shouldn't be enabled by default, because they cannot be
autodetected, and if the configuration is not a supported one, they
produce loud BRRRT at 100% volume and ALSA errors.
If the PCM is loaded directly using only api.alsa.path,
state->card_index may never be initialised, and then we end up opening
the wrong ctl device. Let's try a fallback for this case.
When the driver node is destroyed (like when unplugging the cable) it
will drop/pause all of the follower ALSA nodes. This is something that
happens internally because of how the ALSA nodes work together, on the
PipeWire level, the nodes are still running and they will just be moved to
another driver.
The problem is that nothing will then start the nodes again after moving
it to the new driver. Fix this by keeping track of the desired target
state of the ALSA node and restoring that state when we detect that we are
paused when moved to a new driver.
Fixes#4401
Add a new followerClock block in the profiler info. This is only set
when the follower could be a driver and it contains the clock info used
for following the driver, mostly the rate difference and delay.
Dump this info in pw-profiler -J
Make sure we always set the info in the clock, especially also when we
are following.
Keep a running average and variance of the error. Use this to
periodically update the DLL bandwidth. When the variance gets smaller,
we update the DLL more slowly to stay closer to the ideal rate.
This seems to improve the rate stability.
The properties of the card might overwrite those of the PCM.
For example, the cards's `alsa.id` will be set on the PCM too
since 37a51533e0 ("acp: add more properties for the card").
To avoid that, call `pa_alsa_init_proplist_card()` first
in `pa_alsa_init_proplist_pcm_info()` instead of last.
See #4135
Don't use the api.alsa.soft-mixer option to disable the path selection
but make a new api.alsa.disable-mixer-path.
Disabling the path selection might leave cards unusable after suspend,
so a separate option is a better idea.
See #4311
Use the helper instead of duplicating the same code.
Also add some helpers to parse a json array of uint32_t
Move some functions to convert between type name and id.
Add spa_json_begin_array/object to replace
spa_json_init+spa_json_begin_array/object
This function is better because it does not waste a useless spa_json
structure as an iterator. The relaxed versions also error out when the
container is mismatched because parsing a mismatched container is not
going to give any results anyway.
We have to unlink pcms when they are linked to a driver from
a different pcm.
When a playback and a capture pcm is linked and we start
the playback pcm and the capture pcm later this can leads
to a 'EPIPE' error on the capture device.
...
spa.alsa: hw:3,0c: snd_pcm_start: Broken pipe
...
The port.name should be something fairly unique and stable per node that
is also human readable.
Make sure we include the ALSA client name and port name in the
port.name but try to avoid double client names when the client name
is already in the port name.
There is also a api.alsa.disable-longname that is now set to true by
default. Setting this to false will include the unique client and port
id to the port.name.
This should make the midi port names much more presentable and more in
line with JACK1.
While the spec allows for 1ppm changes, our rate matching logic applies
these changes quite often, which can be spammy on USB. I haven't seen
hosts mind this, but it seems like it might be a problem at some point.
Additionally, if we also have bind ctls enabled, every pitch update is
also a wakeup for ourselves (whether or not we're listening for the
pitch ctls, since the mixer fd does not distinguish between ctls, those
are filtered after we wake up).
The 10ppm threshold is empirically tested as being not "too noisy" (i.e.
when updates happen, I can see them scroll by with `amixer events`).
If necessary, we can make this configurable in the future.
Use the new UMP alsa sequencer API to make it produce UMP packets.
Set the alsa sequencer to MIDI2.0, which will make it convert all
messages to MIDI-2.0 UMP automatically. We can copy this straight into
the control buffers.
This also solves some problems with large sysex messages that are now
nicely split into chunks with UMP.
ACP allows multiple %f in device strings (cf pa_alsa_open_by_template),
but we replace only one of them when emitting the nodes. The a52
profiles in default.conf use multiple %f and probably don't work.
Fix to replace also multiple %f when emitting ACP device nodes.
`:` is a reserved character on Windows filesystems.
As far as I can tell from looking through both PulseAudio and PipeWire
commit history the files under `alsa/mixer/samples` are not used or
installed by anything.
See #2474.
Can be used to group ports together. Mostly because they are all from
the same stream and split into multiple ports by audioconvert/adapter.
Also useful for the alsa sequence to group client ports together.
Also interesting when pw-filter would be able to handle streams in the
future to find out what ports belong to what streams.
When bound_ctl info cannot be read this array elem info
is set to NULL in 'fetch_bind_ctl'. So when we iterate
the bound_ctl array we always have to check this.
In ACP mode, we might be accessing front:0 as the PCM, and using that
string to generate the ctl device name does not make sense. In
PulseAudio, we used the card index to generate a hw:X string, and we
replicate that here.
Fixes: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4028
The default kernel pool size on the input is 200 cells. A cell is
about 28 bytes long so the maximum message that can be received in one
go is about 5600 bytes. This causes problems when using amidi to upload
larger sysex messages because they simply can't be received by the
sequencer.
It if however possible to increase this limit with the set_client_pool()
function. Increase the pool size to at least the quantum_limit * 2.
This ensures we can receive and send at least 2 quantums of raw data,
which should be a fairly long sysex message.
Make a min and max value for the pool size. There is an upper limit of
2000 in the kernel but make this configurable and clamp the final
pool size to the min/max.
Make the MAX_EVENT_SIZE 256, because this is how the sequencer seems to
splits the input data as well and it results in less wasted space in the
output buffer.
See #4005
snd_midi_event_encode() will reset the encoder when it returns an
encoded event. It is possible that the function returns with an encoded
event when the internal buffer is full, in that case we need to push the
event and continue encoding without reseting the encoder.
0 is not a snd_midi_event_encode() error, so don't handle it like
one.
The messages, mostly sysex, can be split over multiple control message.
This happens when we read large messages from the sequencer, the
snd_seq_event_input function returns split messages that we transfer to
control messages directly.
When we send those messages out, however, the encoder wants the complete
message before it will return a valid event that we can send out. Keep
on calling the encoder with the control events until we get a complete
message that we can send out.
Fixes#4005
