Mailing List Archive

On Mon, 2010-07-12 at 23:20 -0500, Chris Kennedy wrote:
> 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 didn't think that I had committed any real tinny audio fixes for the
analog audio demodulator. All my fixes for that so far have been
somewhat working band-aids that guess at the root cause (IMO).

(Ah now I recall, Martin, IIRC, had found some CX23416 encoder startup
timing issues on the I2S digital output side of the CX25843.)

> 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.

If you know you will always be watching NTSC/mono or NTSC/BTSC then
that is perfectly fine. It will give you more reliable audio
demodulation then letting the microcontroller do a full (World-wide)
audio standard search when it needs to redetect the audio standard.



> 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.

It likely never will.

I'm getting a clearer understanding of the Merlin broadcast audio
decoder core, given what information I have on it (which is far from
complete).


> 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.

No, the current fix solves a problem in a different part of the system:
the digital I2S between the CX25843 and CX23416. Tinny audio at this
interface would imply some sort of sample rate mismatch between the
CX25843 and the CX23416. The startup timing change obviously helps the
CX23416 get its sample rate reliably set correctly.


Your problem is clearly originating the Merlin microcontroller and
analog demodulator block. This is where I suspect most people's tinny
audio is originating from.

Looking at figure 3-30 in this data sheet:

http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf

The microcontroller is labeled "Auto Std/Mode Detection" and the analog
demodulator comprises the blocks labeled "Sound IF SRC", "Analog
Demod/NICAM", and "DBX" (excluding the NICAM portion which is digital
demodulation).

I've spent about six hours in the past week taking a harder look at the
analog demodulator (for which I have very little details). It's a
flexible, very configurable block made up of a large number of smaller
blocks to perform two high level functions: spectral analysis with
detection and demoulation of audio signals to baseband.

It of course has to perform spectral analysis, because no one in their
right mind is going to search in the time domain for the characteristics
of things like the BTSC spectrum:

http://broadcastengineering.com/images/nov_2005/511be09_Fig2_600w.jpg
http://www.lenrek.net/experiments/btsc-spectrum/

or any other broadcast audio standard when performing autodetection.
(Note for NTSC/mono, only the L+R portion of the spectrum is present.)


The audio microcontroller is responsible for configuring and
reconfiguring the total of the analog demodulation block when searching
for audio standards and responding to events from the block (i.e.
detection of energy at various frequencies).

> 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.

Right. So let's assume, that if the microcontroller is operating on
good data, it always knows how to set up demodulation of any audio
standard perfectly. That leaves the following problem mechanisms:

1. False detections from the spectral analysis
(possibly due to a non random noise source (EMI) or due to
intermodulation products caused by strong/overamplified signals).

2. Missed detections from the spectral analysis
(possibly due to weak signals, or PLL's locking onto the wrong frequency
inducing an incorrect frequency offset possibly due to a non-random
noise source (EMI) or due to intermodulation products caused by
strong/overamplified signals).

3. Contention for access to the registers for configration and
montioring of the analog audio demodulation blocks.
(Note on figure 3-30 both the microcontroller and I2C interface can
access the register file.)

4. An algorithmic flaw in the micrcontroller program's search algorithm.

5. Incorrect estimation of the horizontal sync frequency.
(BTSC spectrum use and center frequencies are based on this frequency.)

6. some combination of the above.


Redetecion will certainly at least be triggered by transitions in the
NTSC channel's broadcast signal from

a. mono L+R audio <-> BTSC audio
b. no audio signal <-> mono L+R audio
c. no audio signal <-> BTSC audio

I know VCR's and consumer DTV STB's only output mono L+R audio to save a
few bucks. For those items, the transitions in b. above are the only
ones that apply.

TV channels may flip from BTSC to mono between programs, but I doubt it.
TV stations more likely either always transmit a BTSC (with pilot) when
transmitting an audio signal or just transmit mono L+R (which also
should have a detectable FM carrier even when silence is being
transmitted). I'm no broadcast engineer, so I could be wrong.



> 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 microcontroller program is providing those values to us. It could
be as simple as when you force the program to only look for BTSC, that
it always provides a hard coded value.

BY limiting the search to only BTSC, you remove the risk of false
detections of other standards, or detections of energy at the wrong
frequencies that appear to be "close enough".


> The audio sounds like it's very far away in a ringing room or something
> when the problems happen,

filter or demodulator misconfiguration by the microcontroller due to
bad information is likely the cause.



> also I'm hoping that forcing the format is
> really a fix and that for some reason it doesn't still get weird audio

It greatly reduces the probably of false positive detections or
adjusting frequency offsets based on some spurious signal.


> .
> 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.

I think once the audio microcontroller detects a good signal, there is
some hystersis before it declares it has lost the signal and needs to
restart it's search. Limiting the standards for which one is searching
limits the chance of some spurious frequency detection being interpreted
as possibly valid.


> 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.

Sometimes, limiting it to BTSC still fails (see Mark Lord's email from a
few months back). Then forcing a redetect becomes problematic, IIRC.

Forcing an audio standard in locations where NTSC is used makes a lot of
sense. One is pretty sure that either mono audio or BTSC is in use and
there are not any real options for those to vary.

In places that use PAL and SECAM, where differern broadcast systems have
slightly different parameters and folks are capable of receiving the
different standards at their locations, this wouldn't be a terribly
helpful fix as a module option.

A better option would be to have the cx25840 module respond more
specifically to the VIDIOC_S_STD ioctl, when the user has set a very
specific standard on an input.


> 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.

The caveat is, sometimes it still doesn't work.

To have a high probabilty chance of reliably resolving this problem
conclusively, I'd need:

1. Good, detailed block diagrams of the Merlin and perhaps a half-way
decent description of the Theory of Operation

2. The microcontroller program source code

3. A spectrum analyzer capture of the incoming signal's Sound IF before
and after the transition to "tinny" audio.


In other words, the real engineering data about the device, and a
dataset that triggers the failure mode. I'm guessing that won't happen
in my lifetime.

Until then, forcing the audio standard and audio system is the best we
can do, short of using the mono AF out of the analog tuner assmebly and
bypassing the CX25840 SIF audio processing altogether.

Regards,
Andy

> Thanks,
> Chris




_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sat, Jul 17, 2010 at 10:04:24AM -0400, Andy Walls wrote:
> On Mon, 2010-07-12 at 23:20 -0500, Chris Kennedy wrote:
> > 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 didn't think that I had committed any real tinny audio fixes for the
> analog audio demodulator. All my fixes for that so far have been
> somewhat working band-aids that guess at the root cause (IMO).
>
> (Ah now I recall, Martin, IIRC, had found some CX23416 encoder startup
> timing issues on the I2S digital output side of the CX25843.)
>
> > 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.
>
> If you know you will always be watching NTSC/mono or NTSC/BTSC then
> that is perfectly fine. It will give you more reliable audio
> demodulation then letting the microcontroller do a full (World-wide)
> audio standard search when it needs to redetect the audio standard.
>
>
>
> > 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.
>
> It likely never will.
>
> I'm getting a clearer understanding of the Merlin broadcast audio
> decoder core, given what information I have on it (which is far from
> complete).
>
>
> > 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.
>
> No, the current fix solves a problem in a different part of the system:
> the digital I2S between the CX25843 and CX23416. Tinny audio at this
> interface would imply some sort of sample rate mismatch between the
> CX25843 and the CX23416. The startup timing change obviously helps the
> CX23416 get its sample rate reliably set correctly.
>
>
> Your problem is clearly originating the Merlin microcontroller and
> analog demodulator block. This is where I suspect most people's tinny
> audio is originating from.
>
> Looking at figure 3-30 in this data sheet:
>
> http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
>
> The microcontroller is labeled "Auto Std/Mode Detection" and the analog
> demodulator comprises the blocks labeled "Sound IF SRC", "Analog
> Demod/NICAM", and "DBX" (excluding the NICAM portion which is digital
> demodulation).
>
> I've spent about six hours in the past week taking a harder look at the
> analog demodulator (for which I have very little details). It's a
> flexible, very configurable block made up of a large number of smaller
> blocks to perform two high level functions: spectral analysis with
> detection and demoulation of audio signals to baseband.
>
> It of course has to perform spectral analysis, because no one in their
> right mind is going to search in the time domain for the characteristics
> of things like the BTSC spectrum:
>
> http://broadcastengineering.com/images/nov_2005/511be09_Fig2_600w.jpg
> http://www.lenrek.net/experiments/btsc-spectrum/
>
> or any other broadcast audio standard when performing autodetection.
> (Note for NTSC/mono, only the L+R portion of the spectrum is present.)
>
>
> The audio microcontroller is responsible for configuring and
> reconfiguring the total of the analog demodulation block when searching
> for audio standards and responding to events from the block (i.e.
> detection of energy at various frequencies).
>
> > 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.
>
> Right. So let's assume, that if the microcontroller is operating on
> good data, it always knows how to set up demodulation of any audio
> standard perfectly. That leaves the following problem mechanisms:
>
> 1. False detections from the spectral analysis
> (possibly due to a non random noise source (EMI) or due to
> intermodulation products caused by strong/overamplified signals).
>
> 2. Missed detections from the spectral analysis
> (possibly due to weak signals, or PLL's locking onto the wrong frequency
> inducing an incorrect frequency offset possibly due to a non-random
> noise source (EMI) or due to intermodulation products caused by
> strong/overamplified signals).
>
> 3. Contention for access to the registers for configration and
> montioring of the analog audio demodulation blocks.
> (Note on figure 3-30 both the microcontroller and I2C interface can
> access the register file.)
>
> 4. An algorithmic flaw in the micrcontroller program's search algorithm.
>
> 5. Incorrect estimation of the horizontal sync frequency.
> (BTSC spectrum use and center frequencies are based on this frequency.)
>
> 6. some combination of the above.
>
>
> Redetecion will certainly at least be triggered by transitions in the
> NTSC channel's broadcast signal from
>
> a. mono L+R audio <-> BTSC audio
> b. no audio signal <-> mono L+R audio
> c. no audio signal <-> BTSC audio
>
> I know VCR's and consumer DTV STB's only output mono L+R audio to save a
> few bucks. For those items, the transitions in b. above are the only
> ones that apply.
>
> TV channels may flip from BTSC to mono between programs, but I doubt it.
> TV stations more likely either always transmit a BTSC (with pilot) when
> transmitting an audio signal or just transmit mono L+R (which also
> should have a detectable FM carrier even when silence is being
> transmitted). I'm no broadcast engineer, so I could be wrong.
>
>
>
> > 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 microcontroller program is providing those values to us. It could
> be as simple as when you force the program to only look for BTSC, that
> it always provides a hard coded value.
>
> BY limiting the search to only BTSC, you remove the risk of false
> detections of other standards, or detections of energy at the wrong
> frequencies that appear to be "close enough".
>
>
> > The audio sounds like it's very far away in a ringing room or something
> > when the problems happen,
>
> filter or demodulator misconfiguration by the microcontroller due to
> bad information is likely the cause.
>
>
>
> > also I'm hoping that forcing the format is
> > really a fix and that for some reason it doesn't still get weird audio
>
> It greatly reduces the probably of false positive detections or
> adjusting frequency offsets based on some spurious signal.
>
>
> > .
> > 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.
>
> I think once the audio microcontroller detects a good signal, there is
> some hystersis before it declares it has lost the signal and needs to
> restart it's search. Limiting the standards for which one is searching
> limits the chance of some spurious frequency detection being interpreted
> as possibly valid.
>
>
> > 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.
>
> Sometimes, limiting it to BTSC still fails (see Mark Lord's email from a
> few months back). Then forcing a redetect becomes problematic, IIRC.
>
> Forcing an audio standard in locations where NTSC is used makes a lot of
> sense. One is pretty sure that either mono audio or BTSC is in use and
> there are not any real options for those to vary.
>
> In places that use PAL and SECAM, where differern broadcast systems have
> slightly different parameters and folks are capable of receiving the
> different standards at their locations, this wouldn't be a terribly
> helpful fix as a module option.
>
> A better option would be to have the cx25840 module respond more
> specifically to the VIDIOC_S_STD ioctl, when the user has set a very
> specific standard on an input.


I like this idea, it makes sense to me. From what your saying, and what
I can tell, basically when the card is known as in NTSC mode by the
cx25840 module then really there's no true need for audio standard
detection. It basically only has the BTSC option that it would ever
truly end up getting set for, anything else would be an error and
setting it manually would be the most reliable.

>
>
> > 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.
>
> The caveat is, sometimes it still doesn't work.

I'm still not finding the stuff in the archives from Mark Lord to
be really a big issue with at least the PVR500/150 using the cx23416
with the cx25840. I'm suspecting it's not this tinny audio issue,
at least what I've found in those emails doesn't sound like this
behavior. That sounds like an issue where the module for the cx18
loads and audio isn't present till reloading the module. I suspect
it's a whole other issue than this, if there's not something I've
missed in those emails. Something that probably would never affect
ivtv, or at least having BTSC audio set manually for NTSC setup cards
would fix a lot of tinny audio issues and possibly leave this one
issue with the cx18 that Mark Lord saw.

I'd suspect that in the ivtv driver just setting that value for
the buggy 150 card whenever it's a 150 and operating in NTSC mode
would be a fix for NTSC people experiencing tinny audio. Might
not fix it for PAL setups, not sure of the cut of percentage having
the issue on PAL setups compared to NTSC ones (or if it's only an
NTSC issue?). I'm guessing the audio micro controller is just going
to have this type of rare bug in auto detection mode, which I can
see isn't something that probably can be really fixed 100% unless you had
the next to impossible (which you detailed below) at your disposal.

I do believe though that you'd be probably the only person I know
of able to fix it if Conexant gave you those things and you had
a dataset which triggered it to use too (which of course is probably something
even they can't just give you). Definitely have the whole details
down on what is going on, but of course looks like it's at a point
where the microcontroller is a black box and inside there is where
the real bug actually needs to be fixed.


>
> To have a high probabilty chance of reliably resolving this problem
> conclusively, I'd need:
>
> 1. Good, detailed block diagrams of the Merlin and perhaps a half-way
> decent description of the Theory of Operation
>
> 2. The microcontroller program source code
>
> 3. A spectrum analyzer capture of the incoming signal's Sound IF before
> and after the transition to "tinny" audio.
>
>
> In other words, the real engineering data about the device, and a
> dataset that triggers the failure mode. I'm guessing that won't happen
> in my lifetime.
>
> Until then, forcing the audio standard and audio system is the best we
> can do, short of using the mono AF out of the analog tuner assmebly and
> bypassing the CX25840 SIF audio processing altogether.
>
> Regards,
> Andy
>
> > Thanks,
> > Chris
>
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>

--
Chris Kennedy
c@groovy.org

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel