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

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Sep 21 15:21:31 CDT 2011


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

Jörg Höhle <hoehle at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hoehle at users.sourceforge.ne
                   |                            |t

--- Comment #21 from Jörg Höhle <hoehle at users.sourceforge.net> 2011-09-21 15:21:30 CDT ---
I would not be opposed to an msacm chain. Not of any length, but to accommodate
PCM formats.
I'm not sure native would not daisy chain converters if really needed -
otherwise the PCM rate converter in msacm is probably never used.

The current code produces surprising results: Given the msacm resampler, the
wave mapper will accept any PCM rate, but ADPCM only at the rate supported by
the HW. This is not round.

Back in the old days, probably every card would accept mono.

In the modern mmdevapi days, note how native winmm:wave tests report "all WINMM
formats supported" (formats=fffff) whereas my mmdeapi:render format tests
reports that AudioClient:IsFormatSupported solely supports 44100 and 48000
16bit stereo (in exclusive mode, which presumably reveals what the HW really
can), which is typical of modern cards.

Obviously, Vista-w7 close the gap and provide both resampling, channel and bit
width conversion to winmm.

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.

>so that every device supports both stereo and mono sound
Native doen't seem to do that at the mmdevapi (IsFormatSupported) level, yet
the past Vista winmm rewrite supports all formats, mono or stereo.
Native mmdevapi is documented to accept and convert 8/16 bit (verified by my
tests).

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".
Are you telling the app to use one of the enumerated & named devices or does it
simply use "default" / device -1 or 0?

Maybe winealsa should use plughw instead of hw for the enumerated devices? What
does OSS allow?

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?

>I'll work on investigating how Windows handles this type of situation.
Great. I have doubts that Wine handles WAVE_FORMAT_DIRECT etc. correctly. But
that's another story.

-- 
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.


More information about the wine-bugs mailing list