[Bug 27956] Dragon Naturally Speaking: Sound no longer works; sample rates and size is no longer supported

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=27956

--- Comment #22 from Andrew Eikum <aeikum at codeweavers.com> 2011-09-21 15:39:53 CDT ---
(In reply to comment #21)
> Wine behaves differently and relies on the underlying ALSA/OSS/CoreAudio to
> close the gap beside what msacm can do.  This works on my machine with the
> default device that is either plug:dmix or PulseAudio which can support mono,
> but the individual hw:0 device can't. plughw:0 can.
> 
> Wine should strive for more HW independence and provide the same user
> experience on all machines.

This would be nice, but I really do not want to have a mixer in Wine. That's a
pretty big project which is really suited for the audio API itself.

> Susan, can you trick the registry so as to use plughw:x,y as your device
> instead of the raw hw:x,y? The plug ALSA thing will do channel "mapping".

You'll actually have to hack the winealsa.drv source as the MMDevAPI driver
doesn't use the registry at all. There are two occurances of "hw:" in the code,
but I don't know which need to be replaced. Should we be doing device
enumeration in a different manner?

> What I don't yet understand is: why was there a change with wine-1.3.25? The
> winmm devices ought to report no less supported formats than before because
> naively, they map to hw:x,y where nothing changed.  What is different?

You can see the old device enumeration code at
<dlls/winealsa.drv/waveinit.c:ALSA_ScanDevices> or so. It is a hideous,
horrible, hacky mess. I didn't have much interest in copying that, so I just
took a little inspiration and rewrote it. Perhaps a hideous, horrible, hacky
mess is the best you can do with ALSA, though...

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.