[Bug 28517] Pikachu Volleyball stops playing sound effects

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Oct 5 11:28:58 CDT 2011


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

--- Comment #21 from Andrew Eikum <aeikum at codeweavers.com> 2011-10-05 11:28:58 CDT ---
(In reply to comment #20)
> There are two kinds of underruns, yours addresses XRUN, mine handles the case
> of devices (like dmix IIRC) which never enter XRUN state.  Both are needed.
> My general idea is that the code in Wine ought to work with both kinds of
> devices and I believe that's not hard to achieve.
> Perhaps the best is to ask for XRUN (via stop_threshold) and set silence mode,
> then cope with what I now call "soft underruns" from streaming devices without
> XRUN auto-stop, where avail_update grows > alsa_buffer_size.

Doesn't the email you linked above say that this should never happen? I thought
sw_params were supposed to work regardless of the hardware underneath.

> I believe your patch fixes several things at once, e.g. _Stop does not call
> snd_pcm_drop anymore, which caused havoc with GetPosition and waveOutRestart.
> That's good.  Reset is indeed a good place to stop the device that won't
> conflict with GetPosition.  Likewise, I found out that snd_pcm_reset does not
> only set a few vars to 0, it may also change state.
> 
> Now that you removed write() from within ReleaseBuffer, it looks like prefill
> after Start+Stop becomes trivial to handle correctly.

Perhaps I should add a call to alsa_write_data() in Start().

> >start_threshold=1
> Hmm, auto-start should perhaps be disabled because the mmdevapi is designed to
> have explicit control via _Start and _Stop.

Well, we absolutely never give ALSA data unless the MMDevAPI device is
Start()ed. Then in Stop(), we kill the feed timer, so ALSA will run out its
current buffer and stop playing. So this seems to be satisfied.

>                                             OTOH why start without data?  In
> that area I've not yet conducted enough tests to feel comfortable, esp. about
> the former if(avail < alsa_period_size) condition.
> Indeed it looks like some devices really start only when fed more than
> alsa_period_size frames (and same with OSS apparently), and that caused short
> winmm sounds to hang.

Hmm, that's a real concern. I feel that with start_threshold=1, if ALSA does
not start the device, then it's an ALSA bug. Again, sw_params should always
work. I also can't think of a sane way to work around it. Have you seen this
happen?

> BTW, regarding my 1ms/8.192ms example, it shows that in some cases, ALSA's
> defaults are no match for the typical 10ms mmdevapi period and underruns hence
> guaranteed.  But I've not yet found a receipe for what to do then (e.g.
> automatically reduce mmdevapi's period to ALSA's buffer_time if smaller?)

Another ugly problem...

-- 
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.



More information about the wine-bugs mailing list