Re: right way to enumerate pcm devices

[sylvain.bertrand@gmail.com]

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