21 Jul
2007
21 Jul
'07
8:44 a.m.
Hi, All!
Say, we have such audio-chain:
1. analogue source (say, mic-amp),
2. sound card's line input (let sound card be rme hdsp9632),
3. JackRack (or some other JACKified LADSPA host) with the only LADSPA plugin,
let last one be a simple aplifier,
4.1. sound card SPDIF output.
4.2. sound card analogue output,
OK, ALSA-driver, HdspMixer, JACK-server and something else are somewhere
inside this "user' POV" list.
The questions are:
- what is full strict list of "audio-entities" steps in such roughly-presented
chain?
- which formats (float/integer, bitdepth) are used on each step?
- which format convertions between steps may be treated as lossless and whcih as
"lossness"?
And more generally: are there common rules for keeping sound quality intact? I mean
only format-related probable issues rather hardware issues like jitter and such.
Andrew
21 Jul
21 Jul
9:58 a.m.
Hi,
Am Samstag, 21. Juli 2007 schrieb Andrew Gaydenko:
The questions are:
- what is full strict list of "audio-entities" steps in such
roughly-presented chain? - which formats (float/integer, bitdepth) are used
on each step?
1. analogue source (say, mic-amp),
This one doesn't use either double nor float :-) But you want to keep this
part of the chain as high-quality or at least as short as possible.
2. sound card's line input (let sound card be rme
hdsp9632),
Even if the drivers would expose it as doubles, it is still quantified which
is best represented as integers. Most (all?) drivers present the soundcard io
as integers.
3. JackRack (or some other JACKified LADSPA host) with
the only LADSPA
plugin, let last one be a simple aplifier,
With jack the internal processing is done in floating point numbers. This
leaves some quantification-steps but these are _much_ smaller than any
soundcard can reproduce and only affect you when you do some very serious
amplification or something like that...
4.1. sound card SPDIF output.
4.2. sound card analogue output,
This is integer again with fixed bit-depth. Again you will want to keep the
path from your soundcard to the speakers as short and high-quality as
possible.
- which format convertions between steps may be
treated as lossless and
whcih as "lossness"?
The AD/DA-steps are lossy. Depending on the quality of the converters and the
used samplingrate and bitdepth it is sometimes more lossy and sometimes less.
And there is always the question of improvements being better than the human
ear can hear (see the ongoing discussions about 48/96/192).
And more generally: are there common rules for keeping
sound quality
intact?
Use integer calculations as few as possible (unless you know exactly what you
are doing).
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
10:56 a.m.
On Sat, 2007-07-21 at 14:42 +0400, Andrew Gaydenko wrote:
Hi, All!
Say, we have such audio-chain:
1. analogue source (say, mic-amp),
Adds noise.
2. sound card's line input (let sound card be rme
hdsp9632),
Soundcard must dither correctly (This sorts the linearity of the
quantisation process), and means that the bit depth ONLY changes the
noise floor, you can still detect signals down to below 1 LSB).
Output is (In your case),24 bit samples packed into 32 bit words.
Typically you actually get somewhere around 19 bits with the lowest few
being swamped by thermal noise.
3. JackRack (or some other JACKified LADSPA host) with
the only LADSPA plugin,
let last one be a simple aplifier,
All the Jack stuff converts to 32 bit floats, which provides for a 24
bit mantissa (Convenient that!).
4.1. sound card SPDIF output.
4.2. sound card analogue output,
Jack converts back to soundcard native format (24 bit integer in 32 bit
word IIRC for the HDSP), full sale is considered to be +-1.0 on the
float side of the equation. For 16 bit cards, dither is optionally added
to this conversion to linearise it. This is not considered necessary at
24 bit as the error is buried in the system noise for all practical
systems anyway.
OK, ALSA-driver, HdspMixer, JACK-server and something
else are somewhere
inside this "user' POV" list.
Hdspmixer deals with DSP on the card, who knows what it does to the
audio exactly? But it is probably done right.
Alsa driver just passes along the DMA buffers from the card.
Jack converts the integer sample values to floating point (Effectively
lossless), and scales to +- 1.0 full scale (not saying that signals
within the jack graph cannot exceed +-1.0, but that if they do at the
output they will clip.
And more generally: are there common rules for keeping
sound quality intact? I mean
only format-related probable issues rather hardware issues like jitter and such.
Be very careful how you write float->int conversions (it is not
trivial), and work in floating point as far as is possible, there is
little reason (other then marketing) to move to doubles (IIR filters
possibly excepted).
When writing plugins, watch out for possible aliasing.
With that card you do NOT need to be peaking at -1dbFS, you have plenty
of dynamic range, so line up for your nominal zero level to be somewhere
around -16 or so, you will loose far less takes to digital overs, and
generally sweat less.
Regards, Dan.
22 Jul
22 Jul
6:44 a.m.
On 21 Jul 2007, at 13:56, Dan Mills wrote:
Well, I'd qualify that as there's no need to use doubles between
modules, there are many DSP processes that work better in double if
you can afford the extra memory bandwidth. Filters are one.
It's generally not doubles in the audio path though, but its things
that you're using to modify it, coefficients, phase accumulators and
so on.
- Steve
And more generally: are there common rules for
keeping sound
quality intact? I mean
only format-related probable issues rather hardware issues like
jitter and such.
Be very careful how you write float->int conversions (it is not
trivial), and work in floating point as far as is possible, there is
little reason (other then marketing) to move to doubles (IIR filters
possibly excepted).
7:48 a.m.
On Sun, 2007-07-22 at 09:45 +0100, Steve Harris wrote:
On 21 Jul 2007, at 13:56, Dan Mills wrote:
Granted.
Be very careful how you write float->int
conversions (it is not
trivial), and work in floating point as far as is possible, there is
little reason (other then marketing) to move to doubles (IIR filters
possibly excepted).
Well, I'd qualify that as there's no need to use doubles between
modules, there are many DSP processes that work better in double if
you can afford the extra memory bandwidth. Filters are one. It's generally not doubles in the audio path
though, but its things
that you're using to modify it, coefficients, phase accumulators and
so on.
I was thinking mainly about some commercial DAWs that boast of stupid
word length accumulators for mix buses and the like. I never did
understand that.
Regards, Dan.
3:29 p.m.
On Sun, 2007-07-22 at 10:48 +0100, Dan Mills wrote:
On Sun, 2007-07-22 at 09:45 +0100, Steve Harris
wrote:
1) the ones that do are using fixed point math, not floating point
2) there are some good theoretical arguments for needing more than 32bit
floating point resolution for a mixer
--p
On 21 Jul 2007, at 13:56, Dan Mills wrote:
Granted.
Be very careful how you write float->int
conversions (it is not
trivial), and work in floating point as far as is possible, there is
little reason (other then marketing) to move to doubles (IIR filters
possibly excepted).
Well, I'd qualify that as there's no need to use doubles between
modules, there are many DSP processes that work better in double if
you can afford the extra memory bandwidth. Filters are one. It's generally not doubles in the audio path
though, but its things
that you're using to modify it, coefficients, phase accumulators and
so on.
I was thinking mainly about some commercial DAWs that boast of stupid
word length accumulators for mix buses and the like. I never did
understand that. 
8:08 p.m.
On Sun, Jul 22, 2007 at 01:29:19PM -0400, Paul Davis wrote:
2) there are some good theoretical arguments for
needing more than 32bit
floating point resolution for a mixer
Would you have some pointers to papers that discuss this matter in
a scientific way ? I've seen enough reports describing the difference
between floats and doubles in the same subjective terms used to sell
speaker cables made of unobtainium and hand-woven by Yorkshire virgins,
or equipment to revive old and tired electrons, but never anything that
could be taken seriously.
--
FA
Follie! Follie! Delirio vano è questo !
8:54 p.m.
======= On Monday 23 July 2007, Fons Adriaensen wrote: =======
On Sun, Jul 22, 2007 at 01:29:19PM -0400, Paul Davis
wrote:
Hi, Fons!
RME have decided to use on different operations much more bps rather
we (I mean, say, JACK server users) use. Have you a minute to comment?
http://www.rme-audio.com/english/techinfo/hdsp_tmhard.htm
Andrew
2) there are some good theoretical arguments for
needing more than 32bit
floating point resolution for a mixer
Would you have some pointers to papers that discuss this matter in
a scientific way ? I've seen enough reports describing the difference
between floats and doubles in the same subjective terms used to sell
speaker cables made of unobtainium and hand-woven by Yorkshire virgins,
or equipment to revive old and tired electrons, but never anything that
could be taken seriously.
23 Jul
23 Jul
8 a.m.
On Mon, Jul 23, 2007 at 02:52:04AM +0400, Andrew Gaydenko wrote:
RME have decided to use on different operations much
more bps rather
we (I mean, say, JACK server users) use. Have you a minute to comment?
http://www.rme-audio.com/english/techinfo/hdsp_tmhard.htm
This all HW and fixed-point, and a very particular situation.
The mixer described here would be used typically for setting up
a number of monitor mixes. Some signals could end up at a low
level in a full mix, and at full level in a channel used to
monitor just one instrument. It would be perfectly possible
to arrange this without any additional internal headroom, but
that would require a lot of attention from the user.
Having intermediate signals at higher fixed point resolution
means that you have more room to e.g. compensate for too high
gain on all input channels by reducing group gain, etc.
So two points seem to be important:
- this is all about usability, not quality,
- it would not be required when using floating point.
Ciao,
--
FA
Follie! Follie! Delirio vano è questo !
10:09 a.m.
On Sun, Jul 22, 2007 at 01:29:19PM -0400, Paul Davis wrote:
2) there are some good theoretical arguments for
needing more than 32bit
floating point resolution for a mixer
I did a quick experiment.
N floating point signals, all of them Gaussian distributed, summed
both as single and double precision. If the difference between the
two sums is considered 'noise', the signal/noise ratios R in dB are:
N R
----------------
16 -142.9
32 -140.0
64 -136.7
128 -133.8
256 -130.7
512 -128.0
1024 -124.7
2048 -121.9
4096 -118.8
So even when summing 1024 signals the result is better than
120 dB, and an already big mixing session with 64 sources
would produce 136 dB. This should be compared to the S/N
ratio of individual sources which is unlikely to be better
than 90 or 100 dB.
The only case where things would turn out to be worse is
when you are mixing signals that cancel systematically and
the resulting low level sum is amplified. If that happens
you will have other and much more serious problems anyway.
And it's quite easy to improve these figures even when using
just single precision. For example if the summing is done in
two steps, first making sums of 4 inputs and then adding these,
the results for large N improves by 6 dB:
N R
----------------
16 -146.2
32 -144.2
64 -141.8
128 -139.3
256 -136.6
512 -133.6
1024 -130.7
2048 -127.8
4096 -124.9
Or 12 dB using a first grouping of 16:
N R
----------------
16 -142.3
32 -141.8
64 -141.3
128 -140.4
256 -139.3
512 -137.5
1024 -135.7
2048 -133.2
4096 -130.6
Or two intermediate levels of 4:
N R
----------------
16 -144.8
32 -143.9
64 -143.1
128 -141.8
256 -140.4
512 -138.3
1024 -135.9
2048 -133.6
4096 -130.5
Taking this to the limit, a binary tree addition would produce the
best results. This also explains why even single-precision FFTs
produce good results when used for convolution - an FFT computes
sums over all its input samples, but the addition is organised as
a tree by the very nature of the algorithm.
--
FA
Follie! Follie! Delirio vano è questo !
2:16 p.m.
On Mon, 2007-07-23 at 14:16 +0200, Fons Adriaensen wrote:
On Sun, Jul 22, 2007 at 01:29:19PM -0400, Paul Davis
wrote:
Even for this (most simplistic) summing example, an error or noise floor
at -118.8 dB would still be like comparing the sound of a deafening
jet-engine close up, to that of some rustling leaves in the background
(which may or may not be missing in your soundscape ...) Hardly
noticeable.
I also wonder ... Suppose channels 1 - 4095 were an orchestra of
assorted, close miked vacuum cleaners and hair dryers, and channel 4096
was a sole bagpiper. Would you then be able to figure out wether he is
playing Auld Lang Syne or not?
:)
I would suspect the bagpipe to be lost. With that [4096] amount of
channels, we are approaching something compareable to that of a football
choir at a stadium, were one individual has no impact whatsoever on the
resulting sound.
2) there are some good theoretical arguments for
needing more than 32bit
floating point resolution for a mixer
I did a quick experiment.
N floating point signals, all of them Gaussian distributed, summed
both as single and double precision. If the difference between the
two sums is considered 'noise', the signal/noise ratios R in dB are:
N R
----------------
16 -142.9
32 -140.0
64 -136.7
128 -133.8
256 -130.7
512 -128.0
1024 -124.7
2048 -121.9
4096 -118.8
2:39 p.m.
On Mon, Jul 23, 2007 at 06:16:31PM +0200, Jens M Andreasen wrote:
I also wonder ... Suppose channels 1 - 4095 were an
orchestra of
assorted, close miked vacuum cleaners and hair dryers, and channel 4096
was a sole bagpiper. Would you then be able to figure out wether he is
playing Auld Lang Syne or not?
:)
Assuming the bagpipe makes as much noise as vacuum cleaner, it would
be at -36 dB below the assorted noise sources.
But you probably would if the vacuum cleaners are in stereo and the
bagpipe is panned in the middle (provided you know Auld Lang Syne :-).
--
FA
Follie! Follie! Delirio vano è questo !
2:53 p.m.
Am Montag, 23. Juli 2007 schrieb Fons Adriaensen:
On Mon, Jul 23, 2007 at 06:16:31PM +0200, Jens M
Andreasen wrote:
I would probably break out my toolset to repair my vacuum cleaner because it
has some slight funny noise with it:-)
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
I also wonder ... Suppose channels 1 - 4095 were
an orchestra of
assorted, close miked vacuum cleaners and hair dryers, and channel 4096
was a sole bagpiper. Would you then be able to figure out wether he is
playing Auld Lang Syne or not?
Assuming the bagpipe makes as much noise as vacuum
cleaner, it would
be at -36 dB below the assorted noise sources.
But you probably would if the vacuum cleaners are in stereo and the
bagpipe is panned in the middle (provided you know Auld Lang Syne :-).
8:37 p.m.
On Mon, Jul 23, 2007 at 06:53:28PM +0200, Arnold Krille wrote:
I would probably break out my toolset to repair my
vacuum cleaner because it
has some slight funny noise with it:-)
I'm quite sure you don't want to repair 4095 vacuum cleaners :-)
Ciao,
--
FA
Follie! Follie! Delirio vano è questo !
6131
days inactive
6133
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
7 participants
participants (7)
-
Andrew Gaydenko -
Arnold Krille -
Dan Mills -
Fons Adriaensen -
Jens M Andreasen -
Paul Davis -
Steve Harris