> Hello all, > > here are my next goals for the ALSA library development (short > term). I invite all developers to comment these directions. >
[...] > * initiate a development of a graphical tool which will manage > the alsa configuration files (~/.asoundrc) > - we need a rapid development tool; I slowly became a fan of python > and > Qt has rich number of widgets; python + PyQt seems to me a good idea > - using python requires to write a GPLed ALSA 0.9 -> python wrapper > One point I would like to bring to focus is how sound hardware state persistance is dealt with. The limits of alsactl are showing up with hardware like the hdsp, were the card might not be fully initialized (or not even present yet, e.g. cardbus) at boot time. We're more and more likely to have to deal with such external hotpluggable devices (pcmcia, firewire, usb), where full initialization can happen any time after the boot process, and we can't expect the average user to be scripting around. IMHO state restoration could be : * triggered by the driver, at the appropriate time, depending maybe on some system configuration options. * initiated by the user, through the configuration GUI. We could have a default configuration restored by the driver at initialization time, and a set of named configurations the user could save/restore/set as default using the GUI. There are probably other ways to handle this, I'm waiting for your comments. Thomas ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
