[alsa-devel] right way to enumerate pcm devices
Hi,
I got some code based on hints which, unfortunately, seems not sufficient.
I can list the hardware cards, but what is the proper way to enumerate the pcm devices?
For instance, I don't get basic user defined pcm devices, I get all the surround pcm devices for the USB mic from my webcam etc... The real question: how I build a clean list of pcm devices I would present to a user to choose from without confusing him/her?
Wherever I look I get only this hint based code. I presume I am looking the wrong way.
regards,
On Tue, 12 Feb 2019 13:33:33 +0100, sylvain.bertrand@gmail.com wrote:
Hi,
I got some code based on hints which, unfortunately, seems not sufficient.
I can list the hardware cards, but what is the proper way to enumerate the pcm devices?
Parsing the hints is the right way.
For instance, I don't get basic user defined pcm devices, I get all the surround pcm devices for the USB mic from my webcam etc...
The entries without hints are filtered out as default. i.e. a user-defined entry appears, too, if it contains the hints.
You can change the behavior by setting defaults.namehint.showall, too.
HTH,
Takashi
The real question: how I build a clean list of pcm devices I would present to a user to choose from without confusing him/her?
Wherever I look I get only this hint based code. I presume I am looking the wrong way.
regards,
-- Sylvain _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Tue, Feb 12, 2019 at 02:36:00PM +0100, Takashi Iwai wrote:
The entries without hints are filtered out as default. i.e. a user-defined entry appears, too, if it contains the hints.
You can change the behavior by setting defaults.namehint.showall, too.
Hi again,
I am listing the pcm devices, and for the USB mic of my webcam, I get input (IOID=Input) pcm devices for surroundX/frontspeakers/IEC958, which are actually output pcm devices. Why those output pcm devices are hinted as input devices?? Is this expected? Bug? If not, how am I supposed to select the proper input pcm devices the right(tm) way ?
regards,
On Tue, 12 Feb 2019 21:33:24 +0100, sylvain.bertrand@gmail.com wrote:
On Tue, Feb 12, 2019 at 02:36:00PM +0100, Takashi Iwai wrote:
The entries without hints are filtered out as default. i.e. a user-defined entry appears, too, if it contains the hints.
You can change the behavior by setting defaults.namehint.showall, too.
Hi again,
I am listing the pcm devices, and for the USB mic of my webcam, I get input (IOID=Input) pcm devices for surroundX/frontspeakers/IEC958, which are actually output pcm devices. Why those output pcm devices are hinted as input devices?? Is this expected? Bug? If not, how am I supposed to select the proper input pcm devices the right(tm) way ?
It's only the matter of alsa-lib card config. Just due to heuristic reason, the secondary device is assigned as iec958 as default. There are explicit whitelist setup in alsa-lib/src/conf/cards/USB-Audio.conf for the card that behave differently. You'd need to adjust accordingly.
Takashi
On Wed, Feb 13, 2019 at 07:25:13AM +0100, Takashi Iwai wrote:
It's only the matter of alsa-lib card config. Just due to heuristic reason, the secondary device is assigned as iec958 as default. There are explicit whitelist setup in alsa-lib/src/conf/cards/USB-Audio.conf for the card that behave differently. You'd need to adjust accordingly.
Tell me if I did understand you right:
I cannot trust the hint system to select proper pcm devices for, let's say the mic of my USB cam.
I would have to ignore "mostly" the configuration system (the major exception would be the default pcm device) and build myself the pcm devices from the info I can get from the hardware device (hardware mixing, input and/or output, number of channels/etc).
I would have to cherry pick configuration defined pcm devices for specific modes, like surroundX, only if the "basic user" explicitely requests such modes.
The advanced user should override the default pcm device if he/she wants to do/fix tricky sound thingies.
----
To summarize: - show always the pcm default - build custom pcm devices based on hardware info, and show them - for "special" modes, likes surroundX, show the related configuration defined pcm devices only if the "basic" user want to fool around with them.
On Wed, 13 Feb 2019 15:13:28 +0100, sylvain.bertrand@gmail.com wrote:
On Wed, Feb 13, 2019 at 07:25:13AM +0100, Takashi Iwai wrote:
It's only the matter of alsa-lib card config. Just due to heuristic reason, the secondary device is assigned as iec958 as default. There are explicit whitelist setup in alsa-lib/src/conf/cards/USB-Audio.conf for the card that behave differently. You'd need to adjust accordingly.
Tell me if I did understand you right:
I cannot trust the hint system to select proper pcm devices for, let's say the mic of my USB cam.
It can be seen rather as a bug in alsa-lib card config. The card config should be fixed to match with this badly behaving device.
I would have to ignore "mostly" the configuration system (the major exception would be the default pcm device) and build myself the pcm devices from the info I can get from the hardware device (hardware mixing, input and/or output, number of channels/etc).
Or report the bug to get it fixed.
I would have to cherry pick configuration defined pcm devices for specific modes, like surroundX, only if the "basic user" explicitely requests such modes.
... if you want to fix it by yourself, right.
The advanced user should override the default pcm device if he/she wants to do/fix tricky sound thingies.
The advanced user should report the bug report, not ignore and work around it, too :)
Takashi
To summarize:
- show always the pcm default
- build custom pcm devices based on hardware info, and show them
- for "special" modes, likes surroundX, show the related configuration defined pcm devices only if the "basic" user want to fool around with them.
-- Sylvain
Dne 13. 02. 19 v 15:13 sylvain.bertrand@gmail.com napsal(a):
On Wed, Feb 13, 2019 at 07:25:13AM +0100, Takashi Iwai wrote:
It's only the matter of alsa-lib card config. Just due to heuristic reason, the secondary device is assigned as iec958 as default. There are explicit whitelist setup in alsa-lib/src/conf/cards/USB-Audio.conf for the card that behave differently. You'd need to adjust accordingly.
Tell me if I did understand you right:
I cannot trust the hint system to select proper pcm devices for, let's say the mic of my USB cam.
As Takashi noted, we can fix this for your device in the alsa-lib's configuration file to not show the extra invalid surround devices, but it does not mean that the other USB devices are not affected. We are always a little bit behind the hardware. The library does not do any probing for the available channels when the devices are enumerated.
I would have to ignore "mostly" the configuration system (the major exception would be the default pcm device) and build myself the pcm devices from the info I can get from the hardware device (hardware mixing, input and/or output, number of channels/etc).
I would have to cherry pick configuration defined pcm devices for specific modes, like surroundX, only if the "basic user" explicitely requests such modes.
The advanced user should override the default pcm device if he/she wants to do/fix tricky sound thingies.
To summarize:
- show always the pcm default
- build custom pcm devices based on hardware info, and show them
- for "special" modes, likes surroundX, show the related configuration defined pcm devices only if the "basic" user want to fool around with them.
This is not optimal. It would be better to settle something in the one place. I would start to fix the blacklists in /usr/share/alsa/cards/USB-Audio.conf for your device (and post the alsa-lib's patch here).
Perhaps the USB driver might forward also more hints/parameters about the device characteristics to improve this hint system.
Jaroslav
Ok, I think got it.
Jaroslav Kysela, thx for your intervention, actually my device does not need fixing, it's a simple USB mic.
Takashi Iwai, ok, then it's actually the alsa-lib configuration system which seems to be the problem, where the "bugs" should be squashed.
If I want to do the thing which I think it's right, then I would have to move the "lines" between the user application'S' and the alsa-lib. Something "middleground", nothing extreme like the excessively massive pulseaudio.
It boils down to how and how much the alsa-lib shares pcm devices among user applications. I would beef up only the user applications sharing code, aka dmix and dsnoop, and would move all the rest into the user application realm, aka trashing almost everything else.
Each "hardware pcm" would get only 1 pcm device with integrated beefed up dmix or dsnoop.
The "hardware fixing" would go into the kernel where I think it belongs.
As for a user application sharing policy, as I said, I would avoid the extreme like the excessively massive pulseaudio, and would go for the middleground: the first user application to program the pcm device does set the configuration of it (channels,formats,etc). The other concurrent user applications would have a way to know they were beaten in speed, and could be given the chance to adapt (new return codes in current pcm api) to the current configuration of the pcm device or take other action.
Access rights would be those from the file system.
The beefed up dmix and dsnoop would expose as much as they can of the underlying hw regarding what they can do (available mixing formats for dmix). No more graph/chain of plugins which would be moved into the user applications).
The configuration would be limited to THE default (maybe one for playback and one for capture).
As for now, I would present to basic users the default pcms and filter out anything else (at best, give a chance to input the pcm string of a specific pcm for the most advanced basic users).
regards,
participants (3)
-
Jaroslav Kysela -
sylvain.bertrand＠gmail.com -
Takashi Iwai