http://bugs.winehq.org/show_bug.cgi?id=28413
--- Comment #41 from Jörg Höhle hoehle@users.sourceforge.net 2013-01-17 04:24:15 CST --- I have not looked at the patch yet. I'm afraid of a can of worms. Not serializing calls to waveOutOpen/Close means concurrent audio connections, which were a cause of trouble in the past (IIRC winealsa did not implement them). Nowadays we're not in a much better shape, because there's no central mixing in Wine for all audio output, only DSound mixes. So Wine still depends on the backend to be able to open multiple connections, e.g. pulse or dmix, but not plughw! (and I've heard people mention that the surround devices cannot be opened multiply either).
We need to think more about timing. E.g. my current thread-instead-of-timer-queue winealsa patch patiently waits until the end of the period sleep (10ms) within IAC_Release, hence each waveOutClose costs on average 5ms. That way the feeder thread can use usleep() instead of poll/select(), not waiting for the rare termination event to occur. I have not tested it with Lemmix.
Now if only OSS takes a lot of time to close() but always supports multiple connections, maybe we can put something into wineoss (not dlls/winmm) to accelerate IAC_Release? Or ask some OSS mailing list why it takes so long.