[PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
aeikum at codeweavers.com
Mon Jul 25 07:56:05 CDT 2011
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
>> 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.
More information about the wine-devel