brainstorm: what are the audio stumbling blocks?

[Joerg-Cyril.Hoehle at t-systems.com]

Maarten Lankhorst wrote:

>you know how mmdevapi behaves
>Just bite the bullet and add a winepulse driver already, I'll even fix
>mine to work better if it had a chance of getting accepted

I have no objection to a winepulse driver.  Indeed we (not just me,
hopefully) now know a lot about how mmdevapi behaves, i.e. what the
driver(s) should do.

I just won't write it.  PulseAudio started with a promise that there
would be no need for a rewrite of every audio app because it would
smoothly integrate with ALSA, broke that promise with poor quality
plug-ins and the end of the story is that every app was "enhanced" to
natively talk to PulseAudio?  What a shame.
What a summed waste of every project's resources!


>with all the efforts you would have had
>a fully functioning driver by now.

I believe that working around bugs in PulseAudio/alsa_plugs only cost
part of my (and Andrew's) time.  One major part was learning mmdevapi which I
knew nothing about 8 months ago, mostly by writing tests.  Then advance
partly into DSound and winmm devices whereas before, I was simply
happy in my MCI niche.

I really hate it that the imminent release is stressing me such that I
don't find enough time to perform the usual amount of Q&A to my patches.
After all, I'm doing this work as a hobby, why suffer stress here?  I did
not decide that the time is ripe for a release and IMHO there are
still major audio issues (yet bugzilla mostly lists ancient ones).

Please go ahead and make a good pulse driver, based on what we *now*
know about mmdevapi.  It might have benefits, e.g. latency control and
session management.  Hopefully a working GetPosition and underrun
handling or else I recommend to not even start.

IMHO, it would not have been reasonable six months ago to start with >3
drivers simultaneously.  Now we know much more about the mmdevapi target,
so it makes sense nowadays.

The more drivers, the more people are needed to support them.  For
instance, wineoss has not yet received all bug fixes that went into
winealsa or winecoreaudio (e.g. GetNextPacketSize
vs. GetCurrentPadding).  Who will be there for maintenance?

Regards,
	Jörg Höhle