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

[Ed Wildgoose]

Attila Kinali wrote:

>On Wed, Aug 25, 2004 at 12:50:47AM +0300, Ivan Kalvachev wrote:
> 
>  
>
>>Changing syncronization code is at least tricky.
>>For example if I understand your work right, you decrease the
>>time mplayer will sleep. But on 2.4.x kernels (without RTC hack)
>>you cannot sleep for less than 20ms (schedular). This may mean that
>>your code may lead to :
>>a) bigger a-v error and jurkness
>>b) higher CPU usage because mplayer will avoid sleeping.
>>
>>Well b) is acceptable, but a) is not!
>>    
>>
>
>b) isnt acceptable either. On a low end system, you need every
>cpu cycle you can get.
>  
>

Agreed.  However, neither of the above should happen.  All we are doing 
is trying to emulate the same flow of control as would happen if we had 
larger audio buffers.  Currently if your audio buffers are smaller than 
about 4096 samples then you are stuffed, mplayer just doesnt work 
because the video code insists on sleeping until the frame becomes due 
and you run out of audio.  The patch basically just says don't sleep for 
as long and instead go back up to the top of the code and add some more 
audio.

This still leaves me with juddery video though.  My audio card driver 
only reports how many buffers are empty, not the exact audio position.  
-autosync is not working well for me either.  I'm going to fix this with 
a patch to the audio drivers which tries to detect this situation and 
then starts using clock ticks to estimate current audio position rather 
than relying on the output of the alsa free space api call.  I guess on 
average I will be out of sync by about half an audio buffer, but at 
least it will be smooth and consistent - tell me you can spot a 2ms 
frame desync anyway!!

...patch for the above to follow shortly...

Ed W