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

[Ed Wildgoose]

>>I do wishes, but only if the changes get committed!!  Can someone please
>>commit this change or at least tell me what's wrong?!
>>    
>>
>
>What's wrong? I think that the problem is that it is vacation time
>and nobody that understands the changes is around.
>  
>

That's fair enough, but I was hoping to get it commited at *some* 
point.  Stuff does seem to be happening on the list at a reasonable pace 
right now.

>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!
>  
>

Agreed.  However, nothing here is made worse by my changes.  It doesn't 
change the sync code for example.  On 2.4.x kernels you just aren't 
going to be able to use a card with two buffer periods full stop (I guess)

The change only makes the code "try" to sleep for less time.  If the OS 
can't sleep for less than 20ms then we shouldn't make things any worse 
by trying I think?  However, if it's not possible to meet this 
scheduling delay then the sound card will underrun anyway because it 
barely has 20ms buffers.  This is the whole problem really.

>One more question. What is this suposed to do:
>  
>
>>-	if(delay>0.25) delay=0.25; else
>>-	if(delay<0.10) delay=0.10;
>>+	if(delay>0.25) delay=0.25;
>>    
>>
>
>At least removing min check value looks...
>troblesome.
>  
>

Turning the question around, what did the original code do?  If we 
*NEEDED* to wait *less* than 10m, then say "stuff it" and wait a whole 
10ms anyway, what will happen...? 

The delay variable is set by studying frame rate, and how much audio 
data we were able to buffer - if only goes under 10ms if the audio 
buffers don't have 10ms of data in them.  However, at the end of the day 
if you can't sleep 10ms, then you can't sleep 10ms.  Nothing worse 
appears to happen if you have a go - after all you will only even try to 
sleep tiny periods if you have no other choice?

I did try dropping the delay to 0.05, but this then stops working if 
buffers are 512 samples.  I could drop it to around 0.03-0.04 ish and 
then I would be ok again, but as you said, 0.1 is already beyond kernel 
2.4 and so if you need this level of sleep you are stuffed without 
either RTC or kernel 2.6  Nothing worse happens I think by at least trying?

One way to solve this is to have a seperate thread supplying audio data 
and then this can run at it's own best pace and simply block on writing 
audio data.  This will free the video loop  from needing to keep such a 
tight scheduling deadline.  Actually, taking this further you could move 
the video display code into it's own thread and just have the main event 
loop spin around on it's own.

...Is there any resistance to adding threads to mplayer?  Do we support 
architectures that can't handle a multi threaded player?


>P.S.
> I'm not very aware of audio stuff.
>And I am afraid there is no mainteiner of audio system.
>I wonder do you want that job?
>  
>

I am (unfortunately) becoming quite experienced at it.  My latest bit of 
code is some fixes to the RtAudio code in order to produce a cross 
platform (win + linux) impulse response room measuring application.

My level of audio understanding is reasonable Alsa, OSS level plus some 
basic Jack knowhow.  I can certainly offer to do part time maintenance 
on the audio code, but I don't have huge amounts of time.  I also only 
have a small selection of audio cards here (about 3 or 4), but I have an 
intel onboard chipset which covers the bulk of the market I think?

In conclusion I am happy to help with audio maintenance, but I would 
still prefer to commit changes via someone else who can audit them for 
logic cockups - I haven't been playing with Mplayer code for that long.

Thanks

Ed W