semi-obsolete audio drivers
Andrew Eikum
aeikum at codeweavers.com
Wed Mar 30 08:23:53 CDT 2011
Hi Joerg,
On 03/30/2011 06:11 AM, Joerg-Cyril.Hoehle at t-systems.com wrote:
> What do you think?
> - Why did people submit patches to one driver only when a short glance
> shows that the same bug is in the other cloned drivers too?
Well, those people might not know that there are multiple drivers, or
might not care about drivers they don't use. Not everyone is as thorough
as we'd like them to be :)
> - Is WineJack "current" and worth some effort?
> - Let the others continue to decay?
> - Remove them from git?
As for these questions, I can answer them all at once. I am currently
re-implementing MMDevAPI to use a similar driver architecture to what
WinMM uses. (Yes, this is Alexandre-approved ;-) ) I am at the point
where a merge of my work into Wine is probably two or three weeks away.
After we are satisfied with the MMDevAPI implementation, we will have to
begin work on re-implementing WinMM and DSound on top of MMDevAPI, as
Vista+ do.
So the old, unmaintained WinMM drivers, as well as the current,
maintained WinMM drivers, will be replaced by a single MMDevAPI-based
implementation of WinMM. The maintenance burden will then be to keep the
MMDevAPI drivers up-to-date, which is really the same problem you're
asking about. But the hope is to make their first implementations
_good_, and then keep them all correct and current, without letting any
bitrot.
For the record, I am planning on having ALSA (complete-ish, ALSA sucks),
OSSv4 (complete), OSX CoreAudio (in progress), and PulseAudio (not yet
started) implementations from the start. I would also like a JACK
implementation for the pro-audio crowd (plus, I love JACK), but that's
lower priority.
In any case, the MMDevAPI drivers are much simpler and better organized
than the WinMM drivers. I expect maintaining them and writing tests for
them will be a much easier task than maintaining the WinMM drivers.
Your continued work on the WinMM family is appreciated. That will help
make the re-implementation on top of MMDevAPI higher quality from the start.
Thanks,
Andrew
More information about the wine-devel
mailing list