[MPlayer-dev-eng] Patch: Low latency audio enhancements

[Jan Knutar]

On Wednesday 25 August 2004 14:36, Ed Wildgoose wrote:

> For each loop you load up the audio buffer, then *wait* until the frame 
> is scheduled to be displayed, then you show the frame, then check for 
> keypresses, then back to the top.
> 
> So the latency of key presses is the same as the framerate.
> 
> There is an exception to the above.  If the "wait" code notices that the 
> audio buffer would underrun while we are waiting for the frame to become 
> due, then it cuts the wait time.  However, this leads us to read the key 
> presses earlier than we would do otherwise.

[ ... ]

> Nothing particularly wrong  
> with this, but it means that if you are holding down FF, then the frame 
> never gets scheduled for display because each time around the loop we 
> cut the wait time, don't show the frame, read the key press, FF a big, 
> and go around the loop again

Actually, isn't this pretty much what happens in current mplayer, if you have,
say, 1 fps video? Then the current code in mplayer will do exactly that,
run the entire thing again and listen for keyevents and so forth?

Not that your patch makes it any worse really. It just changes one currently
existing broken behaviour to break in a different way, which one is worse
is purely subjective of course. Only noticeable on low fps video, too.

> I would propose that multiple threads are considered to simplify 
> main().  This would remove a fair bit of junk and make the code patch 
> visible.  On the other hand multiple threads create their own issues.

There's probably a few flamewars in the mailing list archives somewhere,
but to summarize, there was a fork of mplayer once to thread it, called
mplayerXP. It seems dead now.