On Tue, 2008-12-09 at 19:21 -0800, Jeff Bevis wrote:
> Noah Beck wrote:
> > > [...]
> > >
> > > I examined your "file65.mpg" and it appears to have no frequency content
> > > above 16KHz, except for a handful of odd bursts at a few specific
> > > frequencies > 16Khz during the first 5 seconds. The "tinny" sound would
> > > appear to be due to frequency aliasing due caused by undersampling.
> > > The aliasing would be the cause of the apparent "tinny" sound.
> > >
> > > What is the special significance to the 16Khz-cutoff, being that it's
> > > exactly 1/3 of the sampling frequency? Well, if you're sampling a
> > > signal at 32KHz, but that signal has frequency content above 16KHz, it
> > > "folds back" around the 16KHz frequency. There seems to be just too
> > > much higher-frequency content to be accounted for in this way in your
> > > file. I'm puzzled by this. There seems to be more going on, involving
> > > oversampling as well, perhaps, to arrive at this result.
> > >
> > > -Jeff
> > >
> >
> > That's interesting. The card also supports a 32KHz sample rate,
> > doesn't it? Is there a chance that something is using a 48KHz
> > algorithm with a 32KHz sample rate?
> >
> > Noah
> >
> Hey Noah,
>
> I think you're probably right, though I can't draw any conclusions
> about why it is, only that it appears to have happened. I wish I was
> familiar with the code, because I need an answer, too!
>
> I'm really glad you provided samples, because that lets me know that
> we're talking about the same phenomenon. What I can say, with
> reasonable confidence, is that the audio in your file has undergone
> sampling at 32KHz somewhere during its life. I failed to mention
> before that the file itself has a sample rate of 48KHz! Therefore it
> should have measurable frequency components above 16KHz (if only due
> to noise in the analog domain).
>
> That means there was an upsampling to 48KHz as the later step, unless
> somebody has a really darn good 16KHz lowpass filter ;-) Even if the
> source signal was 16KHz band-limited, noise should show up above
> 16KHz.
>
> What was really strange were the little bursts in the first 5 seconds.
> They were at narrow frequencies, and there were just a handful of
> them. If I had to guess, I'd say somebody made a 48KHz mp3 and threw
> out most of the high frequency components, giving the impression of
> 32KHz sampling. But... that doesn't really explain the 16KHz cutoff
> on the remaining ("good sounding") audio after 5 sec mark.
>
> Perhaps these observations will give rise to some driver-level ideas
> about how this could even be possible.
Right so let's work with the assumption that something got set to 32
ksps, or a lowpass/antialias filter for 32 kbps got turned on. The
Nyquist frequency for 32 ksps is 16 kHz.
So there are only a few ways this can happen:
1. The driver misconfigured things upon opening the capture and setting
the parameters
2. The driver set things properly but an error on the PCI bus or
something in the firmware itself rejected the request and the driver
didn't notice the error.
3. The audio standard detection microcontroller in the CX25843 decided
to change CX25843 filter settings based on what it saw on the tuner
input.
A few things have to be set up for good audio:
The wm8775 sample clocks
The cx25843 sample clocks
The cx25843 audio filters in path 1
The cx23416 MPEG encoder has to be told the correct sample rate
The cx25843 audio standard detection microcontroller should be ideally
stopped or least have stable SIF audio coming from the tuner, so it
won't change things behind your back.
An failure to properly set these things up could lead to audio problems.
Looking at dumps of registers of the cx25843 with v4l2-dbg (differential
analysis) and well placed log statements in the driver and the ability
to reliably reproduce the problem could help find the failure mode.
BTW
I know the cx25840 module, for 32 ksps tuner audio which doesn't seem to
be at issue here, sets up the audio sample clock PLL VCO to 196 MHz.
That's outside its valid, publicly specified range of 200-600 MHz. It's
surprising that the VCO works under these conditions as the equivalent
PLL doesn't in the CX23418. I had to fix that one.
Regards,
Andy
> -Jeff
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
