On 07/22/2011 08:35 AM, Andrew Eikum wrote:
This is really crude, but does seem to work. I tested it correct with just ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0.
This lets us attempt to load the OSS driver, and if that fails, then try the ALSA driver. Automatic driver selection!
You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry.
The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem.
Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for.
Vitaliy.
On 07/24/2011 06:56 PM, Vitaliy Margolen wrote:
On 07/22/2011 08:35 AM, Andrew Eikum wrote:
This is really crude, but does seem to work. I tested it correct with just ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0.
This lets us attempt to load the OSS driver, and if that fails, then try the ALSA driver. Automatic driver selection!
You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry.
They can, but it's non-functional by design in MMDevAPI. winecfg even says, "Selecting multiple drivers is not recommended."
The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem.
Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for.
I don't really understand. Maybe you're misunderstanding the logic in verify_actually_oss(). The registry entry check only occurs if the user has a driver specified in the registry. If there is no driver in the registry, as in a clean prefix, then the rest of the check will be run. The idea is that if the user specifically requests OSS in the registry, then we should not fail to load the OSS driver, even if the oss_sysinfo struct looks wrong.
The problem is that there is no way to ask the question "What audio system is currently being used?", so we have to come up with some other way to make a selection. Between OSS and ALSA, this was the most reliable method I could find. ALSA's OSS compatability doesn't properly fill the oss_sysinfo struct. If that struct looks wrong, then we fail to load the driver and fall back on the next one, ALSA.
We could certainly have done it the other way around: try to load ALSA unless we detect that ALSA isn't actually in use, and then fall back on OSS. But there is no reliable way to differentiate between true ALSA, and OSS's ALSA compatability.
Andrew
-
Andrew Eikum -
Vitaliy Margolen