* right way to enumerate pcm devices @ 2019-02-12 12:33 sylvain.bertrand 2019-02-12 13:36 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: sylvain.bertrand @ 2019-02-12 12:33 UTC (permalink / raw) To: alsa-devel 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, -- Sylvain ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-12 12:33 right way to enumerate pcm devices sylvain.bertrand @ 2019-02-12 13:36 ` Takashi Iwai 2019-02-12 20:33 ` sylvain.bertrand 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2019-02-12 13:36 UTC (permalink / raw) To: sylvain.bertrand; +Cc: alsa-devel 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-12 13:36 ` Takashi Iwai @ 2019-02-12 20:33 ` sylvain.bertrand 2019-02-13 6:25 ` Takashi Iwai 0 siblings, 1 reply; 11+ messages in thread From: sylvain.bertrand @ 2019-02-12 20:33 UTC (permalink / raw) To: Takashi Iwai; +Cc: 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, -- Sylvain ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-12 20:33 ` sylvain.bertrand @ 2019-02-13 6:25 ` Takashi Iwai 2019-02-13 14:13 ` sylvain.bertrand 0 siblings, 1 reply; 11+ messages in thread From: Takashi Iwai @ 2019-02-13 6:25 UTC (permalink / raw) To: sylvain.bertrand; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-13 6:25 ` Takashi Iwai @ 2019-02-13 14:13 ` sylvain.bertrand 2019-02-13 14:33 ` Takashi Iwai ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: sylvain.bertrand @ 2019-02-13 14:13 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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. -- Sylvain ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-13 14:13 ` sylvain.bertrand @ 2019-02-13 14:33 ` Takashi Iwai 2019-02-13 14:38 ` Jaroslav Kysela 2019-02-13 22:25 ` sylvain.bertrand 2 siblings, 0 replies; 11+ messages in thread From: Takashi Iwai @ 2019-02-13 14:33 UTC (permalink / raw) To: sylvain.bertrand; +Cc: alsa-devel 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-13 14:13 ` sylvain.bertrand 2019-02-13 14:33 ` Takashi Iwai @ 2019-02-13 14:38 ` Jaroslav Kysela 2019-02-13 22:25 ` sylvain.bertrand 2 siblings, 0 replies; 11+ messages in thread From: Jaroslav Kysela @ 2019-02-13 14:38 UTC (permalink / raw) To: sylvain.bertrand, Takashi Iwai; +Cc: alsa-devel 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 -- Jaroslav Kysela <perex@perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-13 14:13 ` sylvain.bertrand 2019-02-13 14:33 ` Takashi Iwai 2019-02-13 14:38 ` Jaroslav Kysela @ 2019-02-13 22:25 ` sylvain.bertrand 2019-02-13 22:43 ` sylvain.bertrand 2 siblings, 1 reply; 11+ messages in thread From: sylvain.bertrand @ 2019-02-13 22:25 UTC (permalink / raw) To: alsa-devel; +Cc: Takashi Iwai 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, -- Sylvain ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: right way to enumerate pcm devices 2019-02-13 22:25 ` sylvain.bertrand @ 2019-02-13 22:43 ` sylvain.bertrand [not found] ` <CA+Owze4OqfSystQ5ZNaF6sO+L-L-FceN5XBPJkqyYf7zjkp+GQ@mail.gmail.com> 0 siblings, 1 reply; 11+ messages in thread From: sylvain.bertrand @ 2019-02-13 22:43 UTC (permalink / raw) To: alsa-devel; +Cc: Takashi Iwai On Wed, Feb 13, 2019 at 10:25:18PM +0000, sylvain.bertrand@gmail.com wrote: > ... Actually, I would just give a way to police the access to buffers. For instance the user application would be in charge of handling the actual mixing (I guess mmap-ed dma buffers). -- Sylvain ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CA+Owze4OqfSystQ5ZNaF6sO+L-L-FceN5XBPJkqyYf7zjkp+GQ@mail.gmail.com>]
* Fwd: right way to enumerate pcm devices [not found] ` <CA+Owze4OqfSystQ5ZNaF6sO+L-L-FceN5XBPJkqyYf7zjkp+GQ@mail.gmail.com> @ 2019-02-13 23:11 ` Joël Krähemann 2019-02-14 13:12 ` sylvain.bertrand 0 siblings, 1 reply; 11+ messages in thread From: Joël Krähemann @ 2019-02-13 23:11 UTC (permalink / raw) To: alsa-devel ---------- Forwarded message --------- From: Joël Krähemann <jkraehemann@gmail.com> Date: Thu, Feb 14, 2019 at 12:11 AM Subject: Re: [alsa-devel] right way to enumerate pcm devices To: <sylvain.bertrand@gmail.com> Hi all, Thank you for the hint about alsa hints. It was very helpful. Just updated my code: http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_devout.c?h=2.1.x&id=04344097582d48fbd0a72e7bf86af904c8fe9c8d#n1688 bests, Joël On Wed, Feb 13, 2019 at 11:44 PM <sylvain.bertrand@gmail.com> wrote: > > On Wed, Feb 13, 2019 at 10:25:18PM +0000, sylvain.bertrand@gmail.com wrote: > > ... > > Actually, I would just give a way to police the access to buffers. For > instance the user application would be in charge of handling the actual > mixing (I guess mmap-ed dma buffers). > > -- > Sylvain > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fwd: right way to enumerate pcm devices 2019-02-13 23:11 ` Fwd: " Joël Krähemann @ 2019-02-14 13:12 ` sylvain.bertrand 0 siblings, 0 replies; 11+ messages in thread From: sylvain.bertrand @ 2019-02-14 13:12 UTC (permalink / raw) To: alsa-devel Huho! My bad, I was stuck into my usb mic use case. But for playback, ofc, the last hardwarly mixed buffer will have to be dmixed from multiple source buffers. regards, -- Sylvain ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-02-14 13:12 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-12 12:33 right way to enumerate pcm devices sylvain.bertrand 2019-02-12 13:36 ` Takashi Iwai 2019-02-12 20:33 ` sylvain.bertrand 2019-02-13 6:25 ` Takashi Iwai 2019-02-13 14:13 ` sylvain.bertrand 2019-02-13 14:33 ` Takashi Iwai 2019-02-13 14:38 ` Jaroslav Kysela 2019-02-13 22:25 ` sylvain.bertrand 2019-02-13 22:43 ` sylvain.bertrand [not found] ` <CA+Owze4OqfSystQ5ZNaF6sO+L-L-FceN5XBPJkqyYf7zjkp+GQ@mail.gmail.com> 2019-02-13 23:11 ` Fwd: " Joël Krähemann 2019-02-14 13:12 ` sylvain.bertrand
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.