[linux-dvb] Audio Dropout on DVB recordings - Air2PC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 23 Mar 2005 20:09:43 -0500, Taylor Jacob <rtjacob@xxxxxxxxxxxxx> wrote:
> Quoting Blammo <blammo.doh@xxxxxxxxx>:
> 
> > I'm getting audio dropouts, part-way through a recording, which then
> > fail to correct. This leaves me with recordings which have perfect
> > video the entire length, but no audio after the point of no recovery.
> 
> This is a software issue in Myth.. There is nothing wrong with the driver..
> There are numerous threads with me answering the same thing.. USE TS MODE.. I
> even gave some temporary solutions until I get it fixed right..

I've been watching the threads on the Myth side about this issue. Most
of the "lockup" issues I was experiencing with HDTV content have gone
away in later versions of CVS.

It's the fact I've switched PS / TS, and the fact the recorded streams
don't play in mplayer either, that led me to post to this list.

I switched to TS about a week ago, and I've already lost audio on:

Boston Legal (ABC)
CSI Miami (CBS)

The resulting files are actually MISSING the audio. mplayer won't play
them. myth won't play them. There is NO audio that I can see, unless
someone tells me how to detect otherwise.

 > Closing and re-opening the card re-init's the stream, and the audio
> > returns, which makes me think this is correctable.
> 
> > I have a nice strong signal. I've tried both PS and TS mode, no change.
> 
> If your signal is so strong why do you keep loosing packets?  Is it possible you
> have a high signal level, but low SNR?

Here's 30 seconds of femon.  Is the ratio I"m getting any good?

[root@backend1 ~]# femon
using '/dev/dvb/adapter0/frontend0'
FE: Nextwave nxt2002 VSB/QAM frontend (TERRESTRIAL)
status 1f | signal fd30 | snr e21a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd90 | snr e3c0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdb0 | snr e420 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd90 | snr e420 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd40 | snr e2a6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdd0 | snr e2a6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd30 | snr e1bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd70 | snr e334 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd80 | snr e1ea | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd30 | snr e1bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd30 | snr e44e | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd80 | snr e1bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdd0 | snr e3f0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd90 | snr e44e | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdc0 | snr e420 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd70 | snr e21a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd60 | snr e1ea | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd00 | snr e2a6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdd0 | snr e3f0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fda0 | snr e304 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd60 | snr e248 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdc0 | snr e3c0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd50 | snr e420 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd10 | snr e248 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd00 | snr e2d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd10 | snr e392 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fcd0 | snr e2d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd10 | snr e18c | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd30 | snr e1bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd60 | snr e21a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd30 | snr e2d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd50 | snr e392 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd10 | snr e1bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd70 | snr e334 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fe00 | snr e21a | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fda0 | snr e1bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd80 | snr e334 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd40 | snr e334 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fdc0 | snr e304 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd60 | snr e392 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal fd90 | snr e334 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

I'm in the process of hacking up femon to dump with a timestamp in
front of every line. Then I'm going to  dump the data into RRD and
graph the signal strength. Then at least I"ll have a way to go back
and look at, say, 29 minutes into CSI, and see what happened.



[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux