sorry, forgot to reply all.
Oops, didn't see this (and gmane doesn't convert attachments, grr)
On real windows, kmixer causes all sorts of problems with high latencies and sample rate artifacts. That's why the next generation of windows is going back to a 98 type model and bypassing kmixer for hardware acceleration when the hardware supports it.
Argh, this is confusing. How do you know what the next generation of Windows (longhorn?!) will do in this regard, has it been published anywhere?
Also, what is our conversion code like compared to alsalibs? I was told it probably wasn't as good, but I don't think I've ever heard it - until I changed the default device to "default" -> "plughw:0,0" WinAMP with WinMM wouldn't play audio at all!
Finally, if we use the Win98 direct access model for Wine, what happens when people want to use emulated apps with other apps via ALSA dmix - we're bypassing the IPC mixing system so we will either block (read: hang) other programs, or Wine itself will hang waiting for the sound device to become available. Neither of these results are really acceptable, to be frank (is there a way to figure out if the device is in use without hanging?)
Longhorn audio system design info is on msdn.
Decent hardware will support multiple buffer hardware acceleration so multiple applications will get their own hardware buffers. Cheap win sound card hardware will not and suffer. 2k and xp encourage cheap hardware which is unfortunate but longhorn will take full advantage of well designed hardware so hopefully the cheap hardware approach will be discouraged in the future.
Mike Hearn wrote:
Oops, didn't see this (and gmane doesn't convert attachments, grr)
On real windows, kmixer causes all sorts of problems with high latencies and sample rate artifacts. That's why the next generation of windows is going back to a 98 type model and bypassing kmixer for hardware acceleration when the hardware supports it.
Argh, this is confusing. How do you know what the next generation of Windows (longhorn?!) will do in this regard, has it been published anywhere?
Also, what is our conversion code like compared to alsalibs? I was told it probably wasn't as good, but I don't think I've ever heard it - until I changed the default device to "default" -> "plughw:0,0" WinAMP with WinMM wouldn't play audio at all!
Finally, if we use the Win98 direct access model for Wine, what happens when people want to use emulated apps with other apps via ALSA dmix - we're bypassing the IPC mixing system so we will either block (read: hang) other programs, or Wine itself will hang waiting for the sound device to become available. Neither of these results are really acceptable, to be frank (is there a way to figure out if the device is in use without hanging?)
On Sun, 28 Mar 2004 08:33:41 -0500, Robert Reif wrote:
Longhorn audio system design info is on msdn.
Yeah, but we all know how accurate info on upcoming Windows releases is from Microsoft. I'd think twice before trusting that....
Decent hardware will support multiple buffer hardware acceleration so multiple applications will get their own hardware buffers. Cheap win sound card hardware will not and suffer. 2k and xp encourage cheap hardware which is unfortunate but longhorn will take full advantage of well designed hardware so hopefully the cheap hardware approach will be discouraged in the future.
Well, that doesn't help people with cheap hardware using Wine today. Possibly this problem is already solved by my previous patch which basically:
1) Defaults to using the software approach which works with cheap hardware 2) Adds new registry/config keys so if you want maximum performance you can go back to using "hw" and bypassing alsalib mixing/conversion.
Does that sound like a good approach that suits people using advanced/high performance audio and also people with cheap hardware or who prefer dmix over direct access? We can disguise it as a "Enable hardware accelerated audio" option in winecfg or something, with a message that this requires direct access to the sound card...
Windows and wine OSS support a mechanism for setting the hardware acceleration level. Unfortunately, wine doesn't use the exact method used by windows. I know how xp does it but I don't know how other windows versions do it.
Mike Hearn wrote:
On Sun, 28 Mar 2004 08:33:41 -0500, Robert Reif wrote:
Longhorn audio system design info is on msdn.
Yeah, but we all know how accurate info on upcoming Windows releases is from Microsoft. I'd think twice before trusting that....
Decent hardware will support multiple buffer hardware acceleration so multiple applications will get their own hardware buffers. Cheap win sound card hardware will not and suffer. 2k and xp encourage cheap hardware which is unfortunate but longhorn will take full advantage of well designed hardware so hopefully the cheap hardware approach will be discouraged in the future.
Well, that doesn't help people with cheap hardware using Wine today. Possibly this problem is already solved by my previous patch which basically:
- Defaults to using the software approach which works with cheap hardware
- Adds new registry/config keys so if you want maximum performance you
can go back to using "hw" and bypassing alsalib mixing/conversion.
Does that sound like a good approach that suits people using advanced/high performance audio and also people with cheap hardware or who prefer dmix over direct access? We can disguise it as a "Enable hardware accelerated audio" option in winecfg or something, with a message that this requires direct access to the sound card...
-
Mike Hearn -
Robert Reif