semi-obsolete audio drivers

Hi,

you may have noticed that I've always sent patches for the 3 audio drivers
that I consider current and mostly up to date:
 + winealsa
 + wineoss
 + winecoreaudio
and never for one of the other ones which I consider obsolete.
 - winejack
 - wineesd
 - winenas

Sometimes I've been wondering whether I should include and take care of
winejack too, although I've neither the jack development package nor
do I know or use any software that uses Jack.

As for the others, I really consider them obsolete and never look at them.
This is not entirely satisfactory, as I've been blaming (in thoughts) the one
or other developer who in the past fixed a bug in one of the drivers without
fixing the same bug in the other ones... Code continues to diverge...

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?
 - Is WineJack "current" and worth some effort?
 - Let the others continue to decay?
 - Remove them from git?

Please don't shout for maintenance by others too early:
how much time do *you* invest in making Wine better?

Regards,
 Jörg Höhle

[Andrew Eikum]

Hi Joerg,

On 03/30/2011 06:11 AM, [e-mail] 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