>My opinion is that a simple function could be included in alsactl which >scans for available devices, makes a list of their abilities. Everyone >uses "post-insert alsactl restore" in the modules.conf file so it would >be essentially a non issue from a user perspective.
i think it needs to be slightly more complex than that (because of the way the configuration space is reduced as various parameters are set). we need a structure that is somewhat equivalent to hw_params. the program fills it out, in effect asking for "16 bit, stereo, 48kHz, 1024 frames/period" and then queries to see what devices can satisfy that. it will be hard for the program to use this if it thinks it can handle multiple configurations, but there are not many programs that work this way: most know what configuration they want, and just want to find devices that can work that way. otoh, one may counter that the plughw layer in alsa-lib is there to allow *any* h/w device to be used with *any* configuration, so this is all a bit ridiculous. of course, the devices may be busy, so the program needs to be ready for that as well (this applies to multiopen cards just the same, even if its much less likely that they are "fully" busy). ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
