On Sun, 2010-10-03 at 13:05 -0400, Shane Shrybman wrote:
> Hi Andy,
>
> Just wanted to follow up on our irc chat from yesterday.
>
> <awalls> hmmm. it says it detected BTSC.
> <awalls> I've got to run but can you test if aplay -f dat
> < /dev/video24 produces the channel's sound.
> <awalls> You can test it when you're runnign an MPEG capture
> simultaneously.
> <awalls> So test it for the the known good situtation and the known bad
> situation.
> <awalls> I suspect it will work the same as the audio working or not in
> the MPEG.
> <awalls> If that's the case, I'd begin to suspect the setup of the audio
> unit in the CX23416.
> <awalls> I've got to go for now.
>
> I tried the aplay -f dat < /dev/video24 thing while recording and you
> are correct, the sound followed what was in the recording.
>
> Are there some recent patches that I could try reverting that would
> affect the setup of the audio unit in CX23416?
Well, there's a lot of them unfortunately:
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/ivtv;h=ef6c178fa6ab836f508c244f3fd7fab32512c3ac;hb=refs/heads/staging/v2.6.36
from now back till February of 2010 there are quite a few changes
mucking with the delays and making CX23416 firmware API calls. Many of
those have my name or Ian's name next to them.
Hans has a bunch of infrastructure related changes which could matter as
well when it comes to controlling I2C connected devices.
The MSP34xx chip driver has also gone through changes but not as many.
Almost all appear to be realted to infrastructure changes:
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/msp3400-driver.c;h=0e412131da7cc68ab932b321e0d57076a7e92b99;hb=refs/heads/staging/v2.6.36
Using git bisect might be the best way to isolate the change that makes
things bad for you. If you can track it down, I can analyze why the
change might be causing the failure and propose a fix.
Thanks for being proactive on this. That's probably the fastest way for
you to get your problem resolved. Waiting on me isn't going to yield a
rapid result, especially since I don't have any analog broadcast signal
available to me anymore.
Regards,
Andy
> Thanks,
>
> Shane
_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> Hi Andy,
>
> Just wanted to follow up on our irc chat from yesterday.
>
> <awalls> hmmm. it says it detected BTSC.
> <awalls> I've got to run but can you test if aplay -f dat
> < /dev/video24 produces the channel's sound.
> <awalls> You can test it when you're runnign an MPEG capture
> simultaneously.
> <awalls> So test it for the the known good situtation and the known bad
> situation.
> <awalls> I suspect it will work the same as the audio working or not in
> the MPEG.
> <awalls> If that's the case, I'd begin to suspect the setup of the audio
> unit in the CX23416.
> <awalls> I've got to go for now.
>
> I tried the aplay -f dat < /dev/video24 thing while recording and you
> are correct, the sound followed what was in the recording.
>
> Are there some recent patches that I could try reverting that would
> affect the setup of the audio unit in CX23416?
Well, there's a lot of them unfortunately:
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/ivtv;h=ef6c178fa6ab836f508c244f3fd7fab32512c3ac;hb=refs/heads/staging/v2.6.36
from now back till February of 2010 there are quite a few changes
mucking with the delays and making CX23416 firmware API calls. Many of
those have my name or Ian's name next to them.
Hans has a bunch of infrastructure related changes which could matter as
well when it comes to controlling I2C connected devices.
The MSP34xx chip driver has also gone through changes but not as many.
Almost all appear to be realted to infrastructure changes:
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/msp3400-driver.c;h=0e412131da7cc68ab932b321e0d57076a7e92b99;hb=refs/heads/staging/v2.6.36
Using git bisect might be the best way to isolate the change that makes
things bad for you. If you can track it down, I can analyze why the
change might be causing the failure and propose a fix.
Thanks for being proactive on this. That's probably the fastest way for
you to get your problem resolved. Waiting on me isn't going to yield a
rapid result, especially since I don't have any analog broadcast signal
available to me anymore.
Regards,
Andy
> Thanks,
>
> Shane
_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel