Andy, I've recently updated my kernel since we last discussed the audio issues I was having that had fixed themselves (or were somehow fixed by your test patch to check the audio format change interrupt). Before they went away after installing your test patch, but even after using the normal module before the patch it strangely still fixed it. Well recently I updated that system to use a newer kernel, and happens it hit upon the audio issues again. I then installed the newest tree from linuxtv.org with the official tinny audio fixes, but yet still that didn't fix it. So oddly the newer fix doesn't fix it for me, haven't tried your old patch since no longer running that kernel so it's way outdated.
I did fix it, at least I'm suspecting it fixes it, by forcing the audio format to BTSC by changing the cx25840 code to use that pvr_150 fix variable which is normally set for certain cards that are buggy. This of course may just work for me in my case, since I'm just trying to get something stable for my setups. Yet I'm wondering the full implications of that, seeing if others really had tinny audio fixed with the newest patch and I'm just odd, also wanting to just let it be known that the fix doesn't seem to 100% fix it at least in my case. My logic seems to be saying that since the current official fix is more for when the startup of encoding happens, because it's being careful to do the digitizer off/on differently to not trigger the problem. Yet in my situations this audio seems to get out of wack in the middle of encoding a few hours or so. So it seems any fix in the driver like that isn't applying to my situation, may always make startup work but then in my case it seems that suddenly the audio controller thinks it sees something else and gets confused in mid encode. What I have right now with the forced BTSC mode, it shows the subtypes of mono lang2 always and works. Before it usually would show mono only and if lang2 would appear then I knew it was tinny audio, always happened that way. I'm very curious exactly why it suddenly now shows the subtypes of both yet still doesn't make the audio all messed up. The audio sounds like it's very far away in a ringing room or something when the problems happen, also I'm hoping that forcing the format is really a fix and that for some reason it doesn't still get weird audio. I suspect that is true, because from what I can tell what I have run across is a bug in the microcontroller crashing when in autodetection mode. I'm thinking that maybe your code/patch you did somehow kicked it into a better mode and somehow it remembered that for a long time till totally changing the kernel/module where it somehow reverted to the old behavior. Maybe I didn't fully reboot right, might be that somehow I was still using your old module (although I swear it wasn't), possibly my audio input from the direcTV box goes through phases where this occurs too and it was a coincidence that your patches seemed to fix it. I'm just hoping that forcing detection fixes it, also wondering why this isn't a module option to the cx25840 to set the format manually and turn off autodetection. I don't know the caveats of doing that, am curious if I'll run into any, and if it's not a possible way to fully avoid tinny audio in cases like mine. Thanks, Chris -- Chris Kennedy [email protected] _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
