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

[Ed Wildgoose]

Attila Kinali wrote:

>On Wed, Sep 15, 2004 at 04:53:38AM +0300, Jan Knutar wrote:
> 
>  
>
>>Yes, that is another issue, however, that is different from the current issue
>>of 2 frag buffers and mplayer simply sleeping too long.
>>
>>I'd hate to think about when video decoding takes longer than audio buffer
>>time :/
>>    
>>
>
>But you have to, it's actualy the most important part.
>Playing a video with more then just enough CPU and I/O power is not
>hard, anyone can do that, even wmp. Playing a file at the edge is very
>hard, as sometimes the video steps over it. Not to fall down is all what
>matters in this case.
>  
>

No disagreement there.  However, one step at a time huh?  This patch 
addresses something that can be changed fairly simply in the main loop.  
What you ask for would have to be fixed by either using threads 
(unlikely...), or by breaking out of the video decode loop periodically 
(tricky) to check if we have overstepped our audio buffer time.

I think that what you want is a very hard thing to fix in practice.  
Much easier I think to suggest that the user finds an audio card with 
larger audio buffers if they are really so close to the limit.

...Actually another way to tackle the problem is to increase the *size* 
of my two buffers.  On my card I can go up to 8192 samples, which is 
plenty enough to survive on.  I did submit a patch to do this initially, 
but there was some resistence since this would change the audio output 
code.  At some later stage I can revisit this patch if there is 
interest, since I can see few disadvantages in having a really large 
audio output buffer (any subtle problems will be down to what happens 
when you pause or FF).  This tackles the problem from a different 
direction, and should probably sort out nearly everyone out there 
without resorting to difficult issues.  (At the moment, the audio code 
artificially restricts itself to a max of 1024 samples, and assumes it 
can allocate more buffers to compensate, this is ultimately the problem 
in my case)

What's the current state anyway?  Are you happy commiting this change 
now and adding in the suggested IF statement to make it work the same 
way as before for high framerate video?  Do you need me to resubmit the 
patch for this one liner?

As an aside, whilst working on the Mythtv JACK layer I found what is 
probably the reason why people were reporting problems with the mplayer 
Jack output.  I believe that there is now a new bio2jack lib with this 
fix in, but I haven't yet tried building it.  However, as far as I can 
see mplayer appears to rely on bio2jack being available on the machine 
to compile the Jack output plugin?  I haven't fully traced it, but this 
seems to be what is happening.  For such a simple .c file this seems a 
bit complicated for the user, I would like to ask whether in principle 
we could just include the bio2jack.c file in the mplayer distribution 
(since it's really the meat of the output layer, and only a small file.  
The lib version of the file is overkill for what is basically a small C 
file I think...?)

Ed W