Right now this check is rejecting devices whose UCM config specifies
neither a conflicting device nor a supported device list, and accepting
devices which specify both. However, a device without neither list is
actually unrestricted, and a device with both lists is a configuration
error. Fix the check to accept the former.
Furthermore, this is missing another case where an already selected
device might have a supported devices list that doesn't have the
candidate device. Make this function also check against that, and also
make it accept devices already in the set.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The existing code meant to generate device groups for combination ports
is tightly coupled to port creation. Similar functionality would be
useful to generate nonconflicting device groups for multiple profiles as
well, so this tries to rewrite it into a more reusable state.
Several things (e.g devices, mapping contexts) use idxsets to store a
device selection. This also switches this conformance check and device
group generation to using idxsets to make it easier to work with those,
with the eventual aim to unify device group representations.
Also try to adjust users of these functions to use idxsets these will
need/return, without causing too much interference.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To support having multiple profiles per UCM verb, split the profile
creation into two parts based on whether they should run once for each
verb or for each profile (maybe multiple times per verb).
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The ucm_create_mapping() function is not idempotent. It looks like it
was meant to be called once per device for the devices of a UCM verb
and takes a profile argument simply because a verb has generated a
single profile so far.
Make sure creating mappings per device and adding those mappings to the
profiles happens as separate steps to make it easier to split UCM verbs
and profiles as concepts.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
So far each profile had the exact name as their associated UCM verb,
which caused the one to be used where the other should have been.
Explicitly get and use the verb name where that was intended, and make
sure things about profiles aren't named after verbs.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Currently each UCM verb generates one profile named the same as the
verb, meaning it's trivial to know which verb the profile belongs to.
This will be slightly harder to do when we generate multiple profiles
per UCM verb (e.g. to make use of conflicting devices).
It would still be possible to parse the profile name to get the UCM
verb, but instead let's keep track of the struct instance representing
the profile's associated verb. This also lets us remove a block of code
searching for the verb by its name.
Co-authored-by: Jaroslav Kysela <perex@perex.cz>
[Alper: Reused Jaroslav's UCM profile context changes for UCM verb
instead of combined devices.]
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
While switching profiles, it's possible that we will want to do more
work besides switching UCM verbs. The alsa-card module already has our
profiles as structs, but passes in only the names instead of the entire
struct. Make things work with the struct instead, so we can add other
things (like a UCM context) to it and use those here.
Co-authored-by: Tanu Kaskinen <tanuk@iki.fi>
[Alper: Split into its own commit and integrated Tanu's snippet.]
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Right now manipulating device status is done inline once while setting a
port. However, we will need to reuse this code to disable conflicting
devices of a device we want to enable. Split it into enable and disable
helper functions.
There is another issue with the device enable logic, where trying to
disabling an already disabled device sometimes fails. To avoid that,
implement a status helper and check if the device we want to enable is
already enabled/disabled before trying to do so.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Modifiers currently keep their conflicting and supported devices's
names, and these names are resolved to devices every time we need to use
them. Instead, resolve these device names while creating the modifier
struct and keep track of the resulting device structs in idxsets, same
as how device structs keep track of their support relations.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This is intended to make the current and upcoming code a bit clearer, as
we won't need to constantly check for the existence of these idxsets
before using or operating on them.
It may be possible that the ALSA control element appears
again. Allow this combination by checking, if the pulseaudio
mixer element already exists. Do not create the duplicate
mixer element in this case.
Don't just limit the max delay of samples we keep in the ALSA ringbuffer
to the buffer_size but to half of it. Make this into a max_delay
variable.
If we have a buffer size of 8192 samples and a headroom of 8192 samples,
when capturing, we would wait for the ringbuffer to contain at least
8192 samples, which would always xrun. When we limit the size to
half, we can still read the data without xruns.
Fixes#2972
* Add support for running the sink as a driver
* Detect which compressed formats are actually supported
* Correctly open/close/start/stop device according to the node commands
* Shift away from tinycompress and use Compress-Offload ioctls directly
to be able to access various caps information (including fragment sizes)
which are unavailable in the tinycompress API
* Implement SPA_PARAM_PropInfo and SPA_PARAM_Props support
When we are rate matching, keep some more headroom to make sure we
have enough data for the adaptive resampler.
Fixes crackling when following the dummy node and probably also when
following another capture device.
We always probe the Pro Audio profile with the maximum number of
channels but this can lead to a more limited amount of sample rates.
Add an option to set the channels used when probing so that the other
samplerates become available.
Fixes#2990
Make a real debug context with a log function and move it to a new file.
This way we don't need to redefine a macro.
Make a new context for debugging to a log file. Make new functions to
debug to a log file.
Move the stringbuffer to string utils.
Integrate file/line/func and topics into the debug log.
We can remove some more things from the pipewire log_object function and
also add support for topics.
Add new spa_debugc_ funnctions that take a context. The user should also
redefine the spa_debugc macro to handle the context.
Use this to let some plugins log the pod and format to the log without
using the global logger.
Also use this to remove our custom pod logger function by reusing the
spa one with a custom context.
Add SPA_SCALE32_UP that scales a uint32 without overflow.
Use this for scaling the threshold in ALSA.
Fix the scaling in audioconvert of the buffer size, the scaling was
wrong and it was also causing an overflow resulting in choppy sound in
some cases.
See #2680
For encoded format, we need to send bigger chunks to make the encoder
happy. Add a new min_delay variable with this info so that we never
leave less than that amount of samples in the ringbuffer.
Fixes#2650
When reading the timerfd gives an error, we should return right away
because the timeout did not happen.
If we change the timerfd timeout before reading it, we can get -EAGAIN.
Don't log an error in that case but wait for the new timeout.
And... we're back to 48Khz probing. Some devices fail to probe with
44.1KHz so when we need to choose between 2 bad things we choose to
do the right thing, which is probe in 48KHz.
Fixes#2857
When we try to play data but the ringbuffer is full, we need to start
the device or else we will stay in this situation forever and stay
silent.
Fixes#2830
port_enum_params should use right param id for SPA_PARAM_Format.
Fix typoed , instead of ; at end of line. Pop frame before putting
state.offset, in case there would be padding added (apparently usually
no).
Do not start the playback device until there is data to play. Otherwise
time consuming configuration of other nodes (such as setting hw params
of a capture device) may be done after playback has been started, which
may cause xrun.
uint32_t i;
for (i = 0; i < SPA_N_ELEMENTS(some_array); i++)
.. stuff with some_array[i].foo ...
becomes:
SPA_FOR_EACH_ELEMENT_VAR(some_array, p)
.. stuff with p->foo ..
