Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Jul 28, 2008, at 6:04 PM, Harry Coin wrote: Correction: Should have been v4l2-ctl -c audio_later_ii_bitrate=13 not 'v4l-ctl...' FYI: I have a PVR-150 running on an old Dell Optiplex (no PCIe, just PCI). I had no problems until upgrading to the lastest ivtv driver, and published firmware and the lastest mythtv stable on Debian Etch (2.8.18). previously I was using the same version of linux, but with the previous stable mythtv and the ivtv drivers published about one year ago. After the 'upgrade', the tinny or fuzzy or scratchy audio on the PVR-150 (and apparently the 500, a dual 150) would set in randomly, with a bias toward every other scheduled audio recording. The problem is not in playback, the distortion is encoded in the mpeg stream, it is an input issue. In my case the input is the s-video input and the RCA left/ right audio. I've proven (by hotwiring the audio leads to a separate amp/speaker setup) the supplied audio is clear into the PVR150. I can make the problem appear at will by playing new pvr-150 sourced mpeg files and disappear by playing ones recorded before the upgrade with no changes to the audio - out playback setup. (same card as source, same resolution, etc, etc.) But I've found a sort-of fix v4l2-ctl -c audio_later_ii_bitrate=13 Of some interest -- the rate listed was already at 13. Somehow the pvr-150 just began to encode audio at a very low rate. Actually setting the rate to any legal value at all restores normal audio. Thanks tons for your research into this. I have a PVR-500 that had tinny audio a couple of years ago that was fixed in the driver but started again in March/April with a big RPM update. Hopefully your find on a bad bitrate will help fix the driver itself. Keith C ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
Correction: Should have been v4l2-ctl -c audio_later_ii_bitrate=13 not 'v4l-ctl...' FYI: I have a PVR-150 running on an old Dell Optiplex (no PCIe, just PCI). I had no problems until upgrading to the lastest ivtv driver, and published firmware and the lastest mythtv stable on Debian Etch (2.8.18). previously I was using the same version of linux, but with the previous stable mythtv and the ivtv drivers published about one year ago. After the 'upgrade', the tinny or fuzzy or scratchy audio on the PVR-150 (and apparently the 500, a dual 150) would set in randomly, with a bias toward every other scheduled audio recording. The problem is not in playback, the distortion is encoded in the mpeg stream, it is an input issue. In my case the input is the s-video input and the RCA left/right audio. I've proven (by hotwiring the audio leads to a separate amp/speaker setup) the supplied audio is clear into the PVR150. I can make the problem appear at will by playing new pvr-150 sourced mpeg files and disappear by playing ones recorded before the upgrade with no changes to the audio - out playback setup. (same card as source, same resolution, etc, etc.) But I've found a sort-of fix v4l2-ctl -c audio_later_ii_bitrate=13 Of some interest -- the rate listed was already at 13. Somehow the pvr-150 just began to encode audio at a very low rate. Actually setting the rate to any legal value at all restores normal audio. Harry ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Mon, 2008-07-14 at 22:47 -0300, [EMAIL PROTECTED]
wrote:
Hi,
i have finaly had some time, i created a diff kernel tree of the 23 kernel
that works and the 25 that has the tinny audio.
i didnt notice anything that stood out, but when i reviewed cx25840-core.c
i noticed that it had what looked like code thats changing registers, with
that in mind and knowing the register thats causing issues i searched it,
and in that file i found 2 lines that where added changeing register 0x810
this is the diff block pertaining, and it just so happens to be working
with the microcontrollor as andy was saying how ever if i understand it,
it is doing the same as andy said changing the register to 1 and then to
0.
In case you want ot know more, the data sheet for the CX2584x chips is
available at:
http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
Figures 3-30 3-38 on pages 3-82 3-99 of the CX2584x data sheet show
the broadcast audio demodulator, the audio microcontroller and the I2S
I/O of a CX2584x chip.
The I2S input is labeled SA Rec (serial audio receive) in the first
diagram. Line in audio is digitized by the wm8775 chip and comes into
this input block.
The first diagram shows Tuner Sound Intermediate Frequency (SIF) audio
in on the left, which should come from the analog tuner can via the
CH2/CH3 ADC2 of the Analog Front End of the CX2584x chip.
On one of the diagrams you can see the line indicating the
microcontroller gets to muck with the control registers as well as the
cx25840 module.
The relevant audio registers are in the 0x800-0x900 range (mostly), and
documented in the later chapters of the data sheet.
@@ -251,8 +364,13 @@
}
cx25840_and_or(client, 0x401, ~0x60, 0);
cx25840_and_or(client, 0x401, ~0x60, 0x60);
+ cx25840_and_or(client, 0x810, ~0x01, 1);
- if (std V4L2_STD_525_60) {
+ if (state-radio) {
+ cx25840_write(client, 0x808, 0xf9);
+ cx25840_write(client, 0x80b, 0x00);
+ }
+ else if (std V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
that causes audio to drop out. For these models the
audio standard must be set explicitly.
@@ -281,11 +399,7 @@
cx25840_write(client, 0x80b, 0x10);
}
- if (cx25840_read(client, 0x803) 0x10) {
- /* restart audio decoder microcontroller */
- cx25840_and_or(client, 0x803, ~0x10, 0x00);
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
- }
+ cx25840_and_or(client, 0x810, ~0x01, 0);
}
static int set_input(struct i2c_client *client, enum cx25840_video_input
vid_input,
@@ -296,9 +410,22 @@
Could you e-mail or provide a download site with a complete diff of the
cx25840 module source code files using diff -up ?
another odd thing i found so far is the cx25840-firmware.c referances
#define FWFILE_CX23885 v4l-cx23885-avcore-01.fw
another firmware (which i have yet to find) and another chipset
and for cx25840-audio.c, nothing again that i would know to note, but for
the register 0x810 the order commands are run have changed, other wise
very simmiler.
The CX23885 is a PCIe device with an integrated CX2584x core. It's a
chip you won't find on an ivtv supported card and you need not worry
about it.
if you want any of these diffs, or to download a tarball off the kernel's
diff tree (made a script to build a kernel tree matching the 2 kenels and
diff the files from the 2 and put it in the new tree)
since i know very very little c/c++ im at a loss for what im looking for,
though what i will try for a start, is copy the 23 sources of the cx25840
module and over write the 25 kernel version, not sure if it will work, but
its my best way to isolate where the issue source is,
That sounds like an excellent idea to test a hypothesis. I don't know
if it will work off the top of my head though.
if some one has a
better idea please let me know, i wount be doing this that soon.
The only other thing I would try as a work around is tuning to a known
good station on the tuner and then switching over to the Composite or
Svideo input. If the microcontroller in the CX2584x is happy with a
stable SIF input from the tuner, it likely won't muck with the control
registers in the CX2584x.
Regards,
Andy
Thanks
Kevin
On Wed, 2008-07-02 at 11:25 -0300, Kevin Blair wrote:
Ok correction on modules in usage,
with the 2.6.25 kernel and bleeding edge driver the modules used are as
fallows:
# lsmod
Module Size Used by
tuner_simple 11600 1
tuner_types13376 1 tuner_simple
tda9887 8964 1
tda829011652 0
wm8775 4844 0
cx2584022988 0
tuner 21512 0
ivtv 115812 0
videodev 29248 2 tuner,ivtv
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
Hi,
i have finaly had some time, i created a diff kernel tree of the 23 kernel
that works and the 25 that has the tinny audio.
i didnt notice anything that stood out, but when i reviewed cx25840-core.c
i noticed that it had what looked like code thats changing registers, with
that in mind and knowing the register thats causing issues i searched it,
and in that file i found 2 lines that where added changeing register 0x810
this is the diff block pertaining, and it just so happens to be working
with the microcontrollor as andy was saying how ever if i understand it,
it is doing the same as andy said changing the register to 1 and then to
0.
@@ -251,8 +364,13 @@
}
cx25840_and_or(client, 0x401, ~0x60, 0);
cx25840_and_or(client, 0x401, ~0x60, 0x60);
+ cx25840_and_or(client, 0x810, ~0x01, 1);
- if (std V4L2_STD_525_60) {
+ if (state-radio) {
+ cx25840_write(client, 0x808, 0xf9);
+ cx25840_write(client, 0x80b, 0x00);
+ }
+ else if (std V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
that causes audio to drop out. For these models the
audio standard must be set explicitly.
@@ -281,11 +399,7 @@
cx25840_write(client, 0x80b, 0x10);
}
- if (cx25840_read(client, 0x803) 0x10) {
- /* restart audio decoder microcontroller */
- cx25840_and_or(client, 0x803, ~0x10, 0x00);
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
- }
+ cx25840_and_or(client, 0x810, ~0x01, 0);
}
static int set_input(struct i2c_client *client, enum cx25840_video_input
vid_input,
@@ -296,9 +410,22 @@
another odd thing i found so far is the cx25840-firmware.c referances
#define FWFILE_CX23885 v4l-cx23885-avcore-01.fw
another firmware (which i have yet to find) and another chipset
and for cx25840-audio.c, nothing again that i would know to note, but for
the register 0x810 the order commands are run have changed, other wise
very simmiler.
if you want any of these diffs, or to download a tarball off the kernel's
diff tree (made a script to build a kernel tree matching the 2 kenels and
diff the files from the 2 and put it in the new tree)
since i know very very little c/c++ im at a loss for what im looking for,
though what i will try for a start, is copy the 23 sources of the cx25840
module and over write the 25 kernel version, not sure if it will work, but
its my best way to isolate where the issue source is, if some one has a
better idea please let me know, i wount be doing this that soon.
Thanks
Kevin
On Wed, 2008-07-02 at 11:25 -0300, Kevin Blair wrote:
Ok correction on modules in usage,
with the 2.6.25 kernel and bleeding edge driver the modules used are as
fallows:
# lsmod
Module Size Used by
tuner_simple 11600 1
tuner_types13376 1 tuner_simple
tda9887 8964 1
tda829011652 0
wm8775 4844 0
cx2584022988 0
tuner 21512 0
ivtv 115812 0
videodev 29248 2 tuner,ivtv
v4l1_compat11844 1 videodev
firmware_class 6400 2 cx25840,ivtv
compat_ioctl32 896 1 ivtv
cx2341x 9476 1 ivtv
v4l2_common 8448 5 wm8775,cx25840,tuner,ivtv,cx2341x
tveeprom 10436 1 ivtv
and on the 2.6.23 kernel with internal modules loaded it lsmod is:
# lsmod
Module Size Used by
wm8775 4684 0
cx2584021712 0
ivtv 112080 0
firmware_class 6784 2 cx25840,ivtv
cx2341x10052 1 ivtv
tveeprom 13456 1 ivtv
i was looking on the wrong system and it didnt have the cx25840 module
loaded.
Under 2.6.23 you don't have the tuner modules loaded. Without those
loaded you may not have SIF coming out of the tuner to cause the audio
microcontroller firmware to try and react to SIF audio changes and
change audio settings. That could explain why 2.6.23 is not giving you
problems. Or are your tuner drivers built into the kernel under your
2.6.23 configuration (invaliding my above train of thought)?
as for the as of 30 min ago, bleeding edge driver the changes did not
resolve the tinny audio issue.
I didn't think they would. Sorry if I caused confusion talking about
how the firmware load of the cx28543 core for the cx18 driver was fixed.
I am unaware of any modifications being made for the cx28540 driver
loading firmware.
I won't be answering email until at least Monday or Tuesday. Good luck.
Regards,
Andy
Kevin
Andy Walls wrote:
On Wed, 2008-07-02 at 01:20 -0300, Kevin Blair wrote:
well i did a simpler test, since i know that with the 2.6.25 kernel
driver or bleeding edge driver i get the bad audio, and i have moved
the
testing to my slave system
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
Andy Walls wrote: On Wed, 2008-07-02 at 11:25 -0300, Kevin Blair wrote: Ok correction on modules in usage, with the 2.6.25 kernel and bleeding edge driver the modules used are as fallows: # lsmod Module Size Used by tuner_simple 11600 1 tuner_types13376 1 tuner_simple tda9887 8964 1 tda829011652 0 wm8775 4844 0 cx2584022988 0 tuner 21512 0 ivtv 115812 0 videodev 29248 2 tuner,ivtv v4l1_compat11844 1 videodev firmware_class 6400 2 cx25840,ivtv compat_ioctl32 896 1 ivtv cx2341x 9476 1 ivtv v4l2_common 8448 5 wm8775,cx25840,tuner,ivtv,cx2341x tveeprom 10436 1 ivtv and on the 2.6.23 kernel with internal modules loaded it lsmod is: # lsmod Module Size Used by wm8775 4684 0 cx2584021712 0 ivtv 112080 0 firmware_class 6784 2 cx25840,ivtv cx2341x10052 1 ivtv tveeprom 13456 1 ivtv i was looking on the wrong system and it didnt have the cx25840 module loaded. Under 2.6.23 you don't have the tuner modules loaded. Without those loaded you may not have SIF coming out of the tuner to cause the audio microcontroller firmware to try and react to SIF audio changes and change audio settings. That could explain why 2.6.23 is not giving you problems. Or are your tuner drivers built into the kernel under your 2.6.23 configuration (invaliding my above train of thought)? the tuner should be loaded, i know it was before because the 23kernel on the slave was setup before i installed sat to tune to cable tv and was never changed, after checking the config, the tuner seems to be built in cat .config | grep TUNER # CONFIG_TUNER_3036 is not set # CONFIG_TUNER_TEA5761 is not set CONFIG_VIDEO_TUNER=y it looks like the ivtv option forces the tuner module to be built and selects it as built in. Kevin as for the as of 30 min ago, bleeding edge driver the changes did not resolve the tinny audio issue. I didn't think they would. Sorry if I caused confusion talking about how the firmware load of the cx28543 core for the cx18 driver was fixed. I am unaware of any modifications being made for the cx28540 driver loading firmware. I won't be answering email until at least Monday or Tuesday. Good luck. Regards, Andy Kevin Andy Walls wrote: On Wed, 2008-07-02 at 01:20 -0300, Kevin Blair wrote: well i did a simpler test, since i know that with the 2.6.25 kernel driver or bleeding edge driver i get the bad audio, and i have moved the testing to my slave system which is not dependant on running a 2.6.25 kernel i backsteped it to a 2.6.23 kernel it was previously running, and the ivtv driver from that kernel, and i have not bin able to recreate the tinny audio issue(after for going in and out of live tv for over half an hour and no issue i dont think it will happen because usually i can get the tinny audio in 5 min of testing), the only thing that has changed is kernel and ivtv driver, all i did was boot it up on the old build of the 2.6.23 kernel which used the old setup on the slave (before i built the 2.6.25 kernel and installed the bleeding edge driver) so it would appear that something that changed since the 2.6.23 kernel driver which is causing this, correct me if im wrong. Overall, I cannot say you are wrong, you have found a causal relationship. The question is where is the problem: the ivtv driver, the cx28540 module, the i2c drivers, or the firmware image request process? (Doing a great big recursive diff of the kernel and driver source code would show you what's changed, but maybe not easily show what the problem is.) It still appears to be audio microcontroller related to me. I am unaware of anything else that could regularly tries to change the audio settings in the cx28543 chip (unless a user application is requesting it - maybe turn on ioctl debugging in ivtv to see). And since resetting that microcontroller makes the problem go away, it really stands out as an actor in the problem. Hans just made a fix to the firmware download to the AV core in the CX23418 for the cx18 driver (it has a very similar core and firmware to the CX28543). He noted that the firmware download had byte errors by doing read backs of the bytes just written to the chip. If something changed that introduces byte errors in the download of firmware to the cx28540, that could obviously cause the audio microcontroller firmware to act funny. You've found a causal relationship, but the root cause is still unknown. To find the root cause, I can only think of two methodologies: inspection and analysis of the differences between the source code version (likely a big job but it is a
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Wed, 2008-07-02 at 01:20 -0300, Kevin Blair wrote: well i did a simpler test, since i know that with the 2.6.25 kernel driver or bleeding edge driver i get the bad audio, and i have moved the testing to my slave system which is not dependant on running a 2.6.25 kernel i backsteped it to a 2.6.23 kernel it was previously running, and the ivtv driver from that kernel, and i have not bin able to recreate the tinny audio issue(after for going in and out of live tv for over half an hour and no issue i dont think it will happen because usually i can get the tinny audio in 5 min of testing), the only thing that has changed is kernel and ivtv driver, all i did was boot it up on the old build of the 2.6.23 kernel which used the old setup on the slave (before i built the 2.6.25 kernel and installed the bleeding edge driver) so it would appear that something that changed since the 2.6.23 kernel driver which is causing this, correct me if im wrong. Overall, I cannot say you are wrong, you have found a causal relationship. The question is where is the problem: the ivtv driver, the cx28540 module, the i2c drivers, or the firmware image request process? (Doing a great big recursive diff of the kernel and driver source code would show you what's changed, but maybe not easily show what the problem is.) It still appears to be audio microcontroller related to me. I am unaware of anything else that could regularly tries to change the audio settings in the cx28543 chip (unless a user application is requesting it - maybe turn on ioctl debugging in ivtv to see). And since resetting that microcontroller makes the problem go away, it really stands out as an actor in the problem. Hans just made a fix to the firmware download to the AV core in the CX23418 for the cx18 driver (it has a very similar core and firmware to the CX28543). He noted that the firmware download had byte errors by doing read backs of the bytes just written to the chip. If something changed that introduces byte errors in the download of firmware to the cx28540, that could obviously cause the audio microcontroller firmware to act funny. You've found a causal relationship, but the root cause is still unknown. To find the root cause, I can only think of two methodologies: inspection and analysis of the differences between the source code version (likely a big job but it is a deterministic process), or making some hypotheses and testing those hypotheses (smaller jobs but not guaranteed to provide an answer). Regards, Andy Kevin Andy Walls wrote: On Tue, 2008-07-01 at 01:34 -0300, Kevin Blair wrote: i dont be leave it produced the tinny audio before, but several things have changed (went from coax to svideo/rca input, since i cannot remember for the life of me the detail but the more i think about it im sure it was working fine and since on the slave downgrading fixes it, so i took a step back looked at the history i have, being i had the master system built since the beginning of march and did not have any issues with audio but i did have issues with sata_mv which i upgraded from a 2.6.24 kernel to a 2.6.25 kernel when it became stable at the beginning of may, so for almost 2 months it was running fine, based on the time i had it built and running and the time i upgraded to the .25 kernel, and few days after i installed the .25 kernel i was posting on the board with the issue. so it must be one of the changes from the 2.6.24 and the 2.6.25 kernel that is causing it. Kevin, That is an interesting bit of information. So here's a new hypothesis: The audio micontroller firmware is changing the digital audio baseband processing settings in the CX28543, corrupting the settings for line in audio, when it thinks it detects a TV audio standard change coming in from the tuner SIF audio input. If that is true, then simple solutions could be 1. stop the audio standard detection microcontroller firmware from running when you've switched to an audio input other than the tuner. or 2. connect an RF TV signal source to the tuner and tune the card to an active TV station before making the switch to the svideo or composite input. #2 is something you can try on your own to see if it eliminates the tinny audio. #1 you can try manually by commanding the ivtv driver to switch to the line in input and then stopping the audio microcontroller by setting bit 4 (bit 0 is the lsb, bit 7 is the msb) of register 0x803 of the CX28543 to 0 with v4l2-dbg. v4l2-ctl --log-status will then show the audio microcontroller as stopped. When the audio microcontroller is stopped, nothing should be automatically changing the processing of input audio. The problem with doing #1, is that it takes quite a few steps to get the audio microcontroller started properly again, and it's probably not a good idea to try it manually. If you can verify that
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Wed, 2008-07-02 at 11:10 -0300, Kevin Blair wrote: Overall, I cannot say you are wrong, you have found a causal relationship. The question is where is the problem: the ivtv driver, the cx28540 module, the i2c drivers, or the firmware image request process? (Doing a great big recursive diff of the kernel and driver source code would show you what's changed, but maybe not easily show what the problem is.) i started doing that, i dont know c++ that well so i can only go so far, but i went through the loaded modules and the diffrences that i found where minimal the changes of the order of dependant modules, and thats all i found so far. like for example --- linux-2.6.25-gentoo-r2/drivers/media/video/ivtv/ivtv.mod.c 2008-05-20 06:35:14.128780278 -0300 +++ linux-2.6.24-gentoo-r3/drivers/media/video/ivtv/ivtv.mod.c You can ignore the *.mod.c files; those are autogenerated as part of the build process for modules. You can probably focus your efforts initially for differences in the ivtv, cx25840, i2c-core, and i2c-algo-bit modules. Then if nothing strike you as really different, expand your search from there. It still appears to be audio microcontroller related to me. I am unaware of anything else that could regularly tries to change the audio settings in the cx28543 chip (unless a user application is requesting it - maybe turn on ioctl debugging in ivtv to see). And since resetting that microcontroller makes the problem go away, it really stands out as an actor in the problem. ok now this i need to clarify, ivtv picks loads and uses the cx2341x module, is the cx28544 handeled by this module or is it a seprate module(just to confirm) and both bleeding edge loads this aswell as the 2.6.23 kernel version. The CX25840, CX25841, CX25842, and CX25843 audio/video digitizer decoder chips are all handled by the cx25840 module. The CX28543 chip can handle A/V standards used the world over; the others handle subsets of the set of worldwide A/V standards. The ivtv driver will load the cx28540 module for PVR cards that have a CX2584x chip. The ivtv driver will also use the i2c-core module and usually the i2c-algo-bit module to manipulate the registers of the CX25843 via the I2C bus between the CX23416 and the CX25843. Hans just made a fix to the firmware download to the AV core in the CX23418 for the cx18 driver (it has a very similar core and firmware to the CX28543). He noted that the firmware download had byte errors by doing read backs of the bytes just written to the chip. If something changed that introduces byte errors in the download of firmware to the cx28540, that could obviously cause the audio microcontroller firmware to act funny. i looked up the changes, the changes may or may not be in the copy of the bleeding edge driver i downloaded(done the same time frame i downloaded my copy), maybe he just fixed it ill download a new copy of bleeding edge and see if it fixes it. These changes only work for the cx18 driver which has a slightly different way of manipulating the CX28543 core registers, as on the CX23418 based boards, the CX28543 core is integrated into the CX23418 chip and not a separate chip like on the CX23416 (ivtv) based cards. My point was that since it's the same CX28543 chip core and the cx18 driver had firmware download problems, it's not outside the realm of possibility that the firmware load in procedure in the cx28540 module is experiencing the same sort of problem, but not correcting the errors. Given your troubleshooting points to a change in the source somewhere introduced the symptoms, the firmware load routines in the cx28540 module are at least one place in the source code where I'm guessing things could have changed to cause the problem. Since that firmware load also relies on I2C bus transactions, changes in the i2c modules and the i2c routines in the ivtv module would be of interest as well. If you can find suspect change sets via source code differences, that'll be great. If you can't, but you can verify that shutting off the microcontroller firmware after switching to Line in 1 prevents the tinny audio problem, that'll give me enough evidence to get off the dime and look into modifications to the cx28540 module. Drivers other than ivtv use the cx28540 module, so I wouldn't want to risk breaking something without knowing we can fix something. Regards, Andy Kevin You've found a causal relationship, but the root cause is still unknown. To find the root cause, I can only think of two methodologies: inspection and analysis of the differences between the source code version (likely a big job but it is a deterministic process), or making some hypotheses and testing those hypotheses (smaller jobs but not guaranteed to provide an answer). Regards, Andy Kevin Andy Walls wrote: On Tue, 2008-07-01 at 01:34 -0300, Kevin Blair wrote: i dont be leave it
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Wed, 2008-07-02 at 11:25 -0300, Kevin Blair wrote: Ok correction on modules in usage, with the 2.6.25 kernel and bleeding edge driver the modules used are as fallows: # lsmod Module Size Used by tuner_simple 11600 1 tuner_types13376 1 tuner_simple tda9887 8964 1 tda829011652 0 wm8775 4844 0 cx2584022988 0 tuner 21512 0 ivtv 115812 0 videodev 29248 2 tuner,ivtv v4l1_compat11844 1 videodev firmware_class 6400 2 cx25840,ivtv compat_ioctl32 896 1 ivtv cx2341x 9476 1 ivtv v4l2_common 8448 5 wm8775,cx25840,tuner,ivtv,cx2341x tveeprom 10436 1 ivtv and on the 2.6.23 kernel with internal modules loaded it lsmod is: # lsmod Module Size Used by wm8775 4684 0 cx2584021712 0 ivtv 112080 0 firmware_class 6784 2 cx25840,ivtv cx2341x10052 1 ivtv tveeprom 13456 1 ivtv i was looking on the wrong system and it didnt have the cx25840 module loaded. Under 2.6.23 you don't have the tuner modules loaded. Without those loaded you may not have SIF coming out of the tuner to cause the audio microcontroller firmware to try and react to SIF audio changes and change audio settings. That could explain why 2.6.23 is not giving you problems. Or are your tuner drivers built into the kernel under your 2.6.23 configuration (invaliding my above train of thought)? as for the as of 30 min ago, bleeding edge driver the changes did not resolve the tinny audio issue. I didn't think they would. Sorry if I caused confusion talking about how the firmware load of the cx28543 core for the cx18 driver was fixed. I am unaware of any modifications being made for the cx28540 driver loading firmware. I won't be answering email until at least Monday or Tuesday. Good luck. Regards, Andy Kevin Andy Walls wrote: On Wed, 2008-07-02 at 01:20 -0300, Kevin Blair wrote: well i did a simpler test, since i know that with the 2.6.25 kernel driver or bleeding edge driver i get the bad audio, and i have moved the testing to my slave system which is not dependant on running a 2.6.25 kernel i backsteped it to a 2.6.23 kernel it was previously running, and the ivtv driver from that kernel, and i have not bin able to recreate the tinny audio issue(after for going in and out of live tv for over half an hour and no issue i dont think it will happen because usually i can get the tinny audio in 5 min of testing), the only thing that has changed is kernel and ivtv driver, all i did was boot it up on the old build of the 2.6.23 kernel which used the old setup on the slave (before i built the 2.6.25 kernel and installed the bleeding edge driver) so it would appear that something that changed since the 2.6.23 kernel driver which is causing this, correct me if im wrong. Overall, I cannot say you are wrong, you have found a causal relationship. The question is where is the problem: the ivtv driver, the cx28540 module, the i2c drivers, or the firmware image request process? (Doing a great big recursive diff of the kernel and driver source code would show you what's changed, but maybe not easily show what the problem is.) It still appears to be audio microcontroller related to me. I am unaware of anything else that could regularly tries to change the audio settings in the cx28543 chip (unless a user application is requesting it - maybe turn on ioctl debugging in ivtv to see). And since resetting that microcontroller makes the problem go away, it really stands out as an actor in the problem. Hans just made a fix to the firmware download to the AV core in the CX23418 for the cx18 driver (it has a very similar core and firmware to the CX28543). He noted that the firmware download had byte errors by doing read backs of the bytes just written to the chip. If something changed that introduces byte errors in the download of firmware to the cx28540, that could obviously cause the audio microcontroller firmware to act funny. You've found a causal relationship, but the root cause is still unknown. To find the root cause, I can only think of two methodologies: inspection and analysis of the differences between the source code version (likely a big job but it is a deterministic process), or making some hypotheses and testing those hypotheses (smaller jobs but not guaranteed to provide an answer). Regards, Andy Kevin Andy Walls wrote: On Tue, 2008-07-01 at 01:34 -0300, Kevin Blair wrote: i dont be leave it produced the tinny audio before, but several things have changed (went from coax to svideo/rca input, since i cannot remember for the life of me the
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Sun, 2008-06-29 at 23:57 -0300, Kevin Blair wrote: Humm, well ill look into adjusting the latency on the pci bus though i have played with that before with no luck but i have little to know how on doing that, Since you may have a mix of PCI and PCIe devices things are a little different than what I know for sure. So going with what I know for a straight PCI bus here's the general concept: The latency timer lets the card know how many PCI bus cycles it is allowed to stay on the PCI bus at any one time when it is acting as bus master. Aside from 1 to 3 overhead cycles of the clock cycles in a PCI bus transfer, 32 bits can be transferred in each PCI bus cycle. The PCI bus runs at 33 MHz (usually) or 30.3 nanoseconds per cycle. If a device isn't allowed enough bus cycles in it's latency timer, then it can't transfer useful amounts of data when it gets granted the bus. If a device gets a lot of bus cycles granted in its latency timer, then it can hog the bus and starve off other devices that need to do transfers. So setting latency timers is a balancing act between individual device needs and the needs of all devices in the system that could possibly be working in parallel. The device manufactures store recommendations is the PCI config data known as MIN_GRANT, the minimum latency timer value in units of 8 bus cycles (nominally 250 ns but actually 242.4 ns), and MAX_LAT the maximum time, in units of 8 bus cycles, that the device can tolerate between consecutive transfers when the device has more data to transfer than can be handled in one cycle. Note that on my PVR-150, Hauppauge has seemed to have accidentally swapped the values for MIN_GNT and MAX_LAT. but to rule out both kernel/driver/firmware conflict and to check and make sure that the drives stop failing(dont want to lose data no matter what the cause is), i disable ivtv in the master myth system so if a drive fails again it has nothing to do with ivtv, Eliminating variables is always a good troubleshooting technique. and update the system in the slave to the same kernel and ivtv version on the master and enable the tuner (i have had it disabled while trying to work this out on the master first) i found that with the same driver version and kernel version i get the same audio issue (only hardware that is simmiler is the tuner) so i tryed the register setting # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=1 register 0x810 set to 0x1 # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=0 register 0x810 set to 0x0 and it does fix the audio like set audio trick, i cant find any older version for the audio chipset You are beholden to a firmware bug then. There's not much to be done to prevent the problem from occurring (unless you feel like reverse engineering 8051 microcontroller code that manipulates undocumented ASIC hardware). If you search for older or newer Hauppauge Windows drivers for the PVR-150 and PVR-500 you may find different Mako firmware versions. From various driver upgrades for my PVR-150, I happen to have these lying around: -rw-r--r-- 1 root root 14264 2005-04-20 10:56 HcwMakoB.ROM-060418.2.0.43.24108 -rw-r--r-- 1 root root 11628 2006-10-27 16:35 HcwMakoC.ROM-050728.2.0.34.23209 -rw-r--r-- 1 root root 12282 2005-06-30 18:33 HcwMakoC.ROM-050915.2.0.35.23258 -r--r--r-- 1 root root 16382 2006-02-09 11:54 HcwMakoC.ROM-060418.2.0.43.24108 and the older version of the encoder chipset that i can find does not work. so that does not work, Since the soft reset of the CX28543 fixed the problem, the encoder isn't to blame anyway. and for the other suggestions im not sure where to start on those. For suggestion 3 of forcing the TV audio standard there is already code in linux/drivers/media/video/cx25840/cx25840-core.c:input_change() and linux/drivers/media/video/ivtv/ivtv-driver.c:ivtv_process_eeprom() for forcing the audio standard for some NTSC boards to BTSC. Look for the variable pvr150_workaround. You may be able to add your tuner model to the switch statement in ivtv-driver.c:ivtv_process_eeprom() to see if that works to solve your problem. Regards, Andy on the note on the drives its a driver issue, i couldn't even initially build the array from the live cd till i built an install with the 2.6.25 kernel, i have lots of cooling, and a 1000w power supply(planned for large power demand) as for bus and latency i have no idea where to start there but if i can identify that as an issue and i cant resolve it ill need to move to a hardware raid pcie controller Kevin Andy Walls wrote: On Sat, 2008-06-28 at 19:18 -0300, Kevin Blair wrote: ok ill give that a try, though i think i may have another direction that could be the issue, i had a suspicion but since i had a very similar issue with out ivtv affecting things i didnt think so, but due to the failure i just had and recovered from, i am suspecting it may be! i noticed a point on one of the ivtv posts
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
Humm, well ill look into adjusting the latency on the pci bus though i have played with that before with no luck but i have little to know how on doing that, but to rule out both kernel/driver/firmware conflict and to check and make sure that the drives stop failing(dont want to lose data no matter what the cause is), i disable ivtv in the master myth system so if a drive fails again it has nothing to do with ivtv, and update the system in the slave to the same kernel and ivtv version on the master and enable the tuner (i have had it disabled while trying to work this out on the master first) i found that with the same driver version and kernel version i get the same audio issue (only hardware that is simmiler is the tuner) so i tryed the register setting # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=1 register 0x810 set to 0x1 # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=0 register 0x810 set to 0x0 and it does fix the audio like set audio trick, i cant find any older version for the audio chipset and the older version of the encoder chipset that i can find does not work. so that does not work, and for the other suggestions im not sure where to start on those. on the note on the drives its a driver issue, i couldn't even initially build the array from the live cd till i built an install with the 2.6.25 kernel, i have lots of cooling, and a 1000w power supply(planned for large power demand) as for bus and latency i have no idea where to start there but if i can identify that as an issue and i cant resolve it ill need to move to a hardware raid pcie controller Kevin Andy Walls wrote: On Sat, 2008-06-28 at 19:18 -0300, Kevin Blair wrote: ok ill give that a try, though i think i may have another direction that could be the issue, i had a suspicion but since i had a very similar issue with out ivtv affecting things i didnt think so, but due to the failure i just had and recovered from, i am suspecting it may be! i noticed a point on one of the ivtv posts about ivtv and sata drives, now over all i have had little issue and nothing directly relating to that post so i didnt think it was related, but i have a raid5 array with 4 drives setup, and i have bin having an intermittent issue of one of the drives fails out (SDC) and goes non responcive, and i had an issue building the array (same issue) when building the array with an older kernel driver, but with the newer 2.6.25 kernel i dont have the building issue but every so often the drive fails and my raid array goes degraded, not a big deal and not that often, reboot remove and add drive and it rebuilds and it works fine, but now i have the temp set-audio-input fix i had enabled, dissabled for testing and i didnt enable it again, and there was a recording starting the same time the drives failed, and not just one went out but 3 out of the 4 went out, but since they simply went offline and not bad, i was able to recover with no data lost, any chance that it could be an incompatibly with the sata_mv libata driver for the chipset: 00:0e.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:0e.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:0e.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) and ivtv causeing both my drives to fail out and ivtvs bad audio? PCI bus load for disk I/O and an ivtv capture simultaneously could cause an error on the PCI bus that adversely affects disk operations. Using lspci, you should review your PCI bus latency settings against each card's MIN_GRANT (minimum desired latency timer setting) and MAX_LAT (maximum interval the device should be held off the bus), and thus the overall throughput of the shared PCI bus that each device wants when most active. You should also look for Parity Errors, System Errors, and Master and Slave aborts on the PCI bus as these can indicate problems. ivtv bad audio would be independent of disk problems though. Here's a simple block diagram of how broadcast TV audio moves through a PVR-150: Antenna -- Tuner --- CX25843 - CX23416 PCI Bus --- Memory RFSIF I2S(?) MPEG MPEG The the tinny audio is likely happening inside the CX25843, when the microcontroller firmware program inside modifies how it demodulates analog Sound Intermediate Frequency (SIF), probably because the firmware audio standard autodetection routines may have a bug. There is also a chance that the CX23416 is doing something wrong with the digital I2S serial audio stream, but this also would be a firmware bug. Audio digitization, demodulation, filtering, and encoding is well removed from the PCI bus. If you've commanded an MPEG capture and the audio starts out OK, no PCI bus error is going to change that audio to sound differently (tinny) unless you're actively trying to command the ivtv board to change it's audio related processing. attached
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
ok ill give that a try, though i think i may have another direction that could be the issue, i had a suspicion but since i had a very similar issue with out ivtv affecting things i didnt think so, but due to the failure i just had and recovered from, i am suspecting it may be! i noticed a point on one of the ivtv posts about ivtv and sata drives, now over all i have had little issue and nothing directly relating to that post so i didnt think it was related, but i have a raid5 array with 4 drives setup, and i have bin having an intermittent issue of one of the drives fails out (SDC) and goes non responcive, and i had an issue building the array (same issue) when building the array with an older kernel driver, but with the newer 2.6.25 kernel i dont have the building issue but every so often the drive fails and my raid array goes degraded, not a big deal and not that often, reboot remove and add drive and it rebuilds and it works fine, but now i have the temp set-audio-input fix i had enabled, dissabled for testing and i didnt enable it again, and there was a recording starting the same time the drives failed, and not just one went out but 3 out of the 4 went out, but since they simply went offline and not bad, i was able to recover with no data lost, any chance that it could be an incompatibly with the sata_mv libata driver for the chipset: 00:0e.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:0e.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:0e.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) and ivtv causeing both my drives to fail out and ivtvs bad audio? attached is the syslog file of the errors outputed pertaining to the drive failures if its of any use to see if this is the issue, also all the drives have bin checked to see that they are good drives, and sdc has bin replaced with a good offline spare i had last time i had a failure to rule out bad drives. Thank you so much for any help if this is the cause of both of my issues. Kevin Andy Walls wrote: On Thu, 2008-06-26 at 10:41 -0300, [EMAIL PROTECTED] wrote: ok, here is the debug reports, i did the fallowing, i got the system to be producining the bad audio and generated the log status file, and a debug file, then i used the set-audio-input switch which brought the audio to being normal, and generated another set of logs and debug logs since this is little difference in the log status i am only posting the diff of the 2, as for the debugs im not sure what you need so im posting the full log of both and a diff. I've looked at the diff's. Some comments are in line below. Basically the significant differences are in the audio decoder register block of the cx28543. Unfortunately most of the differences are in undocumented/reserved register regions. The ones in the AC'97 audio codec register region very likely don't matter as ivtv and PVR-150's don't use this interface. The undocumented registers in the range 0x880-0x89f being different tell me the audio micrcontroller is doing something differently in the two cases, but that may or may not be the cause of the tinny audio. please let me know if you need any more information thanks for the help. The next time you get tinny audio, could you use v4l2-dbg to set register 0x810 to 1 and then back to 0. This toggles the SOFT_RESET of the audio microcontroller, and should get it to try and redetect the audio standard. (IIRC the driver does this as one of the steps when switching inputs.) If that fixes things, you will have then verified that the audio microcontroller firmware in the cx25843 is getting confused. If that is the case you have some courses of action which are limited because the firmware source is not available: 1. Experiment with different versions of the Mako (cx2854x) firmware to see if there is one that doesn't produce the tinny audio problem. 2. Try to reliably detect tinny audio from within a program polling the ivtv driver, and when you detect the tinny audio condition, run a utility to reset the audio microcontroller or take some other corrective action. 3. Since you know the TV standards you normally capture, limit the auto-detection of audio standard to the one you capture. I don't think v4l2-ctl supports this right now, and the driver may not currently easily support anything other than autodetection of audio standard. (I'd need to do more research on this.) [snip] Diff of the 2 ---Start- --- ivtv.good.dbg 2008-06-25 21:52:06.659558323 -0300 +++ ivtv.bad.dbg2008-06-25 21:51:19.185396931 -0300 @@ -6,7 +6,7 @@ 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0100: 33 84 00 d0 00 dc 04 07 0f 04 0a 18 fe e2 2b 00 0110: e5 d6 98 00 00 8c 07 00 02 00 00 00 00 00 00 00 -0120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11 +0120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
ok, here is the debug reports, i did the fallowing, i got the system to be producining the bad audio and generated the log status file, and a debug file, then i used the set-audio-input switch which brought the audio to being normal, and generated another set of logs and debug logs since this is little difference in the log status i am only posting the diff of the 2, as for the debugs im not sure what you need so im posting the full log of both and a diff. please let me know if you need any more information thanks for the help. v4l2-ctl -d /dev/video0 --log-status diff --- ivtv.good.log 2008-06-25 21:52:16.304414070 -0300 +++ ivtv.bad.log2008-06-25 21:50:44.286371792 -0300 @@ -44,5 +44,5 @@ ivtv0: Stream encoder YUV: status 0x, 0% of 2048 KiB (64 buffers) in use ivtv0: Stream encoder VBI: status 0x, 0% of 1040 KiB (61 buffers) in use ivtv0: Stream encoder PCM: status 0x, 0% of 324 KiB (72 buffers) in use - ivtv0: Read MPG/VBI: 6336/0 bytes + ivtv0: Read MPG/VBI: 4622272/0 bytes ivtv0: == END STATUS CARD #0 == debug log - bad audio -start- ioctl: VIDIOC_DBG_G_REGISTER 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0100: 33 84 00 d0 00 dc 04 07 0f 04 0a 18 fe e2 2b 00 0110: e5 d6 98 00 00 8c 07 00 02 00 00 00 00 00 00 00 0120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11 0130: 00 00 00 00 02 18 0a 00 00 00 00 00 00 00 36 00 0140: 04 f0 00 00 10 32 54 76 00 00 00 00 00 00 00 00 0150: 00 00 00 00 00 00 00 00 00 e1 86 10 00 e1 86 06 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0200: 00 00 00 00 ff ff 00 00 ff ff 00 00 00 00 00 00 0210: 20 00 00 00 33 00 00 00 00 00 00 00 00 00 00 00 0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0400: 01 e2 04 00 2e 25 10 00 00 80 00 00 00 81 7d 00 0410: bf 07 ff 7f 00 7e 00 00 00 00 08 00 00 00 08 00 0420: 7e 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0430: 00 00 00 00 00 00 00 00 00 00 00 00 06 00 f0 ff 0440: a9 0b 00 00 00 00 00 00 00 00 00 00 70 99 10 2c 0450: 01 00 00 03 0d c4 08 26 77 88 00 54 00 00 00 00 0460: 02 14 0a 34 6e ca 36 06 e7 00 00 08 20 f6 84 02 0470: 7a 00 2d 5b 1a 70 1e 1a 1f 02 50 66 1f 7c 08 00 0480: b0 03 00 00 00 00 60 42 1a 2f 06 f8 dc 40 10 00 0490: 8a 02 3f cd 00 03 1f 16 22 00 00 00 14 00 50 14 04a0: 0f 02 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 04b0: 00 00 00 00 03 00 00 00 01 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0800: fe 3f ff 03 fe ff 7f 20 f6 04 11 00 00 00 1c e0 0810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 47 67 0820: 64 57 ce 1b 05 e0 05 8a a0 01 00 00 e9 01 ed 03 0830: 10 40 0d 03 00 00 00 40 76 04 ed 03 10 40 0d 03 0840: 00 00 00 40 00 00 ed 03 10 80 84 1e 00 00 00 40 0850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80 0860: b8 01 ca 00 00 00 00 01 00 00 00 00 00 00 00 00 0870: 00 00 00 00 00 00 00 00 7e 05 7e 05 88 45 a2 06 0880: da 07 3c 0b e1 ca 03 40 30 70 30 70 da 01 64 00 0890: 24 f4 03 40 30 70 30 70 d3 0c 00 01 5b 01 16 05 08a0: 78 06 d6 12 87 51 00 00 de 53 03 00 b1 01 00 00 08b0: d0 f3 00 00 00 00 00 00 c8 00 ff 0f 1f 00 0f 00 08c0: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 0f 08d0: 12 10 01 01 2c 00 ff 7f 00 18 18 18 a3 33 ff 7f 08e0: 70 38 06 03 24 00 ff 7f 00 18 18 18 a3 33 ff 7f 08f0: fc 0a 52 bb 88 88 55 55 00 80 01 08 7c 86 01 08 0900: 55 55 01 08 55 55 01 08 53 04 01 08 55 55 01 08 0910: c9 00 b0 12 a0 00 00 00 a0 01 00 00 00 00 00 00 0920: 00 48 3d f5 05 05 00 00 00 00 00 00 00 00 00 00 0930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 ff 0950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00 0960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0980: 00 00 00 00 00 00 00 00 00 3f 00 3f 00 3f 00 3f 0990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09a0: 00 00 00 00 00 00 00 00 01 00 00 00 0e 00 00 80 -end- debug log - Good audio -start- ioctl: VIDIOC_DBG_G_REGISTER 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F : 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0100: 33 84 00 d0 00 dc 04 07 0f 04 0a 18 fe e2 2b 00 0110: e5 d6 98 00 00 8c 07 00 02 00 00 00 00 00 00 00 0120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11 0130: 00 00 00 00 02 18 0a 00 00 00 00 00 00 00 36 00 0140: 04 f0 00 00 10 32 54 76 00 00 00 00
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
another update, i updated the revision of mythtv but it did not fix the audio issue. i also tryed a new copy of the firmware with no change. Kevin well i tryed the lattest bleeding edge driver as of 8pm last night and it does not fix the issue i still get the bad audio. below is the dmesg info when the driver is loaded. Linux video capture interface: v2.00 ivtv: Start initialization, version 1.3.0 ivtv0: Initializing card #0 ivtv0: Autodetected Hauppauge card (cx23416 based) ACPI: PCI Interrupt :05:09.0[A] - Link [APC2] - GSI 17 (level, low) - IRQ 17 PCI: Enabling bus mastering for device :05:09.0 tveeprom 2-0050: Hauppauge model 26552, rev F0A3, serial# 10413145 tveeprom 2-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 2-0050: audio processor is CX25843 (idx 37) tveeprom 2-0050: decoder processor is CX25843 (idx 30) tveeprom 2-0050: has radio, has no IR receiver, has no IR transmitter ivtv0: Autodetected Hauppauge WinTV PVR-150 cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #0) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0) wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0) tuner-simple 2-0061: creating new instance tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes) ivtv0: Registered device video0 for encoder MPG (4096 kB) ivtv0: Registered device video32 for encoder YUV (2048 kB) ivtv0: Registered device vbi0 for encoder VBI (1024 kB) ivtv0: Registered device video24 for encoder PCM (320 kB) ivtv0: Registered device radio0 for encoder radio ivtv0: Initialized card #0: Hauppauge WinTV PVR-150 ivtv: End initialization ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) ivtv0: Encoder revision: 0x02060039 also as a side note, i did change system boards for other reasons so its a different brand/model but simmiler system board. Thanks for any help Kevin Hi, well i have had my system online, and i finaly have time to get back to trying to fix this, i have bin using the set audio input fix as noted before and it still gives me the bad audio, altho not nearly as often, i did try the bleeding edge drivers with no success still same issue and no changes, although that was a month ago, i will try again with the current bleeding edge driver and see if it works, other wise in my free time i can work with anyone who knows more about this to try and debug this since it seems like its an unresoveled issue that some people are having and just arnt speaking up. i currently am traviling, however i have a second slave mythbox that does tuning, since i have bin working on fixing it on the master im not sure if the slave is doing the same, if it is then for any dev that would like to examin the issue with root access give me a week or so, and ill be able to secure remote access to the system. if anyone has found a fix or work around already and i didnt see the message please let me know. thanks Kevin well im not sure now, i have just had a major systemboard failure, i have yet to fully test what has failed but the entire usb system has failed, so it may have bin a bad system board causing the issues for me, ill know for sure when i get a new replacement. Kevin Scott Harris wrote: Hans Verkuil wrote: Hi Mike, The tinny audio problem plagued a lot of people in the past, but I haven't heard about this for quite some time now. Please make sure you are using the latest version (preferably the 'bleeding edge' code from http://www.ivtvdriver.org/index.php/Download#Bleeding_Edge_driver). It seems that this problem only hits NTSC cards and it seems to be related to some interaction between the audio chip and the cx23416. After I made some changes in the way this is handled the problem disappeared, although I never quite understood what was going on internally. And I think that in one or two cases it was actually a bad card, so I wonder if you could get hold of another PVR500 to test with. Regards, Hans I know it doesn't help throwing in the me too emails, but I've never been able to shake this problem from a pvr-250. It happens about 85% of the time. I just run this from cron once a minute to fix it. /usr/bin/v4l2-ctl -d /dev/video1 --set-audio-input=1 Scott Linux mythtv 2.6.24.5-85.fc8 #1 SMP Sat Apr 19 11:18:09 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux ivtv-kmdl-2.6.24.5-85.fc8-1.0.3-136.fc8 ivtv_xdriver-1.0.0-9.fc8 ivtv-firmware-20070217-17 ivtv-1.0.3-136.fc8 perl-Video-ivtv-0.13-8.fc8 ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users ___
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Tue, 2008-06-24 at 08:12 -0300, [EMAIL PROTECTED] wrote: well i tryed the lattest bleeding edge driver as of 8pm last night and it does not fix the issue i still get the bad audio. below is the dmesg info when the driver is loaded. Linux video capture interface: v2.00 ivtv: Start initialization, version 1.3.0 ivtv0: Initializing card #0 ivtv0: Autodetected Hauppauge card (cx23416 based) ACPI: PCI Interrupt :05:09.0[A] - Link [APC2] - GSI 17 (level, low) - IRQ 17 PCI: Enabling bus mastering for device :05:09.0 tveeprom 2-0050: Hauppauge model 26552, rev F0A3, serial# 10413145 tveeprom 2-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 2-0050: audio processor is CX25843 (idx 37) tveeprom 2-0050: decoder processor is CX25843 (idx 30) tveeprom 2-0050: has radio, has no IR receiver, has no IR transmitter ivtv0: Autodetected Hauppauge WinTV PVR-150 cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) Misconfiguration or misdetection of the audio standard by the CX5843 chip is likely cause of audio problems, since it does demodulation, standard detection, dematrixing, digitization, and digital filtering of tuner SIF audio. (CX23416 encoding could also be a cause.) So let's use differential analysis on the cx28543 to see if we can find what's wrong. Ideally we'd like to get snapshots of data of the board with good audio and the board with tinny audio with as many of the inputs and conditions the same as is possible. 1. The first thing you want to look for differences in is the output of $ v4l2-ctl -d /dev/video0 --log-status 2. The second thing you want to look for differences in is the output of $ v4l2-dbg -d /dev/video0 -R type=i2cdrv,chip=cx25840 which produces a register dump of the cx25843's registers. (This syntax might be slightly wrong, as I don't have my PVR-150 in my machine right now) Somethings will be different that don't matter (e.g. the chip counts video scan lines that it has processed so these counters will be different), but hopefully something shows up that does matter. BTW, what corrective actions have you taken that are effective at getting rid of the tinny audio when it occurs? Regards, Andy tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #0) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0) wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0) tuner-simple 2-0061: creating new instance tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes) ivtv0: Registered device video0 for encoder MPG (4096 kB) ivtv0: Registered device video32 for encoder YUV (2048 kB) ivtv0: Registered device vbi0 for encoder VBI (1024 kB) ivtv0: Registered device video24 for encoder PCM (320 kB) ivtv0: Registered device radio0 for encoder radio ivtv0: Initialized card #0: Hauppauge WinTV PVR-150 ivtv: End initialization ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) ivtv0: Encoder revision: 0x02060039 also as a side note, i did change system boards for other reasons so its a different brand/model but simmiler system board. Thanks for any help Kevin Hi, well i have had my system online, and i finaly have time to get back to trying to fix this, i have bin using the set audio input fix as noted before and it still gives me the bad audio, altho not nearly as often, i did try the bleeding edge drivers with no success still same issue and no changes, although that was a month ago, i will try again with the current bleeding edge driver and see if it works, other wise in my free time i can work with anyone who knows more about this to try and debug this since it seems like its an unresoveled issue that some people are having and just arnt speaking up. i currently am traviling, however i have a second slave mythbox that does tuning, since i have bin working on fixing it on the master im not sure if the slave is doing the same, if it is then for any dev that would like to examin the issue with root access give me a week or so, and ill be able to secure remote access to the system. if anyone has found a fix or work around already and i didnt see the message please let me know. thanks Kevin well im not sure now, i have just had a major systemboard failure, i have yet to fully test what has failed but the entire usb system has failed, so it may have bin a bad system board causing the issues for me, ill know for sure when i get a new replacement. Kevin Scott Harris wrote: Hans Verkuil wrote: Hi Mike, The tinny audio problem plagued a lot of people in the past, but I haven't heard about this for quite some time now. Please make sure you are using the latest version (preferably the 'bleeding edge' code from
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
well im not sure now, i have just had a major systemboard failure, i have yet to fully test what has failed but the entire usb system has failed, so it may have bin a bad system board causing the issues for me, ill know for sure when i get a new replacement. Kevin Scott Harris wrote: Hans Verkuil wrote: Hi Mike, The tinny audio problem plagued a lot of people in the past, but I haven't heard about this for quite some time now. Please make sure you are using the latest version (preferably the 'bleeding edge' code from http://www.ivtvdriver.org/index.php/Download#Bleeding_Edge_driver). It seems that this problem only hits NTSC cards and it seems to be related to some interaction between the audio chip and the cx23416. After I made some changes in the way this is handled the problem disappeared, although I never quite understood what was going on internally. And I think that in one or two cases it was actually a bad card, so I wonder if you could get hold of another PVR500 to test with. Regards, Hans I know it doesn't help throwing in the me too emails, but I've never been able to shake this problem from a pvr-250. It happens about 85% of the time. I just run this from cron once a minute to fix it. /usr/bin/v4l2-ctl -d /dev/video1 --set-audio-input=1 Scott Linux mythtv 2.6.24.5-85.fc8 #1 SMP Sat Apr 19 11:18:09 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux ivtv-kmdl-2.6.24.5-85.fc8-1.0.3-136.fc8 ivtv_xdriver-1.0.0-9.fc8 ivtv-firmware-20070217-17 ivtv-1.0.3-136.fc8 perl-Video-ivtv-0.13-8.fc8 ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
Hans Verkuil wrote: Hi Mike, The tinny audio problem plagued a lot of people in the past, but I haven't heard about this for quite some time now. Please make sure you are using the latest version (preferably the 'bleeding edge' code from http://www.ivtvdriver.org/index.php/Download#Bleeding_Edge_driver). It seems that this problem only hits NTSC cards and it seems to be related to some interaction between the audio chip and the cx23416. After I made some changes in the way this is handled the problem disappeared, although I never quite understood what was going on internally. And I think that in one or two cases it was actually a bad card, so I wonder if you could get hold of another PVR500 to test with. Regards, Hans I know it doesn't help throwing in the me too emails, but I've never been able to shake this problem from a pvr-250. It happens about 85% of the time. I just run this from cron once a minute to fix it. /usr/bin/v4l2-ctl -d /dev/video1 --set-audio-input=1 Scott Linux mythtv 2.6.24.5-85.fc8 #1 SMP Sat Apr 19 11:18:09 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux ivtv-kmdl-2.6.24.5-85.fc8-1.0.3-136.fc8 ivtv_xdriver-1.0.0-9.fc8 ivtv-firmware-20070217-17 ivtv-1.0.3-136.fc8 perl-Video-ivtv-0.13-8.fc8 ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
Course of action #2: Alternatively, if Mike Ellis can confirm that he never has tinny audio with a particular ivtv version (0.6.7), a diff between that and version 1.0.3 would show all the potential areas of a root cause in the driver. But the changes between these two versions are probably extensive. Hi Andy. I'm afraid you may have misunderstood my comments. I did say that I settled on 0.6.7, but I did not mean to imply that 0.6.7 fixed the tinny audio problem. In fact, I've been fighting the tinny audio problem on my PVR500 since I setup my system back in 2006. 0.6.7 ended up being the best compromise for me based on the kernel I want to use, but I've observed tinny audio all the way from 0.6.x through the 1.0.x drivers (I used 1.0.x when I was experimenting with newer kernels -- I later reverted). The folks I've spoken to who've worked around this problem use a channel change script to toggle the audio settings each time the channel changes, but I have been procrastinating in setting that up. Put simply: the tinny audio problem appears regardless of whether you are using earlier ivtv drivers for some of the most recent ones. Consequently, I doubt the issue is due to a code change in the driver, and it is more likely due to the way the chips are being configured. Hope this helps. Mike Ellis -- Message: 2 Date: Fri, 09 May 2008 21:26:49 -0400 From: Andy Walls [EMAIL PROTECTED] Subject: Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3 To: User discussion about IVTV ivtv-users@ivtvdriver.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain On Fri, 2008-05-09 at 21:28 -0300, Kevin Blair wrote: upgrade to myth .21 didnt do anything, i tried a pvr250 i have and it doesnt seem to do it, i have a second pvr150 card in the second system which i swaped to rule out hardware (and chipset it has a older revision) but no difference. also tried older and newer(was same as current) firmware, wouldnt take old, no change otherwise. i tried the newi2c option, no change. im not using the pvr250 cause the svid input quality is bad. less of getting a new card im out of ideas. Well it boils down to this, there are only three chips that handle audio on the card: 1. the baseband audio digitizer/multiplexer/serializer (the wm8775 is the one on my PVR-150MCE) 2. the broadcast decoder, digitizer, with digital baseband audio processing (the cx28543 on my PVR-150MCE) 3. the MPEG encoder (the cx23416) I don't have any real insight into the cx23416 encoder, so I'm going to wave my hands and assume its working properly for now. That leaves the cx25843 and the wm8775 as source of the tinny audio. For them to do that, under certain conditions one of these must be true: a) the driver is not setting these chip up properly, or b) the chip isn't behaving properly. The wm8775 is a pretty simple device, so the odds of it behaving improperly are low. If this device is what is introducing the tiny audio, the driver must not be setting it up properly. The cx28543 is a bit more complex so it could either the driver not setting it up properly or it misbehaving. Also, note you have the problem with baseband audio in, and not with tuner audio (which bypasses the wm8775 in the common case of SIF audio being fed into the cx25843). So here are three courses of action you could undertake to try and find the source of the problem. Course of action #1: To verify if the driver is setting up all the registers properly is conceptually easy: 1. With good audio, use v4l-dbg to dump all the registers of the cx25843 and wm8775. 2. With bad audio, but otherwise the same exact configuration, use v4l-dbg to dump all the registers of the cx25843 and wm8775. 3. Do a diff (or use vimdiff) and see what registers differ. If none differ, a device must be misbehaving. 4. If registers do differ, check the datasheets at dl.ivtvdriver.org to see if any are related to audio processing. If so, you may have found the register the driver or on chip autoconfig screwed up. If not, a device is misbehaving. 5. If a device is misbehaving, v4l-dbg can be used to tweak individual register settings to of the cx28543 or wm8775 to hunt for causal relationships by trial and error (blech!) Here's the problem with that: I believe the cx25840 driver support register dumps via v4l-dbg, but I'm pretty sure the wm8775 driver does not. It should be simple to add, so I can work up a patch, if you want to go through some of the steps above to hunt this down. Course of action #2: Alternatively, if Mike Ellis can confirm that he never has tinny audio with a particular ivtv version (0.6.7), a diff between that and version 1.0.3 would show all the potential areas of a root cause in the driver. But the changes between these two versions are probably extensive. Course of action #3
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Wed, 2008-05-07 at 22:55 -0300, Kevin Blair wrote: humm, these errors are sparse but i have errors and warnings saying: Error: Error getting codec params using old IVTV ioctl Warning: Error getting codec params using old IVTV ioctl i guess this version of myth doesnt like this version of ivtv or visaversa, i didnt notice those errors, too much sql in the logs hiding the errors. although a little research says they are nothing to worry about, but i will upgrade to myth 0.21 to rule that out aside from that there is nothing about ioctl or ivtv for errors or warnings and i have all messages on to be logged. Those particular MythTV errors are nothing to worry about. MythTV is just trying to figure out whether to use the old ioctls or new ioctls to set up the device. The gripe is just noise about the old ioctls not working. I was going to suggest that you try and use v4l-dbg to dump the registers for the cx25843 and wm8775 (or whatever audio mux chip your card has) and diff them for cases when the audio was tinny and when it wasn't. However, the wm8775 driver doesn't support dumping it's registers (yet), so you can't do that easily. Since both of these devices affect sound and are controlled via i2c, it may be worth loading the ivtv module with # modprobe -r ivtv # modprobe ivtv newi2c=1 to see if intermittent failures of i2c communications may be causing the tinny audio problems. -Andy ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
upgrade to myth .21 didnt do anything, i tried a pvr250 i have and it doesnt seem to do it, i have a second pvr150 card in the second system which i swaped to rule out hardware (and chipset it has a older revision) but no difference. also tried older and newer(was same as current) firmware, wouldnt take old, no change otherwise. i tried the newi2c option, no change. im not using the pvr250 cause the svid input quality is bad. less of getting a new card im out of ideas. Kevin Andy Walls wrote: On Wed, 2008-05-07 at 22:55 -0300, Kevin Blair wrote: humm, these errors are sparse but i have errors and warnings saying: Error: Error getting codec params using old IVTV ioctl Warning: Error getting codec params using old IVTV ioctl i guess this version of myth doesnt like this version of ivtv or visaversa, i didnt notice those errors, too much sql in the logs hiding the errors. although a little research says they are nothing to worry about, but i will upgrade to myth 0.21 to rule that out aside from that there is nothing about ioctl or ivtv for errors or warnings and i have all messages on to be logged. Those particular MythTV errors are nothing to worry about. MythTV is just trying to figure out whether to use the old ioctls or new ioctls to set up the device. The gripe is just noise about the old ioctls not working. I was going to suggest that you try and use v4l-dbg to dump the registers for the cx25843 and wm8775 (or whatever audio mux chip your card has) and diff them for cases when the audio was tinny and when it wasn't. However, the wm8775 driver doesn't support dumping it's registers (yet), so you can't do that easily. Since both of these devices affect sound and are controlled via i2c, it may be worth loading the ivtv module with # modprobe -r ivtv # modprobe ivtv newi2c=1 to see if intermittent failures of i2c communications may be causing the tinny audio problems. -Andy ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Fri, 2008-05-09 at 21:28 -0300, Kevin Blair wrote: upgrade to myth .21 didnt do anything, i tried a pvr250 i have and it doesnt seem to do it, i have a second pvr150 card in the second system which i swaped to rule out hardware (and chipset it has a older revision) but no difference. also tried older and newer(was same as current) firmware, wouldnt take old, no change otherwise. i tried the newi2c option, no change. im not using the pvr250 cause the svid input quality is bad. less of getting a new card im out of ideas. Well it boils down to this, there are only three chips that handle audio on the card: 1. the baseband audio digitizer/multiplexer/serializer (the wm8775 is the one on my PVR-150MCE) 2. the broadcast decoder, digitizer, with digital baseband audio processing (the cx28543 on my PVR-150MCE) 3. the MPEG encoder (the cx23416) I don't have any real insight into the cx23416 encoder, so I'm going to wave my hands and assume its working properly for now. That leaves the cx25843 and the wm8775 as source of the tinny audio. For them to do that, under certain conditions one of these must be true: a) the driver is not setting these chip up properly, or b) the chip isn't behaving properly. The wm8775 is a pretty simple device, so the odds of it behaving improperly are low. If this device is what is introducing the tiny audio, the driver must not be setting it up properly. The cx28543 is a bit more complex so it could either the driver not setting it up properly or it misbehaving. Also, note you have the problem with baseband audio in, and not with tuner audio (which bypasses the wm8775 in the common case of SIF audio being fed into the cx25843). So here are three courses of action you could undertake to try and find the source of the problem. Course of action #1: To verify if the driver is setting up all the registers properly is conceptually easy: 1. With good audio, use v4l-dbg to dump all the registers of the cx25843 and wm8775. 2. With bad audio, but otherwise the same exact configuration, use v4l-dbg to dump all the registers of the cx25843 and wm8775. 3. Do a diff (or use vimdiff) and see what registers differ. If none differ, a device must be misbehaving. 4. If registers do differ, check the datasheets at dl.ivtvdriver.org to see if any are related to audio processing. If so, you may have found the register the driver or on chip autoconfig screwed up. If not, a device is misbehaving. 5. If a device is misbehaving, v4l-dbg can be used to tweak individual register settings to of the cx28543 or wm8775 to hunt for causal relationships by trial and error (blech!) Here's the problem with that: I believe the cx25840 driver support register dumps via v4l-dbg, but I'm pretty sure the wm8775 driver does not. It should be simple to add, so I can work up a patch, if you want to go through some of the steps above to hunt this down. Course of action #2: Alternatively, if Mike Ellis can confirm that he never has tinny audio with a particular ivtv version (0.6.7), a diff between that and version 1.0.3 would show all the potential areas of a root cause in the driver. But the changes between these two versions are probably extensive. Course of action #3: If neither of those turn up any obvious answers, then one can start doing differential analysis of cx23416 register settings, and hope something that one doesn't need that datasheet to understand will jump out. Those are my ideas. All three of them are a non-trivial amount of work. Anyone have any others? -Andy ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
I have been fighting the Tinny Audio issue for a couple of years now. I have a PVR500 with Phillips tuners, and I've tried the 1.0.x series ivtv drivers, but I ultimately settled on 0.6.7. I can say for sure that I experience the tinny audio without MythTV being in the loop. If I capture directly from /dev/video0 to a file, sometimes the file shows up with tinny audio, but most of the time it works fine. There was a workaround proposed on the this list some time ago, but I've been too busy with other things to try it out. I'll see if I can dig it up. Regards, Mike Ellis humm, these errors are sparse but i have errors and warnings saying: Error: Error getting codec params using old IVTV ioctl Warning: Error getting codec params using old IVTV ioctl i guess this version of myth doesnt like this version of ivtv or visaversa, i didnt notice those errors, too much sql in the logs hiding the errors. although a little research says they are nothing to worry about, but i will upgrade to myth 0.21 to rule that out aside from that there is nothing about ioctl or ivtv for errors or warnings and i have all messages on to be logged. Thanks Kevin = Michael F. Ellis President Ellis Softworks Inc. -- Phone: (941) 713-0361 Email: [EMAIL PROTECTED] Web: http://www.ellissoftworks.com ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Wed, 2008-05-07 at 19:06 -0300, Kevin Blair wrote: Hi, im having the bad tinny audio issue on my mythtv system it has only started recently, and is intermittent so some recordings are fine some have bad audio, for live playback majortiy of the time audio is fine only after going in and out and in and out of live tv sevral times did i get the audio tinny, with no pattern its hard to predict or reproduce on command, the source is svid and composite. cat /dev/video0 seems to test out fine, how ever since live tv playback works most of the time i cant say for sure that its working. i am useing gentoo linux and ivtv v1.0.3 i was useing 2.6.24 and i upgraded to 2.6.25 kernel but the problem remains, due to hardware compatibility i cant downgrade kernel. i tried adding tuner=50 to module options with no success. executing v4l2-ctl --set-audio-input 0 ; v4l2-ctl --set-audio-input 1 when i get mythtv audio playback bad the audio goes to normal, which doesnt help fix the problem for recordings. What is the difference, if any, between the output of $ v4l2-ctl --log-status when the audio is good and when the audio is bad on the input same source. Also can you clarify: does this happens with tuner audio only, audio line in only, or both? -Andy my tuner is as fallows from lspci -v 05:06.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) Subsystem: Hauppauge computer works Inc. WinTV PVR 150 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at e400 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 Kernel driver in use: ivtv Kernel modules: ivtv dmesg output from ivtv being loaded is as fallows: ivtv: Start initialization, version 1.2.0 ivtv0: Initializing card #0 ivtv0: Autodetected Hauppauge card (cx23416 based) ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt :05:06.0[A] - Link [APC1] - GSI 16 (level, low) - IRQ 16 ivtv0: Unreasonably low latency timer, setting to 64 (was 32) tveeprom 2-0050: Hauppauge model 26552, rev F068, serial# 10426282 tveeprom 2-0050: tuner model is LG TAPE H001F MK3 (idx 68, type 47) tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 2-0050: audio processor is CX25843 (idx 37) tveeprom 2-0050: decoder processor is CX25843 (idx 30) tveeprom 2-0050: has radio, has no IR receiver, has no IR transmitter ivtv0: Autodetected Hauppauge WinTV PVR-150 cx25840 2-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0) tuner 2-0043: chip found @ 0x86 (ivtv i2c driver #0) tda9887 2-0043: tda988[5/6/7] found tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0) wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0) tuner-simple 2-0061: type set to 50 (TCL 2002N) ivtv0: Registered device video0 for encoder MPG (4096 kB) ivtv0: Registered device video32 for encoder YUV (2048 kB) ivtv0: Registered device vbi0 for encoder VBI (1024 kB) ivtv0: Registered device video24 for encoder PCM (320 kB) ivtv0: Registered device radio0 for encoder radio ivtv0: Initialized card #0: Hauppauge WinTV PVR-150 ivtv: End initialization and firmware ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) ivtv0: Encoder revision: 0x02060039 cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes) any suggestions would be much appreciated. Kevin ___ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-users] Tinny Audio problem on ivtv 1.0.3
On Wed, 2008-05-07 at 21:05 -0300, Kevin Blair wrote: the fallowing is the differnce between when the audio is good and bad from $ v4l2-ctl --log-status --- record.good 2008-05-07 20:51:09.250606270 -0300 +++ record.bad 2008-05-07 20:53:28.747993406 -0300 @@ -32,17 +32,16 @@ ivtv0: Stream: MPEG-2 Program Stream ivtv0: VBI Format: No VBI ivtv0: Video: 480x480, 30 fps - ivtv0: Video: MPEG-2, 4x3, Variable Bitrate, 400, Peak 500 + ivtv0: Video: MPEG-2, 4x3, Variable Bitrate, 450, Peak 600 ivtv0: Video: GOP Size 15, 2 B-Frames, GOP Closure ivtv0: Audio: 48 kHz, Layer II, 384 kbps, Stereo, No Emphasis, No CRC ivtv0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0 ivtv0: Temporal Filter: Manual, 0 ivtv0: Median Filter: Off, Luma [0, 255], Chroma [0, 255] ivtv0: Status flags:0x0020 - ivtv0: Stream encoder MPG: status 0x0118, 2% of 4096 KiB (128 buffers) in use + ivtv0: Stream encoder MPG: status 0x0118, 1% of 4096 KiB (128 buffers) in use ivtv0: Stream encoder YUV: status 0x, 0% of 2048 KiB (64 buffers) in use ivtv0: Stream encoder VBI: status 0x, 0% of 1040 KiB (61 buffers) in use ivtv0: Stream encoder PCM: status 0x, 0% of 324 KiB (72 buffers) in use - ivtv0: Read MPG/VBI: 1639094208/0 bytes + ivtv0: Read MPG/VBI: 52113408/0 bytes ivtv0: == END STATUS CARD #0 == it seems the video vbi and peek go up and the read mpg/vbi goes down, which would match the issue cause the audio does sound simmiler to audio recorded at mp2/3 at 32/64kbps rather then a higher rate like 384kbps. If what you mean is that if increased video bitrate could force lower quality audio, then this explains the poorer quality audio, then I agree. However, I do not know if that's how the encoder actually behaves. perhaps this may be an issue with mythtv rather then ivtv? mythtv is version 0.20.2_p14972 Does the mythbackend.log gripe about an ioctl() not working when the tinny audio occurs? If it does, it may be worht hunting down in the MythTV source, what ioctl()s it was trying to set. You could then look at the source for the ivtv driver to see why those ioctl()s may fail. this is from audio line in(it is a mce with rca jacks) hooked up to expressvu sat OK. So this shouldn't be due to audio standard auto-detection by the cx25840. -Andy Kevin Andy Walls wrote: On Wed, 2008-05-07 at 19:06 -0300, Kevin Blair wrote: Hi, im having the bad tinny audio issue on my mythtv system it has only started recently, and is intermittent so some recordings are fine some have bad audio, for live playback majortiy of the time audio is fine only after going in and out and in and out of live tv sevral times did i get the audio tinny, with no pattern its hard to predict or reproduce on command, the source is svid and composite. cat /dev/video0 seems to test out fine, how ever since live tv playback works most of the time i cant say for sure that its working. i am useing gentoo linux and ivtv v1.0.3 i was useing 2.6.24 and i upgraded to 2.6.25 kernel but the problem remains, due to hardware compatibility i cant downgrade kernel. i tried adding tuner=50 to module options with no success. executing v4l2-ctl --set-audio-input 0 ; v4l2-ctl --set-audio-input 1 when i get mythtv audio playback bad the audio goes to normal, which doesnt help fix the problem for recordings. What is the difference, if any, between the output of $ v4l2-ctl --log-status when the audio is good and when the audio is bad on the input same source. Also can you clarify: does this happens with tuner audio only, audio line in only, or both? -Andy my tuner is as fallows from lspci -v 05:06.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) Subsystem: Hauppauge computer works Inc. WinTV PVR 150 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at e400 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 Kernel driver in use: ivtv Kernel modules: ivtv dmesg output from ivtv being loaded is as fallows: ivtv: Start initialization, version 1.2.0 ivtv0: Initializing card #0 ivtv0: Autodetected Hauppauge card (cx23416 based) ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt :05:06.0[A] - Link [APC1] - GSI 16 (level, low) - IRQ 16 ivtv0: Unreasonably low latency timer, setting to 64 (was 32) tveeprom 2-0050: Hauppauge model 26552, rev F068, serial# 10426282 tveeprom 2-0050: tuner model is LG TAPE H001F MK3 (idx 68, type 47) tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 2-0050: audio processor is CX25843 (idx 37) tveeprom 2-0050: decoder processor is CX25843
