interactive dsound tests fail && winealsa problem

[Robert Reif]

I have hardware secondary buffers almost working with OSS and
soundcards that supports multi opens. I haven't had the time to finish
it lately but I would like to see how you handled some of the dsound.dll
issues.

wine at frotz.org wrote:

> > I'm trying to improve winealsa's sound quality, and I have found a way. And
> > I think I should make some checks in configure which I am totally unaware
> > of. If everything go smooth, the patch will be sent out within several days.
>
> A few weeks back, I got fed up with the winealsa driver not working with my app
> (and the OSS driver wasn't working for me at the time either), so I gutted it
> and rolled my own using the DMIX plugin.  PCM output is about 80% complete ATM.
> All that's left to do there is one-shot buffers, hook up volume/panning control,
> and do some tidying up of the code.  And then there's the input side....
>
> I was planning to submit it as a separate driver, since its architecture differs
> significantly from the existing one.  The main differences are:  support for
> "hardware" secondary buffers with ALSA, not Wine, doing the mixing; and the use
> of the DMIX plugin, which hopefully will allow it to play friendly with other
> DMIX-aware linux apps (e.g. mplayer, etc.).
>
> So, what I'm wondering now is:  1) Should I bother finishing it?  OSS is
> working fine for me again, and if someone else is going to fix the existing ALSA
> driver...., and 2) if the answer to question 1 is 'yes', then what is the proper
> protocol for submitting such a substantial code change.  IMO a separate driver
> would be less destabilizing (don't run it if you don't want to!), but a little
> confusing (two ALSA drivers?).