Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS

[Vitaliy Margolen]

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.

[PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS

[Andrew Eikum]

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