search

alsa-project / alsa-lib

The Advanced Linux Sound Architecture (ALSA) - library
GNU Lesser General Public License v2.1
344 stars 173 forks source link

default pcm plugin #371

Closed sylware closed 7 months ago

sylware commented 7 months ago

Is there a robust programming way to know if the canonical "default" pcm is actually a pipewire/pulseaudio/jack plugin? That at a device/pcm enumeration time, namely before any pcm is actually being configured.

I was thinking about the "configuration" API, but I am not that sure it "resolves" everything including user-specific/system-specific configurations (asound rc files and env variables).

perexg commented 7 months ago

The only method without "open" is to parse the configuration tree - see alsactl dump-cfg and look for block like:

Example for custom ~/.asoundrc:

pcm.default plughw:1

System-wide config:

pcm.default {
        type pipewire
        ...
}

Are you thinking about alsa-lib API extension or your code API extension? This request looks like a missing API in alsa-lib.

sylware commented 7 months ago

Like you did describe yeah, to "resolve" the configuration for the canonical "default" pcm based on everything.

alsa-ctl dump-cfg does not do it, obviously (it looks like a dump, not a resolution). I am looking at an existing way, not extending the API.

Then I guess I have to look at the code from pcm open to see if there is something reasonable to do.

The goal is to present to the user some "sugar" information, like its cannonical default is using a non alsa software mixer (pulseaudio[012]/jack/other). It is more than reasonably fine without this piece of information given to the user.

perexg commented 7 months ago

The dump is the configuration static base tree. The open just calls the snd_config_search_definition function using this base tree which expands the configuration, but you'll end in the first plugin. The rest of configuration is evaluated in the chained open calls. But it may be enough for your purpose.

sylware commented 7 months ago

Allright, it means I need to have a look at this chain of snd_config_search_definition calls. If the "expansion"(resolution) of the "top" snd_config_search_definition ("default") is enough to know, robustely (including user and system specific configuration, the asound rc files), than we are dealing with an external software mixer (pulseaudio[012]/jack/whatever plugins), this will be more than enough.

sylware commented 7 months ago

I slept on it, and I think adding a dependency on an "advanced" part of the alsa-api which could be changed or removed... I feel like throwing some tantrums for something which is only sweet sugar for some users.

I would be better off writting avx2 channel swizzling support than that.

Never mind, thx.