Mailing List Archive: ivtv: devel

Tinny or distorted sound on PVR-150 using line in

Index | Next | Previous | View Threaded

noah.b.beck at gmail

Dec 8, 2008, 7:34 AM

Post #1 of 6 (3762 views)
Permalink

Tinny or distorted sound on PVR-150 using line in

I searched and found that this (or something similar) was reported back in
August: I get intermittent tinny sound in some of my MythTV recordings.
This is in a system that I set up almost two years ago. Then, it was an
FC6, myth-0.20 install with whatever the latest stable IVTV drivers from
atrpms were. I never had an audio quality problem under this software
setup. A few weeks ago, the root drive on that system died, so I don't
know exactly what IVTV version I was using then (I failed to back up the
root drive anywhere).

When I got a new root drive, I installed FC9, which installed with a
kernel-2.6.25-14 (x86_64 in case it matters), which includes the ivtv
driver already. I installed ivtv-firmware-20080701 and ivtv-utils-1.2.0-6.
I got mythtv back up running, but found that some new recordings had an
irritating tinny quality (distorted high frequencies). Initially, this
seemed to be happening on about 50% of recordings.

I downloaded the "bleeding edge" module source on 12/2, compiled and
installed the new modules, and if I look at the last 15 mythtv recordings,
it looks like 20-25% of recordings are tinny.

Yesterday, I had a chance to try some debugging. I found that if I ran
something like:

for num in {0,1}{0,1,2,3,4,5,6,7,8,9}
do
cat < /dev/video1 > /myth/tmp/file$num.mpg &
pid=${!}
sleep 5
kill -INT $pid
wait $pid
sleep 3
done

I would get 1-3 files with the tinny quality.

The August "Tininess From RCA Stereo Jacks on PVR-150" thread suggested
trying a "v4l2-ctl --set-audio-input=1" when the sound was distorted to see
if it would go away. I inserted this into the above loop:

...
pid=${!}
sleep 5
v4l2-ctl -d /dev/video1 --set-audio-input=1
sleep 5
kill -INT $pid
...

and then ran 100 times. In the first 67 recordings, I got 6 occurrences of
a recording with the tinny sound at the beginning, and in each of those,
after 5 seconds the sound returns to normal. Furthermore, for all of the
other 61 recordings that sounded fine, they sounded fine all the way
through. So, --set-audio-input=1 initiated after the recording starts,
appears to put the driver into the non-tinny state if it is tinny, and
doesn't cause a problem if the driver was already in the non-tinny state.
I added set-audio-input to my channel-change script for now. I placed one
of the 6 tinny+workaround recordings at:

http://roonabeck.bellsofireland.com/file65.mpg

The first 5 seconds sound tinny, and the next 5 seconds sound fine.

Starting with the 68th recording, and for every recording after that, the
sound became terribly distorted. I have no idea what caused this, and I
never had a mythtv recording that sounded like this before. Something
apparently became corrupted such that I had to unload and reload the module
to clear the problem, because even a mythtv recording started with the
card/driver in this state also had the same distortion. I placed a sample
of this at:

http://roonabeck.bellsofireland.com/file67.mpg

I haven't tried to reproduce this again, but thought I'd mention it. I'm
really just interested in trying to get to the bottom of the tinny audio
problem, unless this other distortion also becomes a recurring problem.

Please let me know what I can do to help narrow down the problem.

Thanks,
Noah

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

digijock223 at yahoo

Dec 8, 2008, 2:10 PM

Post #2 of 6 (3447 views)
Permalink

Re: Tinny or distorted sound on PVR-150 using line in [In reply to]

Noah Beck wrote:
> [...]
> and then ran 100 times. In the first 67 recordings, I got 6 occurrences of
> a recording with the tinny sound at the beginning, and in each of those,
> after 5 seconds the sound returns to normal. Furthermore, for all of the
> other 61 recordings that sounded fine, they sounded fine all the way
> through. So, --set-audio-input=1 initiated after the recording starts,
> appears to put the driver into the non-tinny state if it is tinny, and
> doesn't cause a problem if the driver was already in the non-tinny state.
> I added set-audio-input to my channel-change script for now. I placed one
> of the 6 tinny+workaround recordings at:
>
> http://roonabeck.bellsofireland.com/file65.mpg
>
> The first 5 seconds sound tinny, and the next 5 seconds sound fine.
>
This is a problem I have had for quite some time, across different
versions of software and OS. It seems to occur <20% of the time for me.

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

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

noah.b.beck at gmail

Dec 9, 2008, 5:15 PM

Post #3 of 6 (3420 views)
Permalink

Re: Tinny or distorted sound on PVR-150 using line in [In reply to]

> Noah Beck wrote:
>> [...]
>> and then ran 100 times. In the first 67 recordings, I got 6 occurrences of
>> a recording with the tinny sound at the beginning, and in each of those,
>> after 5 seconds the sound returns to normal. Furthermore, for all of the
>> other 61 recordings that sounded fine, they sounded fine all the way
>> through. So, --set-audio-input=1 initiated after the recording starts,
>> appears to put the driver into the non-tinny state if it is tinny, and
>> doesn't cause a problem if the driver was already in the non-tinny state.
>> I added set-audio-input to my channel-change script for now. I placed one
>> of the 6 tinny+workaround recordings at:
>>
>> http://roonabeck.bellsofireland.com/file65.mpg
>>
>> The first 5 seconds sound tinny, and the next 5 seconds sound fine.
>>
> This is a problem I have had for quite some time, across different
> versions of software and OS. It seems to occur <20% of the time for me.
>
> 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

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

digijock223 at yahoo

Dec 9, 2008, 7:21 PM

Post #4 of 6 (3429 views)
Permalink

Re: Tinny or distorted sound on PVR-150 using line in [In reply to]

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.

-Jeff

awalls at radix

Dec 10, 2008, 4:16 AM

Post #5 of 6 (3408 views)
Permalink

Re: Tinny or distorted sound on PVR-150 using line in [In reply to]

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

noah.b.beck at gmail

Dec 11, 2008, 5:41 AM

Post #6 of 6 (3390 views)
Permalink

Re: Tinny or distorted sound on PVR-150 using line in [In reply to]

[Sorry, resend with corrected subject line]

Jeff Bevis wrote:
> 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).

I missed you mentioning that the second half also has the 16kHz
cutoff. When your system exhibits this problem, do you get the same
cutoff? Do "normal" recordings also show the cutoff? I uploaded one
of my normal recordings:

http://roonabeck.bellsofireland.com/file64.mpg

I'll poke around with v4l2-dbg dumps as suggested by Andy this
weekend. If there are any suggestions for places to insert debug
statements, let me know.

Noah

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads