[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=28723

--- Comment #64 from Alexey Loukianov <mooroon2 at 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.c;hb=HEAD),
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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.