interactive dsound tests fail && winealsa problem
wine at frotz.org
wine at frotz.org
Wed Sep 24 02:26:22 CDT 2003
> 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?).
More information about the wine-devel
mailing list