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

[David Bolen]

Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:

> I expressed myself badly, I meant I was wondering if the code complexity
> your patch added was reasonable for the functionality, particularly
> compared to my suggestion above. It seems to me you consider your
> approach not to be preferable to my suggestion (I think my sugggestion
> could sometimes result in truncated sound - this could probably not
> happen with the current code).

Probably not (truncated sound with the current code) but then again an
infinite hang sort of puts a damper on that...

And yes, I think your suggestion is cleaner and performs as well as mine.

I have one test case I was using that's a tiny audio-only file (grand
total of 4048 decoded audio bytes, so even less than a single buffer).
When run -loop 0 with as little output as possible an older version of
my patch did truncate it, which led to my using +2 rather than just +1
(which was my original round up).

Using your suggestion doesn't truncate it.  I'm not positive, but
suspect the reason is a combination of get_delay adding in buffersize
to the calculation - something I probably should have done in mine, as
well as perhaps get_delay's float result being scaled up for
usec_sleep while keeping precision (even though the Windows usec_sleep
then scales down to ms).

The bottom line though is that it appears to be plenty of time.

-- David

PS: Ironically for all this, I'd actually rather than everything just
get thrown out as soon as uninit() is called - e.g., uninit(1) was
used, since I'm loading a new video and want to interrupt anything
ongoing.  But it looks like it'll take a bit of work to pull that off
since by the time uninit() is called back up in mplayer there's no
difference between a slave mode "load" command and naturally falling
off the end of the current playlist entry.  Ah well, plenty of time
for that.