Re: Test report MBP built-in audio device
Re: Test report MBP built-in audio device
- Subject: Re: Test report MBP built-in audio device
- From: Brian Willoughby <email@hidden>
- Date: Mon, 25 Aug 2008 12:03:40 -0700
Mikael,
One thing which really stood out in your analysis was the claim that
"distortion measured right after the start of the signal yields [...]
0.5% distortion!" This is actually due to your tools lacking
windowing, and not an actual indication that the Apple hardware
changes it's distortion specs when your magic signal appears. Your
choice to avoid windows in your analysis may improve the graphs for a
very small selected subset of possible signals, but you're increasing
the distortion inside your tools for most other signals, and thus
your measurements are not always accurate.
Windowing is used because the FT analyses a small part of a signal as
if that part repeated forever. Unless your D/A and A/D line up
perfectly, your windowless analysis is actually looking at a
completely distorted picture of the signal, and thus you'll see very
high distortion as an artifact of your custom tools, not due to any
problem in the Apple audio circuits. In fact, this is worst case
when you start the test signal after silence, because the FT sees a
repeating waveform that is very complex - and this totally explains
the high distortion you're seeing in your custom tools.
Digital audio is full of counter-intuitive practices. We add
dithering noise to reduce quantization noise, yet the initial
reaction is "why would we want to add noise to digital audio?" We
use windowing on any signal fed to Fourier analysis to avoid
discontinuities in the signal within the buffer, yet there are some
cases where particular windowing options produce as many problems as
they cure. The challenge is to select the right windowing function
for the job, but I doubt you can measure an unknown process
accurately without any windowing at all.
Actually, now that I think about it, even if you used windowing,
you'd probably still get false readings showing high distortion at
the start of your test signal because there could still be a
discontinuity in the waveform in the middle of the buffer where most
windowing functions are not altering the signal. You need to devise
a different solution for this, and you certainly need to be careful
not to report false distortion specs for the equipment you're
measuring with unconfirmed tools.
Brian Willoughby
Sound Consulting
On Aug 25, 2008, at 05:12, Mikael Hakman wrote:
Brian,
None, in fact windowing function free methods were one of the reasons
I'm developing my own set of tools. However, this often but not
always requires special test signals to be generated and feed into
the device/software under the test.
Not that I want to argue against use of windowing function but IMHO
the only good thing multiplying the signal by a windowing function
does is to make result presentation (the charts) more pleasant to
look at. It doesn't increase the precision of the results, rather the
opposite. It "smears" out computed frequency spectrum. In fact
windowed DFT of a pure sine wave results in a DFT of the windowing
function itself, not in a single frequency spike as it should.
Spectrogram of an ideal device becomes a ridge of hills on the
diagonal instead of single one pixel wide diagonal line on otherwise
black background. (Sorry for this geodetic metaphor - I don't know
how to express this otherwise).
The other reasons for developing my own toolset are much greater
flexibility of use, my own waterproof validation of the algorithms
and their implementations, and of course the fact that I'm developing
entirely new methods not available before.
PS. Some of the charts in the report, in particular the spectrograms,
were destroyed by Open Office/PDF generation process (TIFF to JPEG
conversion I think). The original charts are much clearer and detailed.
Regards/Mikael
On Sunday, August 24, 2008 8:20 PM, Brian Willoughby wrote:
Mikael,
Which kind of windowing do you apply to the signal before the DFT
analysis? I do not see this information documented anywhere in
your paper.
Brian Willoughby
Sound Consulting
On Aug 24, 2008, at 10:39, Mikael Hakman wrote:
I have ported some of my precision tools for assessing quality of
audio devices and algorithms from Windows to OS X. I have now
used the ported tools to investigate MBP built-in audio device.
The test report is at http://www.dkab.net/Realtek HDA%
20report.pdf.
Regards/Mikael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden