So the external tool would try to load each driver and put the detected one into the appropriate location in the registry?
Chris
From: Eric Pouech eric.pouech@wanadoo.fr Date: 2003/01/07 Tue PM 05:09:02 EST To: cmorgan@alum.wpi.edu CC: wine-devel@winehq.com Subject: Re: Sound driver autodetection
chrismorgan@rcn.com wrote:
I've been thinking about implementing sound driver autodetection in wine. On startup wine would try to open a device with each of the drivers until one was opened successfully. This seems pretty simple to implement, I was wondering if there was a dynamic way of detecting the list of drivers to try or whether this list would have to be hardcoded in a c file. Eric, any hints?
I don't think this belongs to wine. What we could need is: 1/ an external tool that lists all available drivers 2/ then creates the corrects initialization of the registry. this would also include defining the default driver 3/ then all MM DLLs would get their configuration from the registry
of course, 1/ will get complicated with different wine drivers outputing to the same physical device, but we could infer some of the rules here 1 & 2 could be implemented as a control panel (for better user performance), but also as a pure command line tool so that it can be invoked at wine initialisation (at least for 2/)
as a matter of fact, I already have 3/ implemented, but never committed it because of the lack of 1&2
A+
Eric Pouech
chrismorgan@rcn.com wrote:
So the external tool would try to load each driver and put the detected one into the appropriate location in the registry?
the tool(s) would need to: - detect all runnable sound drivers - let the user pick the one(s) he/she wants to run. it would have to detect that a wineoss and winealsa would in fact output to the same physical Linux device, so there's no need to install both of them. Things are a bit more complicated for aRts vs OSS for example where you get audio mixing/sharing with aRts and better RT capabilities (esp. for games) with OSS. - let also the user decides of the default driver (the one the mapper will open by default) - when this is decided, the registry should be populated accordingly
but, this should also be part of a more generic user oriented configuration program, going much further than the pure audio driver configuration
A+
Op woensdag 8 januari 2003 20:51, schreef Eric Pouech:
Things are a bit more complicated for aRts vs OSS for example where you get audio mixing/sharing with aRts and better RT capabilities (esp. for games) with OSS.
I'm currently playing StarCraft with the aRts driver and it seems to work pretty good. Only the movies play a little slow, ingame everything is ok. (I haven't tried any other driver yet so I don't know how the movies run with the ALSA or OSS driver). Setting aRts as default in case aRts is detected probably wouldn't cause any problems with most apps. Games that really need the ALSA or OSS driver could use an AppDefaults section.