Reliable work-horse capture device?

Reliable work-horse capture device?

[David Liontooth]

We're setting up NTSC cable television capture devices in a handfull of 
remote locations, using four devices to capture around fifty hours a day 
on each location. Capture is scripted and will be ongoing for several 
years. We want to minimize the need for human intervention.

I'm looking for advice on which capture device to use.  My main 
candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
the supported USB devices.

Are there USB devices that are sufficiently reliable to hold up under 
continuous capture for years? Are the drivers robust?

I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
now adding it to em28xx. Do any other USB device chipsets have raw 
closed captioning support?

I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
but I need analog support.

Appreciate any advice.

Dave

Re: Reliable work-horse capture device?

[Mauro Carvalho Chehab]

Hi David,

Em Mon, 14 Sep 2009 19:41:13 -0700
David Liontooth <lionteeth@cogweb.net> escreveu:

> 
> We're setting up NTSC cable television capture devices in a handfull of 
> remote locations, using four devices to capture around fifty hours a day 
> on each location. Capture is scripted and will be ongoing for several 
> years. We want to minimize the need for human intervention.
> 
> I'm looking for advice on which capture device to use.  My main 
> candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
> the supported USB devices.
> 
> Are there USB devices that are sufficiently reliable to hold up under 
> continuous capture for years? Are the drivers robust?
> 
> I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
> now adding it to em28xx. Do any other USB device chipsets have raw 
> closed captioning support?
> 
> I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
> but I need analog support.
> 
> Appreciate any advice.

If you look for stability, the most important item is to choose a good stable
server distribution, like RHEL5. You'll be better serviced than using a desktop
distro with some new (not so stable) kernel and tools.

In terms of stability, the PCI devices are generally more reliable, and, among
all drivers, bttv is the winner, since it is the older driver, so, in thesis,
more bugs were solved on it. That's the reason why several surveillance systems
are still today based on bttv. If you need a newer hardware, then you may choose
saa7134, cx88 or ivtv devices.

I don't recommend using an USB hardware for such hard usage: it will probably
have a shorter life (since it is not as ventilated as a PCI device on a
server cabinet), and you might experience troubles after long plays. In terms
of USB with analog support, em28xx driver is the more stable, and we recently
fixed some bugs on it, related to memory consumption along the time (it used to
forget to free memory, resulting on crashes, after several stream
start/stop's). 

There's a tool at v4l2-apps/test made to stress a video driver, made by
Douglas. I suggest that you should run it with the board you'll choose to be
sure that you won't have memory garbage along driver usage.

Cheers,
Mauro

Re: Reliable work-horse capture device?

[David Liontooth]

Mauro Carvalho Chehab wrote:
> Hi David,
>
> Em Mon, 14 Sep 2009 19:41:13 -0700
> David Liontooth <lionteeth@cogweb.net> escreveu:
>
>   
>> We're setting up NTSC cable television capture devices in a handfull of 
>> remote locations, using four devices to capture around fifty hours a day 
>> on each location. Capture is scripted and will be ongoing for several 
>> years. We want to minimize the need for human intervention.
>>
>> I'm looking for advice on which capture device to use.  My main 
>> candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
>> the supported USB devices.
>>
>> Are there USB devices that are sufficiently reliable to hold up under 
>> continuous capture for years? Are the drivers robust?
>>
>> I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
>> now adding it to em28xx. Do any other USB device chipsets have raw 
>> closed captioning support?
>>
>> I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
>> but I need analog support.
>>
>> Appreciate any advice.
>>     
>
> If you look for stability, the most important item is to choose a good stable
> server distribution, like RHEL5. You'll be better serviced than using a desktop
> distro with some new (not so stable) kernel and tools.
>
> In terms of stability, the PCI devices are generally more reliable, and, among
> all drivers, bttv is the winner, since it is the older driver, so, in thesis,
> more bugs were solved on it. That's the reason why several surveillance systems
> are still today based on bttv. If you need a newer hardware, then you may choose
> saa7134, cx88 or ivtv devices.
>
> I don't recommend using an USB hardware for such hard usage: it will probably
> have a shorter life (since it is not as ventilated as a PCI device on a
> server cabinet), and you might experience troubles after long plays. In terms
> of USB with analog support, em28xx driver is the more stable, and we recently
> fixed some bugs on it, related to memory consumption along the time (it used to
> forget to free memory, resulting on crashes, after several stream
> start/stop's). 
>
> There's a tool at v4l2-apps/test made to stress a video driver, made by
> Douglas. I suggest that you should run it with the board you'll choose to be
> sure that you won't have memory garbage along driver usage.
>
> Cheers,
> Mauro
>   
Thank you, Mauro! I much appreciate the advice.

I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos 
goes to Devin Heitmueller for great work on this.

As for the ventilation issue for USB devices, that may not be a serious 
obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
components, we could strip the plastic casing and mount the unit next to 
a fan inside the case.

Memory leaks would be a serious problem on the other hand; thank you for 
pointing to the stress test.

I would be happy to use bttv, but I can't find cards. I also need to 
grab audio off the PCI bus, which only some bttv cards support.

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.

Our fallback is ivtv. I was hoping to use USB so that we could get 
blades instead of 3U cases; it's also getting hard to find good 
motherboards with four PCI slots.

Cheers,
Dave

Re: Reliable work-horse capture device?

[hermann pitton]

Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth:
> Mauro Carvalho Chehab wrote:
> > Hi David,
> >
> > Em Mon, 14 Sep 2009 19:41:13 -0700
> > David Liontooth <lionteeth@cogweb.net> escreveu:
> >
> >   
> >> We're setting up NTSC cable television capture devices in a handfull of 
> >> remote locations, using four devices to capture around fifty hours a day 
> >> on each location. Capture is scripted and will be ongoing for several 
> >> years. We want to minimize the need for human intervention.
> >>
> >> I'm looking for advice on which capture device to use.  My main 
> >> candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
> >> the supported USB devices.
> >>
> >> Are there USB devices that are sufficiently reliable to hold up under 
> >> continuous capture for years? Are the drivers robust?
> >>
> >> I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
> >> now adding it to em28xx. Do any other USB device chipsets have raw 
> >> closed captioning support?
> >>
> >> I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
> >> but I need analog support.
> >>
> >> Appreciate any advice.
> >>     
> >
> > If you look for stability, the most important item is to choose a good stable
> > server distribution, like RHEL5. You'll be better serviced than using a desktop
> > distro with some new (not so stable) kernel and tools.
> >
> > In terms of stability, the PCI devices are generally more reliable, and, among
> > all drivers, bttv is the winner, since it is the older driver, so, in thesis,
> > more bugs were solved on it. That's the reason why several surveillance systems
> > are still today based on bttv. If you need a newer hardware, then you may choose
> > saa7134, cx88 or ivtv devices.
> >
> > I don't recommend using an USB hardware for such hard usage: it will probably
> > have a shorter life (since it is not as ventilated as a PCI device on a
> > server cabinet), and you might experience troubles after long plays. In terms
> > of USB with analog support, em28xx driver is the more stable, and we recently
> > fixed some bugs on it, related to memory consumption along the time (it used to
> > forget to free memory, resulting on crashes, after several stream
> > start/stop's). 
> >
> > There's a tool at v4l2-apps/test made to stress a video driver, made by
> > Douglas. I suggest that you should run it with the board you'll choose to be
> > sure that you won't have memory garbage along driver usage.
> >
> > Cheers,
> > Mauro
> >   
> Thank you, Mauro! I much appreciate the advice.
> 
> I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos 
> goes to Devin Heitmueller for great work on this.
> 
> As for the ventilation issue for USB devices, that may not be a serious 
> obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
> components, we could strip the plastic casing and mount the unit next to 
> a fan inside the case.
> 
> Memory leaks would be a serious problem on the other hand; thank you for 
> pointing to the stress test.
> 
> I would be happy to use bttv, but I can't find cards. I also need to 
> grab audio off the PCI bus, which only some bttv cards support.
> 
> 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

> Our fallback is ivtv. I was hoping to use USB so that we could get 
> blades instead of 3U cases; it's also getting hard to find good 
> motherboards with four PCI slots.
> 
> Cheers,
> Dave
> 

Audio drop on saa7134

[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.

I didn't know about audio_ddep -- what does it do? I'm not seeing it in 
modinfo.

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.

Cheers,
Dave

Re: Audio drop on saa7134

[hermann pitton]

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?

depends:        videobuf-core,videobuf-dma-sg,ir-common,i2c-core,videodev,tveeprom,v4l2-common
vermagic:       2.6.30.1 SMP preempt mod_unload
parm:           disable_ir:disable infrared remote support (int)
parm:           ir_debug:enable debug messages [IR] (int)
parm:           pinnacle_remote:Specify Pinnacle PCTV remote: 0=coloured, 1=grey (defaults to 0) (int)
parm:           ir_rc5_remote_gap:int
parm:           ir_rc5_key_timeout:int
parm:           repeat_delay:delay before key repeat started (int)
parm:           repeat_period:repeat period between keypresses when key is down (int)
parm:           disable_other_ir:disable full codes of alternative remotes from other manufacturers (int)
parm:           video_debug:enable debug messages [video] (int)
parm:           gbuffers:number of capture buffers, range 2-32 (int)
parm:           noninterlaced:capture non interlaced video (int)
parm:           secam:force SECAM variant, either DK,L or Lc (string)
parm:           vbi_debug:enable debug messages [vbi] (int)
parm:           vbibufs:number of vbi buffers, range 2-32 (int)
parm:           audio_debug:enable debug messages [tv audio] (int)
parm:           audio_ddep:audio ddep overwrite (int)
................^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
parm:           audio_clock_override:int
parm:           audio_clock_tweak:Audio clock tick fine tuning for cards with audio crystal that's slightly off (range [-1024 .. 1024]) (int)
parm:           ts_debug:enable debug messages [ts] (int)
parm:           tsbufs:number of ts buffers for read/write IO, range 2-32 (int)
parm:           ts_nr_packets:size of a ts buffers (in ts packets) (int)
parm:           i2c_debug:enable debug messages [i2c] (int)
parm:           i2c_scan:scan i2c bus at insmod time (int)
parm:           irq_debug:enable debug messages [IRQ handler] (int)
parm:           core_debug:enable debug messages [core] (int)
parm:           gpio_tracking:enable debug messages [gpio] (int)
parm:           alsa:enable/disable ALSA DMA sound [dmasound] (int)
parm:           latency:pci latency timer (int)
parm:           no_overlay:allow override overlay default (0 disables, 1 enables) [some VIA/SIS chipsets are known to have problem with overlay] (int)
parm:           video_nr:video device number (array of int)
parm:           vbi_nr:vbi device number (array of int)
parm:           radio_nr:radio device number (array of int)
parm:           tuner:tuner type (array of int)
parm:           card:card type (array of int)


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

Good Luck,
Hermann

Re: Audio drop on saa7134

[David Liontooth]

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

Re: Audio drop on saa7134

[David Liontooth]

Hi Hermann --

I ran in debug mode; results below -- and let me correct a mistake: 
these are 7134 cards, not 7135. I tried some low-profile 7135 cards, but 
got a far higher rate of audio drops and stopped using them.

David Liontooth wrote:
> 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

I added the audio_ddep value and it appears to have no effect; audio 
drops continued at the previous rate on two machines.

I removed the audio_ddep parameter and added audio_debug=9:

saa7133[4]: found at 0000:02:03.0, rev: 16, irq: 16, latency: 64, mmio: 
0xff2ff800
saa7133[4]: subsystem: 5169:0138, board: LifeView FlyVIDEO3000 
[card=2,insmod option]
saa7133[4]: board init: gpio is 39900
saa7133[4]: there are different flyvideo cards with different tuners
saa7133[4]: out there, you might have to use the tuner=<nr> insmod
saa7133[4]: option to override the default value.
tuner 4-0061: chip found @ 0xc2 (saa7133[4])
tuner 4-0061: type set to 39 (LG NTSC (newer TAPC series))
tuner 4-0061: type set to 39 (LG NTSC (newer TAPC series))
tuner 4-0063: chip found @ 0xc6 (saa7133[4])
saa7133[4]: i2c eeprom 00: 69 51 38 01 ff 28 ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]/audio: dsp write reg 0x464 = 0x000000
saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
saa7133[4]/audio: dsp write reg 0x464 = 0x000000
saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
saa7133[4]/audio: dsp write reg 0x474 = 0x000000
saa7133[4]/audio: dsp write reg 0x450 = 0x000000
saa7133[4]/audio: tvaudio thread scan start [1]
saa7133[4]/audio: scanning: B/G D/K I
saa7133[4]/audio: dsp write reg 0x454 = 0x000000
saa7133[4]/audio: dsp write reg 0x454 = 0x0000ac
saa7133[4]/audio: dsp write reg 0x464 = 0x000000
saa7133[4]/audio: dsp write reg 0x470 = 0x101010
saa7133[4]: registered device video2 [v4l2]
saa7133[4]: registered device vbi2
saa7133[4]: registered device radio2
saa7133[4]/audio: dsp write reg 0x464 = 0x000000
saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
saa7134 ALSA driver for DMA sound loaded
saa7133[0]/alsa: saa7133[0] at 0xff6b3800 irq 27 registered as card 1
saa7133[1]/alsa: saa7133[1] at 0xff6b3000 irq 28 registered as card 3
saa7133[2]/alsa: saa7133[2] at 0xff6b2800 irq 29 registered as card 5
saa7133[3]/alsa: saa7133[3] at 0xff6b2000 irq 30 registered as card 4
saa7133[4]/alsa: saa7133[4] at 0xff2ff800 irq 16 registered as card 2
saa7133[0]/audio: dsp write reg 0x46c = 0xbbbb10
saa7133[0]/audio: dsp write reg 0x464 = 0x000003
saa7133[0]/audio: tvaudio thread status: 0x100000 [no standard detected]
saa7133[0]/audio: detailed status: ############# init done
saa7133[1]/audio: tvaudio thread status: 0x100000 [no standard detected]
saa7133[1]/audio: detailed status: ############# init done
saa7133[2]/audio: tvaudio thread status: 0x100000 [no standard detected]
saa7133[2]/audio: detailed status: ############# init done
saa7133[3]/audio: tvaudio thread status: 0x100001 [B/G (in progress)]
saa7133[3]/audio: detailed status: ############# init done
saa7133[4]/audio: tvaudio thread status: 0x100000 [no standard detected]
saa7133[4]/audio: detailed status: ############# init done

When audio is detected correctly, I get this sort of thing:

Sep 18 07:00:01 prato /USR/SBIN/CRON[13590]: (tna) CMD (channel 7, 
60min, "Good Morning America", 2)
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: tvaudio thread scan 
start [32]
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: scanning: M
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 
0x101010
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: tvaudio thread scan 
start [33]
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: scanning: M
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 
0x101010
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 18 07:00:04 prato kernel: saa7133[4]/audio: tvaudio thread status: 
0x100003 [M (in progress)]
Sep 18 07:00:04 prato kernel: saa7133[4]/audio: detailed status: 
############# init done
Sep 18 07:59:57 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:59:57 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 07:59:57 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 07:59:57 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb

The pattern is a four-second initialization and a split-second 
termination as the recording ends.

When audio is dropped, I get this:

Sep 18 08:00:01 prato /USR/SBIN/CRON[21608]: (tna) CMD (channel 7, 
60min, "Good Morning America", 3)
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: tvaudio thread scan 
start [29]
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: scanning: M
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x454 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x470 = 
0x101010
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: tvaudio thread scan 
start [30]
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: scanning: M
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x454 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x470 = 
0x101010
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:00:01 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 18 08:00:04 prato kernel: saa7133[1]/audio: tvaudio thread status: 
0x100003 [M (in progress)]
Sep 18 08:00:04 prato kernel: saa7133[1]/audio: detailed status: 
############# init done
Sep 18 08:27:36 prato -- MARK --
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: tvaudio thread scan 
start [31]
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: scanning: M
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: dsp write reg 0x454 = 
0x000000
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:53:59 prato kernel: saa7133[1]/audio: dsp write reg 0x470 = 
0x101010
Sep 18 08:54:02 prato kernel: saa7133[1]/audio: tvaudio thread status: 
0x100003 [M (in progress)]
Sep 18 08:54:02 prato kernel: saa7133[1]/audio: detailed status: 
############# init done
Sep 18 08:59:57 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:59:57 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 18 08:59:57 prato kernel: saa7133[1]/audio: dsp write reg 0x464 = 
0x000000
Sep 18 08:59:57 prato kernel: saa7133[1]/audio: dsp write reg 0x46c = 
0xbbbbbb

The actual audio drop starts at 08:27:46 --

soundcheck 2009-09-18_0800_KABC_Good_Morning_America.mp3

Searching for dropped audio on Saturday September 19, 2009 at 11:36:42 
PM -- this can take several minutes

        2009-09-18_0800_KABC_Good_Morning_America.mp3

                Found dropped audio in this interval:

                00:27:46 - 00:53:59 (1573 seconds)

Unfortunately, there's no trace of the drop in the logs -- it shows only 
that the scanning restarts at 08:53:59, at which point sound recording 
resumes.

Is there anything I can do to make the problem show up when it happens?

I should also mention that I record the same program from the same RF 
feed on two different computers, and the other recording was fine. It's 
extremely unusual for both recordings to have dropped audio at the same 
time -- if that happens, it's just a signal issue and I deal with it 
accordingly.

I have no comparison data from other OSes and don't know if this is a 
Linux driver or a hardware issue.

Cheers,
Dave

Re: Audio drop on saa7134

[Mauro Carvalho Chehab]

Em Sun, 20 Sep 2009 01:24:12 -0700
David Liontooth <lionteeth@cogweb.net> escreveu:

> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb

This means mute. With this, audio will stop.

> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbb10

This means unmute.

It seems that the auto-mute code is doing some bad things for you. What happens
if you disable automute? This is a control that you can access via v4l2ctl or
on your userspace application.

Are you using the last version of the driver? I'm not seeing some debug log messages
that should be there...



Cheers,
Mauro

Re: Audio drop on saa7134

[hermann pitton]

Hi,

Am Sonntag, den 20.09.2009, 06:02 -0300 schrieb Mauro Carvalho Chehab:
> Em Sun, 20 Sep 2009 01:24:12 -0700
> David Liontooth <lionteeth@cogweb.net> escreveu:
> 
> > Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
> > Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
> 
> This means mute. With this, audio will stop.
> 
> > Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
> > Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbb10
> 
> This means unmute.
> 
> It seems that the auto-mute code is doing some bad things for you. What happens
> if you disable automute? This is a control that you can access via v4l2ctl or
> on your userspace application.
> 
> Are you using the last version of the driver? I'm not seeing some debug log messages
> that should be there...
> 
> 
> 
> Cheers,
> Mauro

despite of still 1001 messages unread, Mauro is right here.

You are also for sure not on a saa7134, likely you would not ever had a
reason to come up here on such. But the much better is to have you now.

Means, you are at least on a saa7133, not able to decode stereo TV sound
on PAL and SECAM systems, vice versa counts for the saa7134 on SYSTEM-M.

The automute is for convenience of the users, say not to have loud noise
on channel switching. It is also controlled by different registers for
analog sound and PCI dma sound.

If debugging those issues, one more thing to mention is that external
video in without audio will kick in mute on those cards too at the first
round.

It should be possible to disable all such funny stuff on production
systems, pleasant for the average user's conditions, and then see if
anything should still remain.

On bad mobos, needing PCI quirks and other such stuff, we are likely not
any further than what you have seen on bttv previously, but in 99.9
percent of the known cases it seems to work.

Else Mauro again is right, even audio_debug = 1 should deliver the
related mute ioctl prints.

Cheers,
Hermann

Re: Audio drop on saa7134

[David Liontooth]

hermann pitton wrote:
> Hi,
>
> Am Sonntag, den 20.09.2009, 06:02 -0300 schrieb Mauro Carvalho Chehab:
>   
>> Em Sun, 20 Sep 2009 01:24:12 -0700
>> David Liontooth <lionteeth@cogweb.net> escreveu:
>>
>>     
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
>>>       
>> This means mute. With this, audio will stop.
>>
>>     
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbb10
>>>       
>> This means unmute.
>>
>> It seems that the auto-mute code is doing some bad things for you. What happens
>> if you disable automute? This is a control that you can access via v4l2ctl or
>> on your userspace application.
>>
>> Are you using the last version of the driver? I'm not seeing some debug log messages
>> that should be there...
>>
>>
>>
>> Cheers,
>> Mauro
>>     
>
> despite of still 1001 messages unread, Mauro is right here.
>
> You are also for sure not on a saa7134, likely you would not ever had a
> reason to come up here on such. But the much better is to have you now.
>   
lspci says

00:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 
Video Broadcast Decoder (rev 10)

The cards apparently have the saa7133HL-v101 chip. Are you suggesting 
the saa7134 would be better?
> Means, you are at least on a saa7133, not able to decode stereo TV sound
> on PAL and SECAM systems, vice versa counts for the saa7134 on SYSTEM-M.
>   
I'm recording NTSC -- are you saying the saa7133 should be able to 
decode stereo on NTSC?

If "vice versa" for the saa7134, does that mean this chip is not able to 
decode stereo on NTSC?

Sorry, I don't know what SYSTEM-M is in this context.

If you could help me find a chip that avoids this audio drop problem, 
that would be great.
> The automute is for convenience of the users, say not to have loud noise
> on channel switching. 
I see. That's irrelevant for my purposes; the channels are switched 
before the recording starts.
> It is also controlled by different registers for
> analog sound and PCI dma sound.
>   
I'm using PCI dma sound.
> If debugging those issues, one more thing to mention is that external
> video in without audio will kick in mute on those cards too at the first
> round.
>
> It should be possible to disable all such funny stuff on production
> systems, pleasant for the average user's conditions, and then see if
> anything should still remain.
>
> On bad mobos, needing PCI quirks and other such stuff, we are likely not
> any further than what you have seen on bttv previously, but in 99.9
> percent of the known cases it seems to work.
>
> Else Mauro again is right, even audio_debug = 1 should deliver the
> related mute ioctl prints.
>   
I see -- it may be a couple of weeks before I can run tests on a more 
recent kernel, but I'll do that if turning off audiomute doesn't solve 
the problem.

Cheers,
Dave

Re: Audio drop on saa7134

[hermann pitton]

Hi David,

Am Montag, den 21.09.2009, 00:53 -0700 schrieb David Liontooth: 
> hermann pitton wrote:
> > Hi,
> >
> > Am Sonntag, den 20.09.2009, 06:02 -0300 schrieb Mauro Carvalho Chehab:
> >   
> >> Em Sun, 20 Sep 2009 01:24:12 -0700
> >> David Liontooth <lionteeth@cogweb.net> escreveu:
> >>
> >>     
> >>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
> >>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
> >>>       
> >> This means mute. With this, audio will stop.
> >>
> >>     
> >>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
> >>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbb10
> >>>       
> >> This means unmute.
> >>
> >> It seems that the auto-mute code is doing some bad things for you. What happens
> >> if you disable automute? This is a control that you can access via v4l2ctl or
> >> on your userspace application.
> >>
> >> Are you using the last version of the driver? I'm not seeing some debug log messages
> >> that should be there...
> >>
> >>
> >>
> >> Cheers,
> >> Mauro
> >>     
> >
> > despite of still 1001 messages unread, Mauro is right here.
> >
> > You are also for sure not on a saa7134, likely you would not ever had a
> > reason to come up here on such. But the much better is to have you now.
> >   
> lspci says
> 
> 00:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 
> Video Broadcast Decoder (rev 10)
> 
> The cards apparently have the saa7133HL-v101 chip. Are you suggesting 
> the saa7134 would be better?

no, you can't use a saa7134 on System-M without additional audio
decoder. You should know better, since you helped a lot to get Closed
Captions working on saa7133/35/31e.

> > Means, you are at least on a saa7133, not able to decode stereo TV sound
> > on PAL and SECAM systems, vice versa counts for the saa7134 on SYSTEM-M.
> >   
> I'm recording NTSC -- are you saying the saa7133 should be able to 
> decode stereo on NTSC?

Yes, of course, but a saa7134 can't. Only the saa7135 and saa7131e chips
can do global stereo audio on that driver.

> If "vice versa" for the saa7134, does that mean this chip is not able to 
> decode stereo on NTSC?

Yes.

> Sorry, I don't know what SYSTEM-M is in this context.

You will find "NTSC" tuners also in South America.
For video they use some PAL, but for audio System-M.

A different example you can find in South Korea.
For video they use NTSC, but for audio dual FM (A2).

> If you could help me find a chip that avoids this audio drop problem, 
> that would be great.
> > The automute is for convenience of the users, say not to have loud noise
> > on channel switching. 
> I see. That's irrelevant for my purposes; the channels are switched 
> before the recording starts.
> > It is also controlled by different registers for
> > analog sound and PCI dma sound.
> >   
> I'm using PCI dma sound.
> > If debugging those issues, one more thing to mention is that external
> > video in without audio will kick in mute on those cards too at the first
> > round.
> >
> > It should be possible to disable all such funny stuff on production
> > systems, pleasant for the average user's conditions, and then see if
> > anything should still remain.
> >
> > On bad mobos, needing PCI quirks and other such stuff, we are likely not
> > any further than what you have seen on bttv previously, but in 99.9
> > percent of the known cases it seems to work.
> >
> > Else Mauro again is right, even audio_debug = 1 should deliver the
> > related mute ioctl prints.
> >   
> I see -- it may be a couple of weeks before I can run tests on a more 
> recent kernel, but I'll do that if turning off audiomute doesn't solve 
> the problem.
> 
> Cheers,
> Dave

Is it really still over the air?

We don't have any such anymore, only cable TV from satellites back
modulated as RF input into their network in best case. Is very stable.

We are not alone and depend also of work done by others.

Generally speaking, your stuff should be sufficient already, but without
having NTSC here, hm maybe some AFN stuff is still active, you are
somewhat on your own again.

To back up your kernel's modules media folder, install recent stuff for
some testing, and if not pleased, delete the recent media folder, copy
the old media folder back into place and run "depmod -a" once should be
not that hard.

Lots of small bugs in between ;)

Cheers,
Hermann

Re: Audio drop on saa7134

[David Liontooth]

Mauro Carvalho Chehab wrote:
> Em Sun, 20 Sep 2009 01:24:12 -0700
> David Liontooth <lionteeth@cogweb.net> escreveu:
>
>   
>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
>>     
>
> This means mute. With this, audio will stop.
>
>   
>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbb10
>>     
>
> This means unmute.
>
> It seems that the auto-mute code is doing some bad things for you. What happens
> if you disable automute? This is a control that you can access via v4l2ctl or
> on your userspace application.
>   
Ah, great -- I added "v4lctl -c /dev/video$DEV setattr automute off" to 
the script and verified it works.

Is there a way to turn off the automute on module insertion?

I don't see a lot of difference -- during the initialization, audio is 
still turned off several times, and then left on:

Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: tvaudio thread scan 
start [8]
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: scanning: M
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 
0x101010
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: tvaudio thread scan 
start [9]
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: scanning: M
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x0000c0
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 
0x101010
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbb10
Sep 21 00:25:22 prato kernel: saa7133[4]/audio: tvaudio thread status: 
0x100003 [M (in progress)]
Sep 21 00:25:22 prato kernel: saa7133[4]/audio: detailed status: 
############# init done

And then audio is turned off again at the end of the recording:

Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb
Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x000000
Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbbbbbb

I'll run with audiomute off for a while and see if it makes a difference 
for the audio drops -- it seems a plausible cause.
> Are you using the last version of the driver? I'm not seeing some debug log messages
> that should be there...
>   
I'm still running 2.6.19.1 and 2.6.20.11 on these production machines -- 
if it works, don't fix it.  If there's a clear reason to upgrade, of 
course I'll do that.

It would be a huge relief to discover the audio drops is a driver issue 
that can be fixed with a simple setting.

Cheers,
Dave

Re: Reliable work-horse capture device?

[Mauro Carvalho Chehab]

Em Mon, 14 Sep 2009 21:02:52 -0700
David Liontooth <lionteeth@cogweb.net> escreveu:

> As for the ventilation issue for USB devices, that may not be a serious 
> obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
> components, we could strip the plastic casing and mount the unit next to 
> a fan inside the case.

Yes, this may work.

Don't forget that, if you use USB devices, you'll probably need one separate USB
buses per each device, due to USB limits in terms of the maximum number of isoc
packets per second. If you don't require high quality, you could try to use
a format that requires less than 16 bits per pixel or 320x240 pixels, in order
to have more than one device per bus.

> I would be happy to use bttv, but I can't find cards. I also need to 
> grab audio off the PCI bus, which only some bttv cards support.
> 
> 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.

saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug
somewhere there.

> Our fallback is ivtv. I was hoping to use USB so that we could get 
> blades instead of 3U cases; it's also getting hard to find good 
> motherboards with four PCI slots.

The current best relation in terms of slots is the new cx25821. It has 8
simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner,
this design could be very interesting. The driver was written by Conexant, and
it is not yet present on any distribution (I just committed it today - at
staging - since it needs some cleanups to match kernel CodingStyle).



Cheers,
Mauro

Re: Reliable work-horse capture device?

[David Liontooth]

Mauro Carvalho Chehab wrote:
> Em Mon, 14 Sep 2009 21:02:52 -0700
> David Liontooth <lionteeth@cogweb.net> escreveu:
>
>   
>> As for the ventilation issue for USB devices, that may not be a serious 
>> obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
>> components, we could strip the plastic casing and mount the unit next to 
>> a fan inside the case.
>>     
>
> Yes, this may work.
>
> Don't forget that, if you use USB devices, you'll probably need one separate USB
> buses per each device, due to USB limits in terms of the maximum number of isoc
> packets per second. If you don't require high quality, you could try to use
> a format that requires less than 16 bits per pixel or 320x240 pixels, in order
> to have more than one device per bus.
>   
Thanks for pointing this out.
>   
>> I would be happy to use bttv, but I can't find cards. I also need to 
>> grab audio off the PCI bus, which only some bttv cards support.
>>
>> 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.
>>     
>
> saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug
> somewhere there.
>   
Interesting idea -- anything I can do to debug?
>   
>> Our fallback is ivtv. I was hoping to use USB so that we could get 
>> blades instead of 3U cases; it's also getting hard to find good 
>> motherboards with four PCI slots.
>>     
>
> The current best relation in terms of slots is the new cx25821. It has 8
> simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner,
> this design could be very interesting. The driver was written by Conexant, and
> it is not yet present on any distribution (I just committed it today - at
> staging - since it needs some cleanups to match kernel CodingStyle).
>   
Wow, that's great to get support for this powerful device. We do need 
tuners, though -- we're capturing straight from RF television cable. 
Otherwise a beautiful product, even with h264 compression, which is what 
we need.

Cheers,
Dave

Re: Reliable work-horse capture device?

[Andy Walls]

On Mon, 2009-09-14 at 21:02 -0700, David Liontooth wrote:
> Mauro Carvalho Chehab wrote:
> > Hi David,
> >
> > Em Mon, 14 Sep 2009 19:41:13 -0700
> > David Liontooth <lionteeth@cogweb.net> escreveu:
> >
> >   
> >> We're setting up NTSC cable television capture devices in a handfull of 
> >> remote locations, using four devices to capture around fifty hours a day 
> >> on each location. Capture is scripted and will be ongoing for several 
> >> years. We want to minimize the need for human intervention.
> >>
> >> I'm looking for advice on which capture device to use.  My main 
> >> candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
> >> the supported USB devices.
> >>
> >> Are there USB devices that are sufficiently reliable to hold up under 
> >> continuous capture for years? Are the drivers robust?
> >>
> >> I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
> >> now adding it to em28xx. Do any other USB device chipsets have raw 
> >> closed captioning support?
> >>
> >> I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
> >> but I need analog support.
> >>
> >> Appreciate any advice.
> >>     
> >
> > If you look for stability, the most important item is to choose a good stable
> > server distribution, like RHEL5. You'll be better serviced than using a desktop
> > distro with some new (not so stable) kernel and tools.
> >
> > In terms of stability, the PCI devices are generally more reliable, and, among
> > all drivers, bttv is the winner, since it is the older driver, so, in thesis,
> > more bugs were solved on it. That's the reason why several surveillance systems
> > are still today based on bttv. If you need a newer hardware, then you may choose
> > saa7134, cx88 or ivtv devices.
> >
> > I don't recommend using an USB hardware for such hard usage: it will probably
> > have a shorter life (since it is not as ventilated as a PCI device on a
> > server cabinet), and you might experience troubles after long plays. In terms
> > of USB with analog support, em28xx driver is the more stable, and we recently
> > fixed some bugs on it, related to memory consumption along the time (it used to
> > forget to free memory, resulting on crashes, after several stream
> > start/stop's). 
> >
> > There's a tool at v4l2-apps/test made to stress a video driver, made by
> > Douglas. I suggest that you should run it with the board you'll choose to be
> > sure that you won't have memory garbage along driver usage.
> >
> > Cheers,
> > Mauro
> >   
> Thank you, Mauro! I much appreciate the advice.
> 
> I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos 
> goes to Devin Heitmueller for great work on this.
> 
> As for the ventilation issue for USB devices, that may not be a serious 
> obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
> components, we could strip the plastic casing and mount the unit next to 
> a fan inside the case.
> 
> Memory leaks would be a serious problem on the other hand; thank you for 
> pointing to the stress test.
> 
> I would be happy to use bttv, but I can't find cards. I also need to 
> grab audio off the PCI bus, which only some bttv cards support.
> 
> 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.
> 
> Our fallback is ivtv. I was hoping to use USB so that we could get 
> blades instead of 3U cases; it's also getting hard to find good 
> motherboards with four PCI slots.


I will point out that, for a fallback position, the cx18 driver also
performs very reliably with essentially the same feature set as ivtv
(since it started out as a cut and paste from ivtv).

The HVR-1600 is the card with which I do most of my testing.  It is a
PCI bus device and can perform analog (with VBI) and digital capture
simultaneously, but not 2 analog streams simultaneously.  I know of two
users who have at least 3 of these boards in one machine.  (I mention
the HVR-1600, in case you have a hard time finding the PVR-500 or
similar analog only cards.)

Of course for you, it sounds like one analog capture device per PCI slot
is suboptimal.  From a bus throughput perspective, I'd assume you'd
really want a multiple analog input PCI or PCIe capture card, that could
do compression on board.

Regards,
Andy

> Cheers,
> Dave

Re: Reliable work-horse capture device?

[David Liontooth]

Andy Walls wrote:
> On Mon, 2009-09-14 at 21:02 -0700, David Liontooth wrote:
>   
>> Mauro Carvalho Chehab wrote:
>>     
>>> Hi David,
>>>
>>> Em Mon, 14 Sep 2009 19:41:13 -0700
>>> David Liontooth <lionteeth@cogweb.net> escreveu:
>>>
>>>   
>>>       
>>>> We're setting up NTSC cable television capture devices in a handfull of 
>>>> remote locations, using four devices to capture around fifty hours a day 
>>>> on each location. Capture is scripted and will be ongoing for several 
>>>> years. We want to minimize the need for human intervention.
>>>>
>>>> I'm looking for advice on which capture device to use.  My main 
>>>> candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
>>>> the supported USB devices.
>>>>
>>>> Are there USB devices that are sufficiently reliable to hold up under 
>>>> continuous capture for years? Are the drivers robust?
>>>>
>>>> I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
>>>> now adding it to em28xx. Do any other USB device chipsets have raw 
>>>> closed captioning support?
>>>>
>>>> I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
>>>> but I need analog support.
>>>>
>>>> Appreciate any advice.
>>>>     
>>>>         
>>> If you look for stability, the most important item is to choose a good stable
>>> server distribution, like RHEL5. You'll be better serviced than using a desktop
>>> distro with some new (not so stable) kernel and tools.
>>>
>>> In terms of stability, the PCI devices are generally more reliable, and, among
>>> all drivers, bttv is the winner, since it is the older driver, so, in thesis,
>>> more bugs were solved on it. That's the reason why several surveillance systems
>>> are still today based on bttv. If you need a newer hardware, then you may choose
>>> saa7134, cx88 or ivtv devices.
>>>
>>> I don't recommend using an USB hardware for such hard usage: it will probably
>>> have a shorter life (since it is not as ventilated as a PCI device on a
>>> server cabinet), and you might experience troubles after long plays. In terms
>>> of USB with analog support, em28xx driver is the more stable, and we recently
>>> fixed some bugs on it, related to memory consumption along the time (it used to
>>> forget to free memory, resulting on crashes, after several stream
>>> start/stop's). 
>>>
>>> There's a tool at v4l2-apps/test made to stress a video driver, made by
>>> Douglas. I suggest that you should run it with the board you'll choose to be
>>> sure that you won't have memory garbage along driver usage.
>>>
>>> Cheers,
>>> Mauro
>>>   
>>>       
>> Thank you, Mauro! I much appreciate the advice.
>>
>> I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos 
>> goes to Devin Heitmueller for great work on this.
>>
>> As for the ventilation issue for USB devices, that may not be a serious 
>> obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
>> components, we could strip the plastic casing and mount the unit next to 
>> a fan inside the case.
>>
>> Memory leaks would be a serious problem on the other hand; thank you for 
>> pointing to the stress test.
>>
>> I would be happy to use bttv, but I can't find cards. I also need to 
>> grab audio off the PCI bus, which only some bttv cards support.
>>
>> 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.
>>
>> Our fallback is ivtv. I was hoping to use USB so that we could get 
>> blades instead of 3U cases; it's also getting hard to find good 
>> motherboards with four PCI slots.
>>     
>
>
> I will point out that, for a fallback position, the cx18 driver also
> performs very reliably with essentially the same feature set as ivtv
> (since it started out as a cut and paste from ivtv).
>
> The HVR-1600 is the card with which I do most of my testing.  It is a
> PCI bus device and can perform analog (with VBI) and digital capture
> simultaneously, but not 2 analog streams simultaneously.  I know of two
> users who have at least 3 of these boards in one machine.  (I mention
> the HVR-1600, in case you have a hard time finding the PVR-500 or
> similar analog only cards.)
>
> Of course for you, it sounds like one analog capture device per PCI slot
> is suboptimal.  From a bus throughput perspective, I'd assume you'd
> really want a multiple analog input PCI or PCIe capture card, that could
> do compression on board.
>
> Regards,
> Andy
>   
Thanks Andy, that's a useful suggestion for a fallback.

Cheers,
Dave