Discussion of the jack audio server and jack applications

Paul Davis | 10 Dec 2009 03:50

Fwd: Audio recording bitdepth

somebody else who knows what he is talking about ...

---------- Forwarded message ----------
From: Brian Willoughby <brianw <at> sounds.wa.com>
Date: Wed, Dec 9, 2009 at 9:02 PM
Subject: Re: Audio recording bitdepth
To: CoreAudio API <coreaudio-api <at> lists.apple.com>
Cc: Ross Bencina <rossb-lists <at> audiomulch.com>, Bjorn Roche
<bjorn <at> xowave.com>, Paul Davis <paul <at> linuxaudiosystems.com>

The problem with this whole thread is that there is no downgrade in
fidelity with the conversion method used by CoreAudio.  All the rest
of the comments assume that there is a superior method when there
really isn't one.

Bjorn proposes in his blog that there are two good choices for
conversion methods.  I'll call them A and B.  Method A is used by
Apple in CoreAudio.  Method B is the 'asymmetrical' option.  Bjorn
claims that they are both good, with each method having specific
benefits and drawbacks.  The problem is that Bjorn's hypothesis has
not been peer-reviewed, and does not stand up to basic mathematical
principles.  Bjorn's own tests do not reveal the flaws in method B
because his tests are incomplete and do not have a solid basis.

In a nutshell, Bjorn's asymmetrical conversion introduces non-linear
distortion by processing positive values differently than negative
values.  Ross' comments about CPU efficiency are a diversion from the
fact that all processing on the distorted waveforms would make this
distortion irreversible.  Bjorn's tests only happen to reverse this
non-linear distortion for the one special case where no processing is

(Continue reading)

headers

Jörn Nettingsmeier | 10 Dec 2009 04:37

Re: Fwd: Audio recording bitdepth

Paul Davis wrote:
> somebody else who knows what he is talking about ...

interesting thread, thanks for forwarding. this last post you quoted
should pretty much end the debate.
but it's good to know about all those potential pitfalls, such as the
(obvious, once you've thought about it) deficiency of the standard c
sine function...

--

-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Elektrofachkraft
Audio and event engineer - Ambisonic surround recordings

http://stackingdwarves.net

headers

Jussi Laako | 10 Dec 2009 08:50

Re: Fwd: Audio recording bitdepth

On 12/10/2009 05:37 AM, Jörn Nettingsmeier wrote:
> but it's good to know about all those potential pitfalls, such as the
> (obvious, once you've thought about it) deficiency of the standard c
> sine function...

AFAIK, when FPU is used it is not linearly interpolated, but from the
available documentation I've understood that the FPU uses LUT up to
certain accuracy and then iterative process to calculate remaining
precision.

Intel's IA32 Basic Architecture document states in chapter
"Transcendental Instruction Accuracy" that the error when rounding to
nearest is less than 1 ulp (units in the last place). See the said
document for the definition of "ulp".

IMO, since the highest bit-depth audio DACs are now 32-bit the precision
is good enough for any practical use in audio (>200 dB)...

headers

fons | 10 Dec 2009 11:37

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 04:37:06AM +0100, Jörn Nettingsmeier wrote:

> interesting thread, thanks for forwarding. this last post you quoted
> should pretty much end the debate.

I agree.

> but it's good to know about all those potential pitfalls, such as the
> (obvious, once you've thought about it) deficiency of the standard c
> sine function...

No need to panic about that. Jaaa's sine generator uses
a 4096 point LUT with linear interpolation. The highest
spurious I've ever seen is -144 dB below the sine level.

Replacing this by just sinf() improves this to -150 dB,
and using -ffast-math doesn't change that result.
This is perfectly consistent with the precision of the
float type - given that precision you can't do better.

Ciao,

--

-- 
FA

headers

Paul Davis | 10 Dec 2009 13:34

Re: Fwd: Audio recording bitdepth

2009/12/10  <fons <at> kokkinizita.net>:
> On Thu, Dec 10, 2009 at 04:37:06AM +0100, Jörn Nettingsmeier wrote:
>
>> interesting thread, thanks for forwarding. this last post you quoted
>> should pretty much end the debate.
>
> I agree.

great, except that the same poster (Brian Willoughby) subsequently
wrote to me, regarding JACK's use of 0x7fff and 0x7fffff for scaling
between int+float:

--------
The correct conversion factors are 0x8000 and 0x800000, for 16-bit and
24-bit, respectively.  You cannot have more than one non-zero bit in a
conversion factor without introducing the potential for additional
noise.  It's true that most cases will end up with rounding covering
up the added bits, but the safest choice is to do it right in the
first place, using a method which will produce the correct results no
matter how the values are rounded, truncated, or dithered.

One way to make sense of the proof for this is to think of how
multiplication is implemented.  When humans multiply values on paper,
we handle one digit at a time, adding up the partial results to get
the total.  I'm sure you can remember how this is done, because I
don't think I can explain it in text.  Anyway, binary multiplication
is similar.  To multiply X * Y, the long version of the algorithm
looks at each non-zero bit in X, and then adds an appropriately
shifted copy of Y to a running total.  At the end, you have X*Y, with
the correct result, provided that the answer has enough bits to hold

(Continue reading)

headers

fons | 10 Dec 2009 14:13

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 07:34:56AM -0500, Paul Davis wrote:

> 2009/12/10  <fons <at> kokkinizita.net>:
> > On Thu, Dec 10, 2009 at 04:37:06AM +0100, Jörn Nettingsmeier wrote:
> >
> >> interesting thread, thanks for forwarding. this last post you quoted
> >> should pretty much end the debate.
> >
> > I agree.
> 
> great, except that the same poster (Brian Willoughby) subsequently
> wrote to me, regarding JACK's use of 0x7fff and 0x7fffff for scaling
> between int+float:
> 
> --------
> The correct conversion factors are 0x8000 and 0x800000, for 16-bit and
> 24-bit, respectively.  You cannot have more than one non-zero bit in a
> conversion factor without introducing the potential for additional
> noise.  It's true that most cases will end up with rounding covering
> up the added bits, but the safest choice is to do it right in the
> first place, using a method which will produce the correct results no
> matter how the values are rounded, truncated, or dithered.

Which is what I wrote before.

> One way to make sense of the proof for this is to think of how
> multiplication is implemented. 
> ...

A long-winded way of saying that when dividing by 0x8000 or 0x800000

(Continue reading)

headers

Paul Davis | 10 Dec 2009 14:36

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 8:13 AM,  <fons <at> kokkinizita.net> wrote:
> On Thu, Dec 10, 2009 at 07:34:56AM -0500, Paul Davis wrote:
>
>> 2009/12/10  <fons <at> kokkinizita.net>:
>> > On Thu, Dec 10, 2009 at 04:37:06AM +0100, Jörn Nettingsmeier wrote:
>> >
>> >> interesting thread, thanks for forwarding. this last post you quoted
>> >> should pretty much end the debate.
>> >
>> > I agree.
>>
>> great, except that the same poster (Brian Willoughby) subsequently

>> The correct conversion factors are 0x8000 and 0x800000, for 16-bit and
>> 24-bit, respectively.

> Which is what I wrote before.

>>  I'd be very curious to see anyone make a
>> valid argument against using 0x8000 and 0x800000.
>
> I surely won't. Frankly I've never understood why one would ever
> try to divide unity in 0x7FFF equal parts (which is impossible
> with a binary format), while 0x8000 is the natural way to do it.

grep 'define SAMPLE' $J/drivers/alsa/memops.c
#define SAMPLE_24BIT_SCALING  8388607.0f
#define SAMPLE_16BIT_SCALING  32767.0f
#define SAMPLE_24BIT_MAX  8388607
#define SAMPLE_24BIT_MIN  -8388607

(Continue reading)

headers

fons | 10 Dec 2009 15:14

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 08:36:49AM -0500, Paul Davis wrote:

> so are we now moving towards the two _SCALING constants being 1 larger
> than they are at present?

I would have preferred that for a long time.
Note that some other changes may be required to ensure
correct clipping. I can work out the details if you like.

Again, the result to be accepted is that clipping will
occur at -0.00013 dB instead of 0 dB for 16 bit.

(this is (0x7FFF + 0.5) / 0x8000 in dB)

Ciao,

--

-- 
FA

headers

fons | 10 Dec 2009 20:05

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 08:36:49AM -0500, Paul Davis wrote:

> so are we now moving towards the two _SCALING constants being 1 larger
> than they are at present?

The attached .diff should do the trick.

(based on 0.116.2)

Ciao,

--

-- 
FA

--- memops-orig.c	2008-11-22 12:54:59.000000000 +0100
+++ memops.c	2009-12-10 20:02:28.000000000 +0100
 <at>  <at>  -34,39 +34,21  <at>  <at> 

 #include <jack/memops.h>

-/* Notes about these *_SCALING values.
-
-   the MAX_<N>BIT values are floating point. when multiplied by
-   a full-scale normalized floating point sample value (-1.0..+1.0)
-   they should give the maxium value representable with an integer
-   sample type of N bits. Note that this is asymmetric. Sample ranges 
-   for signed integer, 2's complement values are -(2^(N-1) to +(2^(N-1)-1)
-
-   Complications

(Continue reading)

headers

Jussi Laako | 10 Dec 2009 20:34

Re: Fwd: Audio recording bitdepth

On 12/10/2009 03:13 PM, fons <at> kokkinizita.net wrote:
>>  I'd be very curious to see anyone make a
>> valid argument against using 0x8000 and 0x800000.
> 
> I surely won't. Frankly I've never understood why one would ever
> try to divide unity in 0x7FFF equal parts (which is impossible
> with a binary format), while 0x8000 is the natural way to do it.

My opinion on the case is that the case for straight int-float-int
conversion case is practically useless. And for anything else, real
world signal is always something else than +1.0 or -1.0. And practically
never any exactly representable value either.

Thus for any real world signal, any conversion factor is as good as any
other. For a real signal, there's always quantization error.

headers

fons | 10 Dec 2009 22:05

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 09:34:07PM +0200, Jussi Laako wrote:

> On 12/10/2009 03:13 PM, fons <at> kokkinizita.net wrote:
> >>  I'd be very curious to see anyone make a
> >> valid argument against using 0x8000 and 0x800000.
> > 
> > I surely won't. Frankly I've never understood why one would ever
> > try to divide unity in 0x7FFF equal parts (which is impossible
> > with a binary format), while 0x8000 is the natural way to do it.
> 
> My opinion on the case is that the case for straight int-float-int
> conversion case is practically useless. And for anything else, real
> world signal is always something else than +1.0 or -1.0. And practically
> never any exactly representable value either.
> 
> Thus for any real world signal, any conversion factor is as good as any
> other. For a real signal, there's always quantization error.

The quantisation error is added when representing the signal
as integer valued samples. A power-of-two conversion factor
allows to convert these integers to floats without adding
more errors. That's all. As long as the resolution of the
floats is much higher than the ints the conversion factor
doesn't matter. But that's not the case for 24 bits. OTOH,
for 24 bits quantisation error is swamped by thermal noise.
So indeed in practice it doesn't matter very much. But I
see no reason to prefer 0x7FFF over 0x8000. 

Ciao,

(Continue reading)

headers

Jussi Laako | 10 Dec 2009 23:47

Re: Fwd: Audio recording bitdepth

On 12/10/2009 11:05 PM, fons <at> kokkinizita.net wrote:
> The quantisation error is added when representing the signal
> as integer valued samples. A power-of-two conversion factor

There's always certain amount of quantization error of real world
signals in any finite precision presentation.

>>> This is perfectly consistent with the precision of the
>>> > > float type - given that precision you can't do better.
>> > 
>> > Actually, you can if the used bandwidth is less than Nyquist.
> We're probably talking about different things here. 
> But you could try to explain.

Maybe, I'm talking about noise shaping on non-Nyquist sampling systems.

headers

fons | 11 Dec 2009 00:22

Re: Fwd: Audio recording bitdepth

On Fri, Dec 11, 2009 at 12:47:11AM +0200, Jussi Laako wrote:
> On 12/10/2009 11:05 PM, fons <at> kokkinizita.net wrote:

> > The quantisation error is added when representing the signal
> > as integer valued samples. A power-of-two conversion factor
> 
> There's always certain amount of quantization error of real world
> signals in any finite precision presentation.

Yes, finite precision -> quantization noise. And... ? 
What point are you trying to make ?

> >>> This is perfectly consistent with the precision of the
> >>> > > float type - given that precision you can't do better.
> >> > 
> >> > Actually, you can if the used bandwidth is less than Nyquist.
> > We're probably talking about different things here. 
> > But you could try to explain.
> 
> Maybe, I'm talking about noise shaping on non-Nyquist sampling systems.

Which is indeed something completely different and of no
concern to the problem discussed in this thread.

Ciao,

--

-- 
FA

headers

Jussi Laako | 11 Dec 2009 08:20

Re: Fwd: Audio recording bitdepth

On 12/11/2009 01:22 AM, fons <at> kokkinizita.net wrote:
> Yes, finite precision -> quantization noise. And... ? 
> What point are you trying to make ?

That there are also other sources of error than float->int conversion.
And for recent 32-bit DACs precision of single precision floating point
is not event sufficient.

And in the end, the quality of DSP algorithms inside the DAC chip
(and/or on external SRC) tend to dominate.

>> Maybe, I'm talking about noise shaping on non-Nyquist sampling systems.
> 
> Which is indeed something completely different and of no
> concern to the problem discussed in this thread.

For me it's not. I use 192 kHz sample rate most of the time and move
some of the quantization noise to 40-80 kHz band to gain extra SNR in 20
Hz - 20 kHz audio band.

headers

fons | 11 Dec 2009 10:49

Re: Fwd: Audio recording bitdepth

On Fri, Dec 11, 2009 at 09:20:39AM +0200, Jussi Laako wrote:

> On 12/11/2009 01:22 AM, fons <at> kokkinizita.net wrote:
> > Yes, finite precision -> quantization noise. And... ? 
> > What point are you trying to make ?
> 
> That there are also other sources of error than float->int conversion.
> And for recent 32-bit DACs precision of single precision floating point
> is not event sufficient.

32-bit audio DACs ? The bottom 8 bits (and probably a few more)
could be a good random generator, nothing else. What's the S/N
ratio of the analog input of these converters ?

> >> Maybe, I'm talking about noise shaping on non-Nyquist sampling systems.
> > 
> > Which is indeed something completely different and of no
> > concern to the problem discussed in this thread.
> 
> For me it's not. I use 192 kHz sample rate most of the time and move
> some of the quantization noise to 40-80 kHz band to gain extra SNR in 20
> Hz - 20 kHz audio band.

We were discussing Jack's I/O conversions. Jack does not upsample.
Without upsampling noise shaping does not improve the total noise
energy, nor the distribution of the errors. It just changes the
spectrum.

Ciao,

(Continue reading)

headers

Jussi Laako | 11 Dec 2009 19:30

Re: Fwd: Audio recording bitdepth

On 12/11/2009 11:49 AM, fons <at> kokkinizita.net wrote:
> 32-bit audio DACs ? The bottom 8 bits (and probably a few more)
> could be a good random generator, nothing else. What's the S/N
> ratio of the analog input of these converters ?

Yep, devices like ES9018, AK4399 and PCM1795 accept 32-bit input data.
Of which PCM1795 seems to be best, noise spectrum upwards from 1 kHz
seems to be around -156 dB.

SNR is not very good value since it doesn't tell anything about spectral
distribution of the noise. For example phono preamps tend to have poor
SNR value, but in the end noise slope follows RIAA equalization plus
contains extra noise on bass/subsonic frequencies.

> We were discussing Jack's I/O conversions. Jack does not upsample.
> Without upsampling noise shaping does not improve the total noise
> energy, nor the distribution of the errors. It just changes the
> spectrum.

Yes, that's why I said that it depends if used bandwidth is less than
Nyquist. And even if there's no upsampling, is there much content in the
ultrasonic band and should the space there be utilized for improving the
SNR on lower frequencies?

I just found it a bit oversimplification since the original posting
seemed to list only rouding and flat dither methods for conversion while
there's also third way...

headers

Jussi Laako | 11 Dec 2009 19:38

Re: Fwd: Audio recording bitdepth

On 12/11/2009 08:30 PM, Jussi Laako wrote:
> Yep, devices like ES9018, AK4399 and PCM1795 accept 32-bit input data.
> Of which PCM1795 seems to be best, noise spectrum upwards from 1 kHz
> seems to be around -156 dB.

Actually found the figures for the ES9008 where the noise floor of the
modulator is at -160 dB.

headers

Jussi Laako | 11 Dec 2009 19:59

Re: Fwd: Audio recording bitdepth

Let me put my opinion straight. The conversion factor discussion is
nitpicking in most practical cases. But if we want to go to the extreme,
then we should use something better than just rounding with or without
dither.

And then the precision of float is not anymore enough in first place to
feed new DACs with full precision data for their internal processing...

headers

fons | 11 Dec 2009 22:03

Re: Fwd: Audio recording bitdepth

On Fri, Dec 11, 2009 at 08:38:59PM +0200, Jussi Laako wrote:

> On 12/11/2009 08:30 PM, Jussi Laako wrote:
> > Yep, devices like ES9018, AK4399 and PCM1795 accept 32-bit input data.
> > Of which PCM1795 seems to be best, noise spectrum upwards from 1 kHz
> > seems to be around -156 dB.
> 
> Actually found the figures for the ES9008 where the noise floor of the
> modulator is at -160 dB.

Again this must be a noise density in an unspecified BW,
hence meaningless. 

You should really learn to interpret a datasheet instead
of believing all those figures blindly, apparently even
without understanding some of them such as the -160 above.

For example for the ES9008 we have:

Full scale differential output current: 4.224 mA pp.
Full scale differential voltage output: 3.3V pp.

This means that the impedance at that point is 781 ohm.
This will produce a thermal noise of -126 dBV at room
temperature.

3.3V pp means 1.167 V rms, or +1.34 dBV. So the unweighted
S/N ratio of this device can never be better than -127.3 dB.
It will produce that noise even when you just feed it 32-bit
zeros. And that is without the required external amplifier.

(Continue reading)

headers

fons | 11 Dec 2009 21:30

Re: Fwd: Audio recording bitdepth

On Fri, Dec 11, 2009 at 08:30:19PM +0200, Jussi Laako wrote:

> On 12/11/2009 11:49 AM, fons <at> kokkinizita.net wrote:
> > 32-bit audio DACs ? The bottom 8 bits (and probably a few more)
> > could be a good random generator, nothing else. What's the S/N
> > ratio of the analog input of these converters ?
> 
> Yep, devices like ES9018, AK4399 and PCM1795 accept 32-bit input data.
> Of which PCM1795 seems to be best, noise spectrum upwards from 1 kHz
> seems to be around -156 dB.

You mean fig 20 in the data sheet ? That is noise *density*.
You can make that figure as low as you want by decreasing
the measurement bandwidth. It is completely meaningless if
the bandwidth is not specified. In this case this seems to
be Fs/32K, or around 1.5Hz. Assuming the densitiy is flat
over most of the audio ranget, To get the noise level in the
audio band you have to add 10*log10(20e3/1.5) or around
41 dB.  Which produces 115 dB, a realistic figure. But well
below the official one so I wonder how they measured that.

>From my data sheets:

ES9008 : 128 dB(A) or around 125 dB. You can gain a few
dB by combining channels.
PCM1795 and AK4399 : 126 dB(A), 123 dB. 

These corresponds to 20...21 bits. This also means that
this noise has nothing to do with quantisation noise,
and any oversampling and noise shaping tricks will *not*

(Continue reading)

headers

Jussi Laako | 11 Dec 2009 22:32

Re: Fwd: Audio recording bitdepth

On 12/11/2009 10:30 PM, fons <at> kokkinizita.net wrote:
> You mean fig 20 in the data sheet ? That is noise *density*.

Noise density vs signal density matters and spectral distribution
matters. Absolute noise level vs signal level doesn't. You can generate
0 dBFS pink noise and mix 5 kHz sine tone at -6 dBFS to it and the sine
can still be heard without trouble. Noise matters only when it
completely masks the signal.

This is also why vinyl rumble and tape hiss doesn't matter that much.

> be Fs/32K, or around 1.5Hz. Assuming the densitiy is flat
> over most of the audio ranget, To get the noise level in the
> audio band you have to add 10*log10(20e3/1.5) or around

That's especially wrong assumption because it's not flat. Typical
voltage and current noise has it's own frequency slope as well as
thermal noise. Neither of these are flat and these noise types dominate
when signal is good enough.

> These corresponds to 20...21 bits. This also means that
> this noise has nothing to do with quantisation noise,
> and any oversampling and noise shaping tricks will *not*
> improve it. 

Feed the DAC with 16-bit data and set attenuation to normal quiet volume
setting like -70 dB and suddenly it begins to matter. Feed it with
32-bit data and you can still use digital attenuation at -100 dB and
still without quantization noise.

(Continue reading)

headers

fons | 11 Dec 2009 23:10

Re: Fwd: Audio recording bitdepth

On Fri, Dec 11, 2009 at 11:32:48PM +0200, Jussi Laako wrote:

> On 12/11/2009 10:30 PM, fons <at> kokkinizita.net wrote:
> > You mean fig 20 in the data sheet ? That is noise *density*.
> 
> Noise density vs signal density matters and spectral distribution
> matters. 

The term "density" has meaning only for noise-like signals.
And I did not say that noise denstity "doesn't matter".
But it's not a S/N ratio and you were using it as such.

> Absolute noise level vs signal level doesn't.

You're joking ?

> You can generate 0 dBFS pink noise and mix 5 kHz sine tone
> at -6 dBFS to it and the sine can still be heard without
> trouble. Noise matters only when it completely masks the signal.
> This is also why vinyl rumble and tape hiss doesn't matter that much.

Most music listeners would disagree with that.

> That's especially wrong assumption because it's not flat.

According to that figure it is more or less flat over most
of the audio range. And even if it isn't flat you can still
integrate it, and you will in this case get something that
is even worse than my optimistic calculation.

(Continue reading)

headers

Jussi Laako | 11 Dec 2009 23:45

Re: Fwd: Audio recording bitdepth

On 12/12/2009 12:10 AM, fons <at> kokkinizita.net wrote:
> The term "density" has meaning only for noise-like signals.
> And I did not say that noise denstity "doesn't matter".
> But it's not a S/N ratio and you were using it as such.

OK, and let's take a sound of a crash cymbal as extreme example. What
kind of signal is it? And then something like freely vibrating guitar
string as another extreme?

I could give another example, I recently implemented conversion for
DSDIFF files. For a 1-bit signal sampled at 2.8 MHz or 5.6 MHz "SNR" is
really poor for the Nyquist bandwidth. However, the amount of noise in
the audio band is really low...

> Most music listeners would disagree with that.

I've been working on sonar systems for quite some time, and there it's
all about extracting signals out of noise. And being able to listen
signals buried deeply into the noise.

> According to that figure it is more or less flat over most
> of the audio range. And even if it isn't flat you can still
> integrate it, and you will in this case get something that
> is even worse than my optimistic calculation.

Check the logarithmic frequency plots. Usually there's a heavy peak
between 0.x Hz and 10 Hz. From audio point of view it doesn't matter if
there's -90 dB noise at 10 Hz. And it's not rare that there's a spike at
50 Hz (in Europe) which is even some tens of dB's higher than the noise
floor. Still this doesn't harm too much either because it doesn't mask

(Continue reading)

headers

Jussi Laako | 12 Dec 2009 00:14

Re: Fwd: Audio recording bitdepth

On 12/12/2009 12:10 AM, fons <at> kokkinizita.net wrote:
>> This is also why vinyl rumble and tape hiss doesn't matter that much.
> 
> Most music listeners would disagree with that.

And by the way, given the increasing sales of vinyl and decreasing CD
sales I would say they don't. Vinyl just sounds so much better than most
of today's overcompressed and clipped digital crap. :)

SACD also has quite some amount of ultrasonic noise even after
filtering, but people still prefer that sonically over CD... (Like I do) ;)

And SACD has over 120 dB of audio band SNR, regardless of only 1 bit per
sample being used. ;)

headers

Jussi Laako | 12 Dec 2009 01:52

Re: Fwd: Audio recording bitdepth

OK, let's put the question graphically. Which one of these two is better
for 16-bit?
http://www.sonarnerd.net/tmp/conv.png

And does that matter more than the +-1 change in the conversion factor
for 24-bits which is practically buried in noise?

Not that I would have anything against the change in conversion factor.

But before worrying about that I would worry more about couple of other
things... :)

headers

fons | 12 Dec 2009 12:01

Re: Fwd: Audio recording bitdepth

On Sat, Dec 12, 2009 at 02:52:40AM +0200, Jussi Laako wrote:

> OK, let's put the question graphically. Which one of these two is better
> for 16-bit?
> http://www.sonarnerd.net/tmp/conv.png

Depends on the definition of 'better', which would in 
turn depend on the application. 

AFAICS this is a simple noise shaping demo and not in
any way relevant to the 2^N vs 2^N-1 choice.

Caio,

--

-- 
FA

headers

Jussi Laako | 12 Dec 2009 12:52

Re: Fwd: Audio recording bitdepth

On 12/12/2009 01:01 PM, fons <at> kokkinizita.net wrote:
> AFAICS this is a simple noise shaping demo and not in
> any way relevant to the 2^N vs 2^N-1 choice.

I was mostly relating to the importance of the change. And I find it
missing from the original (blog post) article as being part of
conversion and possible word length reduction.

Now it just becomes even more cumbersome to generate 0 dBFS signals with
jack since the target output resolution is not known. Maybe I'll just
begin to apply 0.5 dB safety margin in all generators and lack support
for 0 dBFS...

IMO, 1.0 and -1.0 should be legal.

Clipping signals causes distortion. And also overshoot in the subsequent
DAC's interpolation filter and may cause also modulator resets, even
though some DACs take this into account by mapping input data into
non-fullscale internal representation.

This is also API break, since now 1.0 and -1.0 are not legal anymore.

headers

fons | 12 Dec 2009 14:27

Re: Fwd: Audio recording bitdepth

On Sat, Dec 12, 2009 at 01:52:15PM +0200, Jussi Laako wrote:

> Now it just becomes even more cumbersome to generate 0 dBFS signals with
> jack since the target output resolution is not known. Maybe I'll just
> begin to apply 0.5 dB safety margin in all generators and lack support
> for 0 dBFS...

The actual clipping level is -0.00013dB for 16 bit.
Maybe you could actually calculate the distortion for
a 0dB sine clipped at that level before jumping to
conclusions ?

> IMO, 1.0 and -1.0 should be legal.

They are.

Ciao,

--

-- 
FA

headers

Jussi Laako | 12 Dec 2009 15:58

Re: Fwd: Audio recording bitdepth

On 12/12/2009 03:27 PM, fons <at> kokkinizita.net wrote:
> The actual clipping level is -0.00013dB for 16 bit.
> Maybe you could actually calculate the distortion for
> a 0dB sine clipped at that level before jumping to
> conclusions ?

It is visible in the spectrum and is thus too much.

But yes, now I understand even more why ASIO is done the way it is,
since there at least I know what I get. I just better move to using pure
ALSA on Linux too. Apple's CoreAudio is anyway helpless, so I don't even
bother doing anything there.

Some people are using jack also for other purposes than recording and
playback of music.

headers

fons | 12 Dec 2009 17:02

Re: Fwd: Audio recording bitdepth

On Sat, Dec 12, 2009 at 04:58:52PM +0200, Jussi Laako wrote:

> On 12/12/2009 03:27 PM, fons <at> kokkinizita.net wrote:
> > The actual clipping level is -0.00013dB for 16 bit.
> > Maybe you could actually calculate the distortion for
> > a 0dB sine clipped at that level before jumping to
> > conclusions ?
> 

> It is visible in the spectrum and is thus too much.

I've been trying for hours to see it. Please show me !
Together with a spectrum of the same signal at -0.1dB
so we can compare them.

And I assume that you aware that dithering and/or noise
shaping also require a similar small margin. You have been
advocating the use of noise shaping. So what's the big
drama ? This margin is nothing new.

> Some people are using jack also for other purposes than recording and
> playback of music.

Yes, and I'm one of them. and probably the most 'technical'
user on this list.

Ciao,

--

-- 
FA

(Continue reading)

headers

Jussi Laako | 12 Dec 2009 17:30

Re: Fwd: Audio recording bitdepth

On 12/12/2009 06:02 PM, fons <at> kokkinizita.net wrote:
> And I assume that you aware that dithering and/or noise
> shaping also require a similar small margin. You have been
> advocating the use of noise shaping. So what's the big
> drama ? This margin is nothing new.

Clipping adds correlated error - harmonic distortion. Dithering adds
non-correlated noise to hide correlated error of the conversion
inaccuracy, having clipping _and_ the conversion error is different.
Noise shaping just deals with the conversion-related error, clipping
error is still additional error source.

No there's no big drama anywhere. There are just two aspects which
bothered me a bit:
1) For most ordinary audio hardware the difference of scaling factors is
not noticeable.
2) For the cases where the difference could be noticeable are mostly
32-bit input DACs where the single precision floating point itself is
too inaccurate to feed the DAC with full resolution data.
3) New factor adds distortion to the signal if application is trying to
generate 0 dBFS signal and application cannot pre-determine the maximum
value it should use to not clip...

headers

Jussi Laako | 12 Dec 2009 18:09

Re: Fwd: Audio recording bitdepth

On 12/12/2009 06:30 PM, Jussi Laako wrote:
> Clipping adds correlated error - harmonic distortion. Dithering adds

Which reminds me of one more problem which we should deal with.

These days there are various audio interfaces which have 18, 20 (or 22)
bit interface towards audio DAC. Having 24-bit samples truncated to
these word lengths adds significant amount of distortion.

This should be also taken into account. Having conversions only to 16 or
24 bits is not enough.

headers

Jussi Laako | 11 Dec 2009 22:58

Re: Fwd: Audio recording bitdepth

On 12/11/2009 10:30 PM, fons <at> kokkinizita.net wrote:
> You mean fig 20 in the data sheet ? That is noise *density*.

No, more like fig 22 and fig 23, -144 dBFS signal is still clearly visible.

> Again this must be a noise density in an unspecified BW,
> hence meaningless.

I would ask you to read the text in their white paper:
http://www.esstech.com/PDF/sabrewp.pdf

According to their docs, THD is the limiting factor in THD+N figures.

> This will produce a thermal noise of -126 dBV at room
> temperature.

Thermal noise is not flat spectrum. Noise density matters. Absolute
level doesn't matter. For analog parts, it's no too hard to reach 0.9
nV/sqrt(Hz) noise.

Just think how much gain there is already involved with low-output MC
phono cartridges. And still very good _subjective_ SNR is possible.

headers

fons | 11 Dec 2009 23:21

Re: Fwd: Audio recording bitdepth

On Fri, Dec 11, 2009 at 11:58:56PM +0200, Jussi Laako wrote:

> For analog parts, it's no too hard to reach 0.9
> nV/sqrt(Hz) noise.

Could be, but it won't help you with a source impedance
of 781 ohm such as the ES9008, as the source itself will
contribute 3.5nV/sqrt(Hz) or around 12 dB more.

Ciao,

--

-- 
FA

headers

Jussi Laako | 11 Dec 2009 23:56

Re: Fwd: Audio recording bitdepth

On 12/12/2009 12:21 AM, fons <at> kokkinizita.net wrote:
> Could be, but it won't help you with a source impedance
> of 781 ohm such as the ES9008, as the source itself will
> contribute 3.5nV/sqrt(Hz) or around 12 dB more.

I don't know about source impedance of ES9008 or especially ES9018 which
is the 32-bit part, since the only information I have is the web page
and the white paper. For ES9018 the web page states 135 dB DNR in mono
mode (two converters parallel).

One can easily connect several converters in parallel to improve the
figure, like Accuphase for example does in their converters.

In suitable conditions ear is pretty good on digging out disturbing
distortions out of the "absolute" noise background. Like low-level DAC
non-linearities.

headers

Jussi Laako | 10 Dec 2009 20:51

Re: Fwd: Audio recording bitdepth

On 12/10/2009 12:37 PM, fons <at> kokkinizita.net wrote:
> No need to panic about that. Jaaa's sine generator uses
> a 4096 point LUT with linear interpolation. The highest
> spurious I've ever seen is -144 dB below the sine level.

And on recent x86, FPU can do the calculations internally using 80 or
128 bit resolution and the result is just rounded in the end...

> Replacing this by just sinf() improves this to -150 dB,
> and using -ffast-math doesn't change that result.
> This is perfectly consistent with the precision of the
> float type - given that precision you can't do better.

Actually, you can if the used bandwidth is less than Nyquist.

headers

fons | 10 Dec 2009 22:07

Re: Fwd: Audio recording bitdepth

On Thu, Dec 10, 2009 at 09:51:07PM +0200, Jussi Laako wrote:

> > Replacing this by just sinf() improves this to -150 dB,
> > and using -ffast-math doesn't change that result.
> > This is perfectly consistent with the precision of the
> > float type - given that precision you can't do better.
> 
> Actually, you can if the used bandwidth is less than Nyquist.

We're probably talking about different things here. 
But you could try to explain.

Ciao,

--

-- 
FA

headers

Jussi Laako | 10 Dec 2009 08:24

Re: Fwd: Audio recording bitdepth

On 12/10/2009 04:50 AM, Paul Davis wrote:
> * Bjorn claims that when A/D converters clip around -.5 dBFS, that
> it's equivalent to (2^n)-.5, which is completely false.  This clipping
> happens entirely in the analog domain, before quantization to digital
> codes, so it is not equivalent to (2^n)-.5 because the converter is
> still based on 2^n.  What happens before the A/D conversion cannot be
> precisely equated to binary math.  These comments show a lack of
> understanding of the A/D process as well as mathematics.

This is a bit incorrect for any delta-sigma converter which are not
purely 2^n converters. Signals CAN actually clip also in the digital
domain inside the ADC converter chip. As well as actually also in DAC...

This because the converter is actually functioning in PDM or some kind
of mixed PCM-PDM mode and the modulation limits are more complicated
than just purely signal level.