[MPlayer-dev-eng] Re: [Alsa-devel] Problem with RME 9632 and Plug

[Ed Wildgoose]

> Now with cards that have a lot of latency that sleep code will indeed 
> wait until the video frame is shown.  However, with my change it has 
> the option to do a partial sleep to avoid the buffer underrun, and 
> hence it never displays the video frame and tries to go around the 
> loop again, which then moves us forward a frame, and we get the same 
> issue next time
>
> Notice that this shouldn't have changed anything for anyone else, it's 
> purely a fix for people who would otherwise never have enough latency 
> in the audio buffers to be able to sleep for a whole video frame.  ie 
> it only affects people with frame buffers smaller than about 4 x 1024 
> (at 24fps), or 2 x 2048.
>
> It could be fudged to make the sleep check more aggressive by checking 
> audio buffer periods, but I think the answer is actually just to 
> notice when we are in fast forward mode and handle appropriately.  
> Perhaps someone could tell me whether there is already a flag set when 
> we are jumping around?  The answer then would be just to pop this into 
> the IF statement and ignore the resulting audio underrun...


OK, this patch fixes the problem of the frame not displaying while fast 
forwarding.  As suspected it only occurs when we haven't large enough 
audio buffers to sleep for a whole frame.  What I have done is check for 
frame_time_remaining at the end of the sleep period and go back to the 
audio part to keep supplying more audio until our frame becomes due.  
This should pretty much give identical source paths for long and short 
latency users now, whereas before the short latency people were getting 
a UI that was more responsive than the video!

As an aside, this main video loop is hideous... Can't we break this up 
into seperate subs which do each little bit, and end up with a main loop 
which just says:

while (!eof) {
    fill_audio_buffer()
    generate_frame()
    show_frame()
    check_ui()
    etc  
}

As it stands it's very hard to understand and follow the logic.  
Seperate threads to generate audio and video might also be a good move?

Grateful if you could look this over and hopefully commit this plus my 
previous patch (with 2048 audio buffers I guess?)

Thanks

Ed W


--- mplayer.c   2004-08-05 08:49:55.449945787 +0100
+++ 
/var/tmp/portage/mplayer-1.0_pre5-r2.orig/work/MPlayer-1.0pre5/mplayer.c    
2004-08-04 13:56:55.000000000 +0100
@@ -2244,11 +2244,7 @@

 }

-// If frame_time_remaining is non_zero then we are worried about audio 
underflow
-// and haven't paused long enough to display the frame yet.
-// Go back and supply more audio
-if (frame_time_remaining) continue;
-
+//if(!frame_time_remaining){   // should we display the frame now?

 //====================== FLIP PAGE (VIDEO BLT): =========================