right way to enumerate pcm devices

right way to enumerate pcm devices

[sylvain.bertrand]

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

Re: right way to enumerate pcm devices

[Takashi Iwai]

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
> 

Re: right way to enumerate pcm devices

[sylvain.bertrand]

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

Re: right way to enumerate pcm devices

[Takashi Iwai]

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

Re: right way to enumerate pcm devices

[sylvain.bertrand]

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

Re: right way to enumerate pcm devices

[Takashi Iwai]

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
> 

Re: right way to enumerate pcm devices

[Jaroslav Kysela]

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.

Re: right way to enumerate pcm devices

[sylvain.bertrand]

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

Re: right way to enumerate pcm devices

[sylvain.bertrand]

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

Fwd: right way to enumerate pcm devices

[Joël Krähemann]

---------- 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

Re: Fwd: right way to enumerate pcm devices

[sylvain.bertrand]

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