• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Test report MBP built-in audio device
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test report MBP built-in audio device


  • Subject: Re: Test report MBP built-in audio device
  • From: Richard Dobson <email@hidden>
  • Date: Tue, 26 Aug 2008 15:24:06 +0100

Mikael Hakman wrote:
..


Distortion caused by a device (and possibly its driver etc.) itself, on the other hand, varies with a number of external factors. From where did you get that "a DAC cannot have stabilization time that lasts longer than one sample period"? This is untrue. I say that DACs take time to stabilize.



You can say it; but that doesn't make it true. You have to show it with evidence (from a reliable source, such as an AES paper) that can be replicated. Otherwise it is just a snake-oil argument. I say you have too much oxygen in your cables.



Can you cite an independent source for your claim that it is quite common for DAC to exhibit higher distortion at the very beginning of a signal?

I cannot cite independent source, because they don't publish this data, probably because they don't know how to measure it (in the best case) or don't want to (in the worst case) or simply because they don't do it.


Or because it is a delusion. Disortion on the scale you describe would be visually as well as aurally obvious. If it were a real effect, believe me, ~everyone~ would have documented it by now. Can't you add an imput/output waveform plot to your report?


..

You are saying this without any proof. There is nothing wrong with my analysis and the proof is that it gives correct answers if the signal does not pass through a DAC. If my computations were causing distortion variation, then this would be present also when not passing the signal though a DAC, wouldn't it? The effect is there only if there is a DAC in the path.



For all we know, you have an earth loop, or are picking up RF interference. You are making a circular argument - you say your method is correct because it produces correct results - but you are also saying you are the only person capable of producing those results.



You have difficult to accept my results because you never before seen such an analysis. Well, somebody has to be the first, in this case I'm.

Windowing or not has nothing to do with it. You are free to give me a spec for a windowing function of your choice, including all its parameters and I will repeat measurements using your function.

I propose the standard Hann Window. Frequency-domain coeffs:

Fw_t = 0.5 F_t - 0.25[ F_{t-1}+F_{t+1}]


It isn't MacBook Pro distortion that varies but in there used codec. This is normal.


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.

Worst case!? Well, about as worst as saxophone starting to play a note from silence or near silence. About as worst as an artist playing a slow classic composition on acoustic guitar and letting every note decay to low levels! What are you talking about?


Because your signal is (in effect) a sinusoid multiplied by a step function (see my other post). The step function (as does any transient) results in a multitude of harmonics (possibly variant in frequency). Inside the FFT, it is equivalent to an infinite number of very short attacks, with no steady-state. Think of it as like switching on the amp while a sound is already playing. You are analysing the click (or the speaker thump), not the signal.


...

Who said that a DAC is a perfect linear time-invariant system? On the contrary, all tests aim at assessing how far from this ideal a particular device is.



Of course they are not "perfect", but were the codec as bad as you are claiming, the machines would be unusable; worse than the cheap'n-cheerful musical card I was given a few months ago. Even cheap 24bit codecs are linear over at least 22bits these days (with the errors almost entirely at the bottom - where, in the absence of liquid cooling, brownian noise starts to get in the way).


So to be clear, are you claiming the codec is seriously time-variant, or seriously non-linear, or both?


If Fourier analysis had trouble with attack time then it would be having it even without DAC in the path, wouldn't it?

Because what? I send pure simple sine wave


We have no evidence yet of how pure your sinewave is. Have you measured it independently? Can you prove that all harmonics and noise are more than (say, generously) 100dB down? Are you generating it with analog means (what instrument), or digitally? How, exactly? Simple linear interpolation of a wavetable? Direct sine computation? Double precision?

Are you really expecting the startup of a note to show the same spectrum as the steady-state part of the note? What do you expect the spectrum of this to be (ASCII art, needs mono-spaced font):

              ________________ (envelope)
              | /\      /\
______________|/  \    /  \
0------------------------------
               ^   \  /    \
(discontinuity)|    \/      \ etc (pretend this is a sine!)

t=0                           t=1024

?

Richard Dobson


_______________________________________________ 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
  • Follow-Ups:
    • Re: Test report MBP built-in audio device
      • From: Richard Dobson <email@hidden>
References: 
 >Test report MBP built-in audio device (From: "Mikael Hakman" <email@hidden>)
 >Re: Test report MBP built-in audio device (From: Brian Willoughby <email@hidden>)
 >Re: Test report MBP built-in audio device (From: "Mikael Hakman" <email@hidden>)
 >Re: Test report MBP built-in audio device (From: Brian Willoughby <email@hidden>)
 >Re: Test report MBP built-in audio device (From: "Mikael Hakman" <email@hidden>)
 >Re: Test report MBP built-in audio device (From: Brian Willoughby <email@hidden>)
 >Re: Test report MBP built-in audio device (From: "Mikael Hakman" <email@hidden>)

  • Prev by Date: Re: Test report MBP built-in audio device
  • Next by Date: Re: Test report MBP built-in audio device
  • Previous by thread: Re: Test report MBP built-in audio device
  • Next by thread: Re: Test report MBP built-in audio device
  • Index(es):
    • Date
    • Thread