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 [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
