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