|
I recently upgraded to the 2.6.12 SMP kernel and with it came the new
0.4.5 ivtv drivers which produces the notorious "tinny audio" on the
PVR-150. First, an overview of the system: Asus P4P800 SE mobo 2.8Ghz Intel HT Northwood Processor 784Mbs RAM PVR-250 with remote (/dev/video0) PVR-150 no remote (/dev/video1) Two external cable set top boxes using an IR-blaster each to change channels (and a custom compiled version of Lirc_serial, ledxmit_serial.) S-video in for both Using the latest firmware (16382 bytes) for the cx25840 Running the latest stable MythTV version 0.19-125 (Also runs Asterisk with a Diguim card) Through trial and error, I figured out a simple work-around that so far, seems to work %100 of the time. First, the tinny audio happened every time MythTV went from "none" to Live TV but by issuing either "ivtvctl --device=/dev/video1 -q1" and/or "ivtvctl --device=/dev/video1 -p4" after the video stream had started, the tinny audio stopped. ("-q1" selects the non-tuner audio inputs necessary for s-video and "-p4" selects the 2nd s-video input, even though the card has only one, "p3" also works) After issuing either of those commands or sometimes both sequentially, the audio cleared up and changing channels didn't bring the bad audio back. I first tried to add the ivtvctl commands to the bash script that changes channel, but the problem was that MythTV doesn't start the stream until after the change-channel script had returned and the fix only works AFTER the stream had started. The work-around was to kick off another background process that then waited a few seconds and then issued the commands. Here is the change-channel script: #!/bin/sh <all the change channel crap here> /usr/local/bin/fix_ivtv.sh & The last line kicks off the background script before returning to MythTV, which then starts up the video stream and meanwhile, fix_ivtv.sh runs: #!/bin/sh sleep 5 ivtvctl --device=/dev/video1 -q1 sleep 5 ivtvctl --device=/dev/video1 -p3 That seems to do the trick with just a few seconds of tinny audio at the start, then it cleans up. I did a direct capture using "cat /dev/video1 > test_capture.mpg" and there was no tinny audio. After reading through most of the past few months of "tinny audio" messages from this list, at least some of the problem is that MythTV is initializing ivtv with something bad that the ivtvctl commands are resetting. (Probably something the MythTV developers put in back in v0.01 to avoid a bug in ivtv, haha). If you can use the ivtvctl commands shown above to fix the tinny audio problem after the stream has started and you use an external IR-blaster to change channels, then this work-around may work. --
Sean Donovan |
_______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
