[mythtv] Not decoding enough audio data?

[Ed W]

On 26/04/2010 00:30, Jean-Yves Avenard wrote:
> Hi
>
> On 25 April 2010 09:25, Michael T. Dean<mtdean at thirdcontact.com>  wrote:
>    
>> Extra audio buffering
>> Enable this setting if MythTV is playing "crackly" audio.  This setting
>> affects digital tuners (QAM/DVB/ATSC) and hardware encoders.  It will have
>> no effect on framegrabbers (MPEG-4/RTJPEG).  MythTV will keep extra audio
>> data in its internal buffers to workaround this bug.
>>
>> was meant to work around.  Also, I think Jean-Yves Avenard has a patch that
>> fixes the actual bug.  I don't think it's gone into trunk (let alone any
>> -fixes branches), yet.
>>      
> It's the opposite flag I think we'll be able to remove "aggressive
> audio buffer"...
>    

That code has been in for a long time and always baffled me why we need 
it? It appears to make the soundcard buffer something like 4 fragments 
smaller than it's configured to be - which should be the same as simply 
requesting the same via the alsa open params?  I'm guessing, but my 
assumption is that someone previously had a problem:
- some soundcard refused to accept less than some large number of 
fragments, say 8+ (I seem to remember some cheap cards and stuff like an 
M-Audio card were locked at 8 fragments only?)
- the audio pause/reset or similar wasn't at the time flushing the 
soundcard buffers
- therefore there were very long delays when changing volume/pausing, etc??

I'm not able to look at Jean-Yves latest hg repo right now, perhaps this 
has already gone, but if not then it has always seemed to me like it 
could either go completely, or at worst be automatically enabled based 
on the return results from the card open call?

> The keep extra audio isn't part of the audio code, but part of the
> video player...
>    

Cool - that's the one I was looking for.  Is there some reason we DON'T 
want it on all the time? ie what goes wrong when enabling it always?


Cheers

Ed W