[mythtv-users] chirping in recordings with pchdtv hd-3000's and 0.21

[Tom Dexter]

On Thu, Apr 10, 2008 at 7:58 PM, Patrick Wagstrom <patrick at wagstrom.net> wrote:
> I've had a stable mythtv box with dual hd-3000 cards for the last three
>  years.  After some issues with a power supply on the machine conking out
>  while recording, the cards have worked wonderfully.  Well, at least until I
>  upgraded to 0.21.
>
>  Since upgrading to 0.21, I get numerous "chirps" in my recordings; about
>  every 5 minutes or so.  These usually happen where there is some slight
>  video damage.  The errors are usually accompanied by a message in my log:
>
>  cx88[0]/2: queue is empty - first active
>  cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
>  cx88[0]/2: setting the interrupt mask
>  cx88[0]/2: [d9469600/0] cx8802_buf_queue - first active
>
>  Looking around, this error is usually caused by either not tuning a channel
>  or not having enough throughput to the drives.  The first cause is
>  eliminated because I'm watching shows, so I know I'm tuned.  The second
>  possible cause I think I can safely eliminate because my tests show my
>  drives (a sw RAID 5 array) can push 50+MB/s on writes to the drives.
>
>  The OS is Ubuntu Dapper, kernel 2.6.15-26.  Not sure if it matters, but
>  there is also a PVR-250 installed.  Nothing changed on the machine to make
>  it start doing this except the upgrade from 0.20->0.21.
>
>  Any thoughts?
>
>  --Patrick
>  _______________________________________________
>  mythtv-users mailing list
>  mythtv-users at mythtv.org
>  http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

I occasionally get corruption in my recordings (for example due to OTA
interference in bad weather)..the kind that causes temporary video
pixelation etc.

Under 0.20.2 it seemed that, if anything, these would cause slight
audio dropouts, and only rarely seemed to cause any significant audio
noise.  For some reason under 0.21 virtually any corruption like this
seems to cause full-scale audio chirps almost without fail.  I'm
seeing some of these in my frontend logs, but I have to verify if
these actually are occurring when I hear the audio chirps:

2008-04-14 21:58:55.122 [ac3 @ 0xb7384028]cplendf = 6 < cplbegf = 13
2008-04-14 21:58:55.122 [ac3 @ 0xb7384028]error parsing the audio block
2008-04-14 21:58:55.954 [ac3 @ 0xb7384028]delta bit allocation strategy reserved
2008-04-14 21:58:55.954 [ac3 @ 0xb7384028]error parsing the audio block
2008-04-14 21:58:56.240 [ac3 @ 0xb7384028]delta bit allocation strategy reserved
2008-04-14 21:58:56.240 [ac3 @ 0xb7384028]error parsing the audio block
2008-04-14 21:58:56.322 [ac3 @ 0xb7384028]delta bit allocation strategy reserved
2008-04-14 21:58:56.322 [ac3 @ 0xb7384028]error parsing the audio block
2008-04-14 21:58:56.632 [ac3 @ 0xb7384028]chbwcod = 61 > 60error
parsing the audio block
2008-04-14 21:58:56.638 [ac3 @ 0xb7384028]delta bit allocation strategy reserved
2008-04-14 21:58:56.639 [ac3 @ 0xb7384028]error parsing the audio block

It's pretty unnerving when it happens, even when watching at low volume.

I'm using HD-5500 cards by the way, but I don't think that has
anything to do with it.  Any card can get corrupted video if theres an
issue with the signal.  The audio just seems to be more susceptible to
it for some reason.

I'm not sure what's different in audio handling.  I'm running Gentoo.
The 0.21 install added the new --enable-libfaad because I have the
Gentoo aac USE flag on.  I'm using ordinary stereo out however and
don't have any digital audio pass through enabled or anything, so I
don't think that would have any affect.

I'm hoping I can come up with some way to address it.  It seems like
full scale pops could be filtered somehow.

Tom