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
c@groovy.org
_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
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
c@groovy.org
_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel