DirectSound and i810 soundcards

[chrismorgan at rcn.com]

> Ove Kaaven wrote:
> > On Mon, 6 Jan 2003, Francois Gouget wrote:
> [...]
> > Note that test results from Windows XP won't be very useful for this;
> > under XP, dsound primary buffers doesn't map directly to the sound
> > hardware any more, according to MSDN. If you create and use a dsound
> > primary buffer under XP, it will just become another stream sent to XP's
> > kernel-mode sound mixer, before it gets to the hardware.
> 
> Ah that probably explains some results I've seen then. Thanks.
> 
> 
> >>I don't know why the mmap fails. I would tend to think this is a 
> >>limitation or bug of the Alsa driver since it works with the OSS driver. 
> > 
> > ALSA has resampling features. If you open the sound device at e.g. 11kHz,
> > then ALSA's OSS emulation will, instead of telling you that the chip is
> > 48kHz, install a resampling filter to convert from 11kHz to the hardware's
> > required 48kHz. Unfortunately, that filter gets in the way of direct
> > access, making an mmap fail. (In WineX we test mmap on a range of common
> > frequencies to work around this.)
> 

> Ok. That makes sense. That's sort of the opposite direction of the 
> DirectSound patch I sent to wine-patches (and which just got applied). 
> The annoying thing is that the mmap, the device format bubbling up and 
> the CreateThread are all in different places :-(
> Oh well, I'll try to come up with something. It seems hacking things to 
> make mmap succeeds is the simplest approach. But what's the best approach?
> 

Why not just stop trying to mmap the device?  XP can apparently get away without it...


>   1. if we tweak things so that the mmap call succeeds then Wine will be 
> making the resampling. And Wine is not really good at that and tends to 
> introduce audible distortion. It probably doesn't matter if you start 
> from an 8kHz signal but if you're playing a 44kHz sound...
> 
>   2. if we tweak things so that the CreateThread is done, then the 
> resampling will be done by Alsa (or whichever back-end) which will 
> presumably do it much better than us. howeve rin that case we have to 
> make the almost never used case work and I'm not sure how well it would 
> work anyway (I'm concerned about skips/cracks/pops).
> 
> To make 1. cleaner maybe we should have a Wine-specific message that 
> asks the backend to return the formats supported by the device, i.e. for 
> OSS returning an exact translation of the value returned by 
> SNDCTL_DSP_GETFMTS.
> Then if our msacm gets improved to the Jack sound format conversion 
> library we're golden... (what's the status of this btw?)
> 

I think we should stick with what we currently have where we try to open the device with the app requested audio output format and then fallback to having the msacm do the conversion to a supported format if necessary.  Why not use the existing waveOutGetDevCaps() message to get the device capabilities?

Afaik the library is mostly done.  I haven't taken any look at how to integrate it into wine yet though, been quite busy with other jack audio related work lately.  I was planning on working on this though.

Chris