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: Mikael Hakman <email@hidden>
- Date: Mon, 25 Aug 2008 20:27:54 +0200
On Aug 25, 2008, at 4:49 PM, Richard Dobson wrote:
Mikael Hakman wrote:
> None,
That would indicate the rectangular window, therefore.
This is one way to look at it - a rectangular window of height 1
extending from 0 to infinity. But then all signals not filtered in any
way could be said to be filtered by such a rectangular window, and
then not only once but infinite number of times. I am aware of this
point of view but in my taste this is too much of bending the reality
to the theory. I prefer the other way around. If the signal is not
filtered then it simply isn't filtered.
> 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.
A Hann or similar tapered window is a low-pass filter. It reveals
lower-level components by suppressing the strong sidebands of the
rectangular window spectrum. Nothing to do with "precision" as such
(that would be determined more by the window length, which appears
to be unspecified in your report). But very much to do with
detecting a wide dynamic range of signal components, essential for
tasks such as detection of alias and distortion components.
Because as you say it is a filter, it changes the signal, and
therefore the signal you analyze after filtering is not the one I want
analyze. Therefore the results it produces are different from what you
get when analyzing unfiltered signal. Then, by definition, it produces
biased results, i.e. less precise.
> 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.
It results in a convolution of the FT of the window with that of the
signal. Even with a rectangular window, you will only get a single
spectral line if the period of the signal matches that of the window
~exactly~. Even with a DFT, that will not happen unless the signal's
period is an exact integer number of samples. In all other cases,
sidelobes will appear.
Convolution of FT of the window with that of the signal is the FT of
the window shifted to the position of spectral line of the signal if
the signal is pure sine wave. This is what I said. Using my approach,
I get single spectral line when there should be a single spectral line.
> 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).
>
Those are the DFT/window side-lobes - might as well use the
established technical language! Are you actually using a raw DFT
algorithm or an FFT? What length in samples?
Exactly, as I said, what you see for a perfect device is DFT of the
window function. I'm using a language that other readers than you can
also understand. Just because a guy can write down expression "side-
lobes" doesn't necessarily mean he understands the math of what he is
talking about, if we are going to pick on each other here, that is.
Does it matter whether it is FFT or some other DFT method? There are
many, I designed a few myself.
My tools work with a library of DFT algorithms. I can select what
algorithm to use at run-time. Most of these work with any even sample
length. However, because the best (most robust and precise) algorithms
are slow and implemented in Java (like all my tools), the number of
samples feed into DFT is dictated by the time you want to wait for
results. And also by the signal time you are prepared to average over.
The report was done using correlation-based DFT with 4800 samples,
i.e. 100 milliseconds at 48 kHz SR. I have validated that this number
of samples gives correct answers when analyzing synthetic signals for
which I knew the answers.
Also, one of your plots in that report shows a chirp signal.
Rectangular windowing will not help you there; rather, it will help
to conceal lower-level components, whether from harmonics in the
signal itself, or generated by the system under test. Several are
visible in the plot (where the ascending line is reflected downwards
from Nyquist); with a low-pass window those alias components (and
the extent of them) would be very much more visible.
The test signal is perfect (down to -320 - -350 dB, see my last
comment at the end of this post). All artifacts in the measured signal
(device response) is result of the device processing that perfect
signal. This includes quantization distortion, but using 24-bits gives
only about -144 dB in total, and only around -160 dB for individual
frequencies. This is why I'm using -140 dB z-axis floor on
spectrograms. As I said before, Open Office/PDF conversion destroyed
the charts to some degree. The original charts are much more clear and
detailed. You can clearly see both the harmonic lines and the Nyquist
reflections (aliases), and what levels they are on. There are many
ways to visually enhance such charts, using non-linear z-axis is one,
often criticized way. I prefer to see things in the proportions they
actually have.
But to see even that amount of aliasing with a rectangular window
indicates either that the input sinusoid itself has a high
proportion of harmonics (i.e. distortion), or the system does.
Including a plot of the spectrum of the input would help -
describing it simply as a "specially designed test signal" is not
really very informative. How do you generate it?
Spectrogram of the input consists of one-pixel wide red (0 dB)
diagonal line going from (0,0) to (24000,24000) on otherwise entirely
black background (using the same z-axis floor as in the report). As I
said, I'm using perfect input signals. Anything you see on the
spectrograms in the report, that isn't on that line, and isn't black
is generated by the device in question, i.e. it is distortion,
harmonic or not.
Also, all physically realisable audio systems have a finite
frequency response (and all digital ones of course, +- Nyquist).
Both the ADC and the DAC will have more-or-less effective anti-alias
filters (more-or-less brickwall), such that any "ideal" pulse will
of course be converted to a sinc-like waveform. In this sense, there
can be no such thing as a "perfect device".
Nobody said there is. The purpose of all testing is to assess how
close to or far from a perfect device the actual device is, and to
compare one imperfect device to another. Then again, a hypothetical
device with finite but entirely rectangular frequency response will
produce exact sinc(x) waveform.
I would suggest including more source-response comparisons in your
reports; and allowing those reading it to form their own conclusions
by including both rectangular and low-pass windowed measurements,
and including a detailed description of the test signal.
I didn't include charts for the input (test) signals because there is
nothing interesting there. Single pulse response is a spike (pure
delta function) located at 0 and extending from 0 to 1 FS. Frequency
response is horizontal line at 0 dB extending from 0 to 24000 Hz. S/N
is at 144 dB (using 24-bit quantization). THD+N is the same but
negative of course, at all frequencies and all times. Spectrogram of
the input consists of one-pixel wide red (0 dB) diagonal line going
from (0,0) to (24000,24000) on otherwise entirely black background
(using the same z-axis floor as in the report). As I said, I'm using
perfect input signals. All test signals are generated with 64-bit
(double) precision, what you eventually can see on input is the effect
of 24-bit quantization, but then this is also a property of the
device. I can feed it with 64-bits if it can take that much.
When I get time then perhaps I will include charts for my perfect test
signals as well. Right now there are more interesting things to do,
such as porting more tests from XP to OS X and, of course, developing
new methods.
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