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,