[mythtv-users] Sound stutters during dark video

[Mr. Demeanour]

Michael T. Dean wrote:
> On 11/14/2006 02:46 AM, Mr. Demeanour wrote:
>> Viitasaari wrote (and I re-arranged):
>>   
>>> On Mon, 2006-11-13 at 13:56 -0500, Michael T. Dean wrote:
>>>     
>>>> On 11/13/2006 01:31 PM, Mr. Demeanour wrote:
>>>>       
>>>>> When video fades to black, the audio starts to break up. When the
>>>>> dark interval is over, the stutter goes away. This happens with
>>>>> recorded matter as well as when watching "live" TV. It doesn't
>>>>> always happen, but it does seem to be the usual case. The fade
>>>>> doesn't always have to be a full fade to black - just a period of
>>>>> relatively dark video is sometimes sufficient. The stutter
>>>>> usually lingers for about a second after the video has become
>>>>> bright again.
>>>> In mythfrontend settings, Playback settings, page 1, "General
>>>> playback":
>>>>
>>>> Extra audio buffering Enable this setting if MythTV is playing
>>>> "crackly" audio and you are using hardware encoding. This setting
>>>> will have no effect on MPEG-4 or RTJPEG video. MythTV will keep
>>>> extra audio data in its internal buffers to workaround this bug."
>>>>       
>>> Would this be related to sound and video stuttering during a channel 
>>> change?
>>>     
>> Not particularly. I have occasionally noticed momentary glitches during
>> channel-changing, but it's not the same thing. For example, the
>> phenomenon I am reporting doesn't involve any video stutter.
>>
>> Feedback: I have now set "Extra audio buffering", and spent a few hours
>> watching. I haven't noticed any of this stuttering since I made the
>> change, but I'm not yet ready to conclude that it's fixed.
>>
>> So thanks for the suggestion! However note that it wasn't at all an
>> answer to my original question, which was roughly "what is the cause of
>> this phenomenon?" - I like to understand the systems I use. In
>> particular, if I don't know what caused it, then I won't know how to
>> avoid future changes that might cause it to re-appear.
> 
> If you're not content that you've now fixed the problem, re-read the 
> help text I included above that explains what the setting controls.  
> Then, imagine what might happen if Myth didn't do what the setting makes 
> it do.  Now, you understand "the cause of this phenomenon."

Another evening's viewing reveals that the problem is much attenuated, 
but regrettably still there. On a fade or transition from a light 
picture to a dark one, there is often still a brief hiccup in the audio. 
It's pretty much acceptable to me now.

Your comment (I didn't realise that you had written this stuff!) doesn't 
explain what bug the extra buffering is supposed to be working around. 
My question arose because I don't understand why the lightness/darkness 
of the video stream should affect the audio stream at all.
> 
> If you don't, get out your text editor and start reading the code.  I 
> volunteered my time to respond with the fix for your issue.

Steady on - I didn't mean to criticize you, and I did thank you for your 
advice! I have no idea which code to start reading; and since the extra 
buffering is a workaround, it's by no means obvious to me that reading 
the code that is responsible for the extra buffering is going to 
enlighten me at all about the nature of the underlying problem.

> If you want 
> more, don't /expect/ it to be handed to you--be willing to put in your 
> own time/effort.  Then, if you have specific questions, feel free to 
> post them and /hope/ for a response.

I'm not familiar with the MythTV code at all. In due course I imagine I 
may well plunge into the source, but I'm not up for doing that until I 
have a much better understanding of the system at a component level.

Anyway, thanks again for your remarks, which have been helpful. Perhaps 
someone else has some insight into why the brightness of the video 
stream might interfere with the steadiness of the audio stream?

-- 
Jack.