http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #64 from Alexey Loukianov mooroon2@mail.ru 2011-12-01 05:58:30 CST --- (In reply to comment #63)
What you describe is very interesting. I've rarely used hw:0 myself as I typically use a converter plugin to allow 8000x8x1.
emu10k1 allows to use "almost arbitrary" rate/bps/chan combos doing required conversions in hw (or in kernel space - hadn't had a chance to look at emu10k1 sources) so all the test's I've been ever doing had been done like hw vs. dmix plug only vs. rate plug only vs plug+dmix combo. You'd be surprised how many gotchas and black areas are there when some perfectly correct access schemes work as expected with direct hw access and fails silently when using some alsa-lib plugins.
I've hit a new variant yesterday with dmix: Given a period of 170 frames, play Nx170 silence (N>=1), then 169 noise and wait. Underrun is entered but the noise is never heard. Dmix (or the rate converter you described) is again waiting for a full period.
I had spent some time yesterday looking at alsa-lib sources. I think that it's not dmix who causes the behavior you describe, most likely it is rate plugin again. Take a look at it's sources (http://git.alsa-project.org/?p=alsa-lib.git;a=blob_plain;f=src/pcm/pcm_rate....), grep for "start_pending" and the root cause of the problem would become obvious for you.
This reminds me of test results on vista, where padding frames are left unconsumed after underrun. Not so with w7.
Oh, thanks for reminding about this. I would try to repeat the same tests I've done for alsa-lib rate/dmix on laptop with Vista installed - today it had finally arrived at my disposition and going stay here for a next few days.
It means that the last milliseconds of any sound are not played in Wine using dmix unless the app adds silence -- which is what MSDN recommends for mmdevapi.
Well, they don't actually recommend it - they just describe a way that the provided example code is expected to work. What they actually do is append about half a buffer of silence to the end of real audio samples just to make sure that the audio engine wouldn't use stale data residing in a ring buffer and thus it "prevents unwanted sounds before the call to the IAudioClient::Stop method stops the audio stream." Actual tests using your N*period silent frames + (period-1) of noise (sine wave in my case) produce a beep on win7. Would try to test with Vista today and report back.
I'm sorry GetPosition is not ready. Yesterday I had a case with PulseAudio where the first call to snd_pcm_delay after starting to play returned -5.
Smells like -EIO. Was the call successful or it was just the delay_frames that been set to a negative value? Is it a repeatable result or not?
Second, I've had cases where PulseAudio avail_update returned ~1.8s worth of frames, much more than the 50ms buffer_size I set. So computing alsa_padding as buffer_size-avail_update does not work. I'm not amused.
Certainly it is a bug in pulse alsa-plugin. Yeah, ALSA codebase is not the finest thing ever by itself, but bugs in PA-related stuff sometimes make me rage (you know, spending several days debugging just to find out that it's yet another PA-related bug I have to invent a workaround for).
Back on topic, in any case we need some data source from the ALSA part of a world to get an idea about current padding and/or delay. The fact that reported avail_update and delay values can't be always trusted gives us a misery but there's not too much at all we can do about it except for filing-out bug reports to alsa and/or PA bug trackers.