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