[MPlayer-dev-eng] [PATCH] Prevent ao_win32 from hanging during uninit(0)

[David Bolen]

Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

> On Fri, Mar 06, 2009 at 10:46:43AM -0500, David Bolen wrote:
>> David Bolen <db3l.net at gmail.com> writes:
>> 
>> > And yes, I think your suggestion is cleaner and performs as well as mine.
>> (...)
>> > The bottom line though is that it appears to be plenty of time.
>> 
>> I may need to correct this - it seemed good in local testing, but in
>> production use, the single usec_sleep appears to be too short, as I'm
>> getting a lot of log file warnings about bytes still remaining after
>> the sleep, whereas I never got any with my counted loop other than when
>> the problem occurred.
>
> Where exactly do those warnings come from?

Sorry - it's the message in my original patch if buffered_bytes is
non-zero after it exits the delay.  (It was how I originally noted that
my change was exiting when the old code wouldn't have).

There's some risk that the callback could still trigger and update the
final buffer count just after I check it, but since the next step of
the main thread is reset the wave device, I think it's safest if
buffered_bytes is zero at that point to avoid truncation.

In reviewing things, I'm really only getting the warnings from my
faster machines (and I didn't get it on my development machine), which
lead me to believe the delay is just on the edge in terms of timing.

Maybe doing an "exact" calculation is just a little too tight for a
simple wait, and we just need a bit of a buffer.  But I don't want to
wait too long if unnecessary (the prior loop would at least exit out
early if it could) since that delays my loading of new media.

I'll have some time this evening to run some tests at the site with
the machines giving the warnings to see just how much more room is
needed.

-- David