All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Liontooth <lionteeth@cogweb.net>
To: hermann pitton <hermann-pitton@arcor.de>
Cc: linux-media@vger.kernel.org
Subject: Re: Audio drop on saa7134
Date: Mon, 14 Sep 2009 23:07:23 -0700	[thread overview]
Message-ID: <4AAF2F1B.2050206@cogweb.net> (raw)
In-Reply-To: <1252993000.3250.97.camel@pc07.localdom.local>

hermann pitton wrote:
> Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth:
>   
>> hermann pitton wrote:
>>     
>>> Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth:
>>>   
>>>       
>>>> <snip>
>>>> We've been using saa7135 cards for several years with relatively few 
>>>> incidents, but they occasionally drop audio.
>>>> I've been unable to find any pattern in the audio drops, so I haven't 
>>>> reported it -- I have no way to reproduce the error, but it happens 
>>>> regularly, affecting between 3 and 5% of recordings. Audio will 
>>>> sometimes drop in the middle of a recording and then resume, or else 
>>>> work fine on the next recording.
>>>>     
>>>>         
>>> Hi Dave,
>>>
>>> hmm, losing audio on three to five percent of the recordings is a lot!
>>>
>>> When we started to talk to each other, we had only saa7134 PAL/SECAM
>>> devices over here.
>>>
>>> That has changed a lot, but still no System-M here.
>>>
>>> The kernel thread detecting audio on saa7133/35/31e behaves different
>>> from the one on saa7134.
>>>
>>> But if you let it run with audio_debug=1, you should have something in
>>> the logs when losing the audio. The kernel audio detection thread must
>>> have been started without success or id find the right thing again. I
>>> would assume caused by a weaker signal in between.
>>>
>>> Do you know about the insmod option audio_ddep?
>>>
>>> It is pretty hidden and I almost must look it up myself in the code.
>>>
>>> Cheers,
>>> Hermann
>>>
>>>   
>>>       
>> OK, I'll try running with audio_debug=1. Could you clarify what you mean 
>> by "The kernel audio detection thread must have been started without 
>> success or id find the right thing again"? An audio drop can be 
>> initiated at any point in the recording. A weak signal is a good guess, 
>> but I've never noticed a correlation with video quality.
>>     
>
> You said audio sometimes recovers, than the kernel thread did detect it
> again, else failed on the pilots.
>
>   
>> I didn't know about audio_ddep -- what does it do? I'm not seeing it in 
>> modinfo.
>>     
>
> Oh, are you sure?
>
>   
My mistake -- I'm running 2.6.19 and it's there.
>> It would be fantastic to get this problem solved -- we've had to record 
>> everything in parallel to avoid loss, and still very occasionally lose 
>> sound.
>>     
>
> It could also be something else, but that is the point to start.
>
> It stops the kernel audio detection thread and tells him to believe that
> only the norm given by insmod should be assumed.
>
> It is some hex in saa7134-audio, don't know it off hand for NTSC.
>
> Wait, i'll look it up. 0x40.
>   
Thank you! I'll try turning off the audio detection thread first, and 
then run debug.

 options saa7134 card=95,95,95,95 tuner=39,39,39,39 
audio_ddep=0x40,0x40,0x40,0x40 # audio_debug=9,9,9,9

It's a production system so I may need to wait until the weekend.

Cheers,
Dave


  reply	other threads:[~2009-09-15  6:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15  2:41 Reliable work-horse capture device? David Liontooth
2009-09-15  3:08 ` Mauro Carvalho Chehab
2009-09-15  4:02   ` David Liontooth
2009-09-15  4:21     ` hermann pitton
2009-09-15  5:16       ` Audio drop on saa7134 David Liontooth
2009-09-15  5:36         ` hermann pitton
2009-09-15  6:07           ` David Liontooth [this message]
2009-09-20  8:24             ` David Liontooth
2009-09-20  9:02               ` Mauro Carvalho Chehab
2009-09-21  1:30                 ` hermann pitton
2009-09-21  7:53                   ` David Liontooth
2009-09-23  0:42                     ` hermann pitton
2009-09-21  7:40                 ` David Liontooth
2009-09-15  4:34     ` Reliable work-horse capture device? Mauro Carvalho Chehab
2009-09-15  5:03       ` David Liontooth
2009-09-15 10:39     ` Andy Walls
2009-09-15 14:48       ` David Liontooth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AAF2F1B.2050206@cogweb.net \
    --to=lionteeth@cogweb.net \
    --cc=hermann-pitton@arcor.de \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.