http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #52 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-02 06:50:04 CDT ---
I wonder if it isn't worth just ignoring the clock skew issue I'd like to submit this patch very soon
I oppose this that way. Don't understand me wrong. I'd be pleased to have my old Ubuntu Intrepid work without "pactl exit".
We already have the hack that writes no more than 3-4 periods and preferably full periods. On top of that, you add a rate-limiting hack based on a separate timer. All this just so that PA works, thus the hacks ought to be only active when PA is detected.
What I like about the current audio driver code in Wine is that it's quite straight forward and not too hard to review. We can go to any audio guy and claim: "hey, look at the Wine audio code, it's so simple, any bug must be on your side!".
But by rate-limiting writes based on any timer independent on the audio clock, you would introduce a design fault that would make any audio guy laugh at our driver and not take it seriously.
Quite to the contrary, we might simplify the code even further and solely keep the "write full periods" in the regular driver and put "but no more than 3-4" into the if (This->quirks & PULSE_QUIRK) branch. (Well, I acknowledge that not writing too much in advance minimizes noise when audio shall be paused).
so don't rely on avail_update() to determine buffer fullness
We should not work against the underlying APIs. If it's broken, it need be fixed on their side, but not kludged dramatically on the Wine side. I'm not opposed to small compatibility hacks but broken by design is not acceptable.
Sadly, I've seen no development follow from my PA bug report https://bugs.freedesktop.org/show_bug.cgi?id=46296 Somehow I have the feeling that what they need is somebody to write the tiny pure C code (not my Lisp) that demonstrates how easily PA gets into inconsistent state. Then hopefully we'll see progress...