Reply by robert bristow-johnson●April 27, 20152015-04-27
On 4/26/15 11:17 PM, Randy Yates wrote:
> robert bristow-johnson<rbj@audioimagination.com> writes:
>
>> On 4/26/15 8:01 PM, Tim Wescott wrote:
>>> On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote:
>>>
>>>> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill<lcargill99@comcast.com>
>>>> wrote:
>>>>
>>>>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
>>>>>
>>>>> I suspect he's describing a non-problem, or a problem in pretty extreme
>>>>> corner cases.
>>>>
>>>> Actually, no.
>>>>
>>>> I only skimmed the article, but it appears that Moorer is advocating not
>>>> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the
>>>> 48/56-bit internal architecture of the Motorola/Freescale/whatever
>>>> DSP56K.) That double-precision integer processing is superior to
>>>> single-precision floating point processing has been known for a very
>>>> long time. In fact, back in 1995 I proved it in an internal memo for my
>>>> employer at the time: I simulated the same set of filters, implemented
>>>> in both 32-bit float and 48/56-bit integer, and the integer
>>>> implementation performed better, particularly in terms of dynamic range.
>>>>
>>>> To be fair, the integer implementation was highly optimized while the
>>>> floating point implementation was unoptimized (i.e., without any regard
>>>> to such things as the order-of-operations problems that occur when
>>>> adding multiple floating point numbers of wide-ranging magnitudes). But
>>>> it did prove that making a switch to floating point, at least to
>>>> single-precision floating point, while allowing one to avoid overflow
>>>> and underflow problems, does not necessarily improve audio performance.
>>>
>>> Using floating point doesn't allow you to avoid overflow and underflow
>>> problems; it just masks them in hard-to-find ways.
>>>
>>> I warn about this in my controls book, and give some tools to figure out
>>> what's going on.
>>>
>>> For DSP, if precision matters then carefully crafted code with 32-bit
>>> integers is going to be better than anything you could do with 32-bit
>>> floating point. 48-bit integers would just make it betterer.
>>
>>
>> here's a little more of interest regarding the same author (Andy
>> Moorer). he was sorta the subject of this recent NPR All Things
>> Considered story 2 weeks ago:
>> http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code
>>
>>
>> i didn't know this until this story that Andy was the guy who created
>> that ubiquitous and annoying monster THX sound at the beginning of
>> movies.
>>
>> same guy.
>>
>> i think i did a better job (in 2008
>> http://www.aes.org/events/125/tutorials/session.cfm?code=T19 ) than
>> Andy regarding the float vs. fixed-point issue. i tried comparing
>> apples to apples, where the word size was the same for float and
>> fixed. comparing 32-bit IEEE-748 float (with 8 exponent bits) to
>> 32-bit fixed, you would have to require a 40 dB headroom (or more) in
>> order for floating-point samples to have better S/N ratio than with
>> fixed. i have seen a special in-house implementation of floating
>> point (non-IEEE) with 5 exponent bits and that seems about optimum for
>> audio. otherwise fixed point is better given limited bits in the word
>> width, as long as you're willing to pay a little attention to where
>> the rails are.
>
> Robert,
>
> Was there a preprint or other document associated with that tutorial?
hi Randy,
if your address is correct (i check with previous email), i can send you
the powerpoint, including the soundfiles that went with it. expect a
big turd in your Inbox.
i think i might have it all zipped up somewhere.
and likewise for anyone else interested. just lemme know.
--
r b-j rbj@audioimagination.com
"Imagination is more important than knowledge."
Reply by Randy Yates●April 27, 20152015-04-27
robert bristow-johnson <rbj@audioimagination.com> writes:
> On 4/26/15 8:01 PM, Tim Wescott wrote:
>> On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote:
>>
>>> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill<lcargill99@comcast.com>
>>> wrote:
>>>
>>>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
>>>>
>>>> I suspect he's describing a non-problem, or a problem in pretty extreme
>>>> corner cases.
>>>
>>> Actually, no.
>>>
>>> I only skimmed the article, but it appears that Moorer is advocating not
>>> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the
>>> 48/56-bit internal architecture of the Motorola/Freescale/whatever
>>> DSP56K.) That double-precision integer processing is superior to
>>> single-precision floating point processing has been known for a very
>>> long time. In fact, back in 1995 I proved it in an internal memo for my
>>> employer at the time: I simulated the same set of filters, implemented
>>> in both 32-bit float and 48/56-bit integer, and the integer
>>> implementation performed better, particularly in terms of dynamic range.
>>>
>>> To be fair, the integer implementation was highly optimized while the
>>> floating point implementation was unoptimized (i.e., without any regard
>>> to such things as the order-of-operations problems that occur when
>>> adding multiple floating point numbers of wide-ranging magnitudes). But
>>> it did prove that making a switch to floating point, at least to
>>> single-precision floating point, while allowing one to avoid overflow
>>> and underflow problems, does not necessarily improve audio performance.
>>
>> Using floating point doesn't allow you to avoid overflow and underflow
>> problems; it just masks them in hard-to-find ways.
>>
>> I warn about this in my controls book, and give some tools to figure out
>> what's going on.
>>
>> For DSP, if precision matters then carefully crafted code with 32-bit
>> integers is going to be better than anything you could do with 32-bit
>> floating point. 48-bit integers would just make it betterer.
>
>
> here's a little more of interest regarding the same author (Andy
> Moorer). he was sorta the subject of this recent NPR All Things
> Considered story 2 weeks ago:
> http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code
>
>
> i didn't know this until this story that Andy was the guy who created
> that ubiquitous and annoying monster THX sound at the beginning of
> movies.
>
> same guy.
>
> i think i did a better job (in 2008
> http://www.aes.org/events/125/tutorials/session.cfm?code=T19 ) than
> Andy regarding the float vs. fixed-point issue. i tried comparing
> apples to apples, where the word size was the same for float and
> fixed. comparing 32-bit IEEE-748 float (with 8 exponent bits) to
> 32-bit fixed, you would have to require a 40 dB headroom (or more) in
> order for floating-point samples to have better S/N ratio than with
> fixed. i have seen a special in-house implementation of floating
> point (non-IEEE) with 5 exponent bits and that seems about optimum for
> audio. otherwise fixed point is better given limited bits in the word
> width, as long as you're willing to pay a little attention to where
> the rails are.
Robert,
Was there a preprint or other document associated with that tutorial?
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com
Reply by robert bristow-johnson●April 26, 20152015-04-26
On 4/26/15 8:01 PM, Tim Wescott wrote:
> On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote:
>
>> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill<lcargill99@comcast.com>
>> wrote:
>>
>>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
>>>
>>> I suspect he's describing a non-problem, or a problem in pretty extreme
>>> corner cases.
>>
>> Actually, no.
>>
>> I only skimmed the article, but it appears that Moorer is advocating not
>> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the
>> 48/56-bit internal architecture of the Motorola/Freescale/whatever
>> DSP56K.) That double-precision integer processing is superior to
>> single-precision floating point processing has been known for a very
>> long time. In fact, back in 1995 I proved it in an internal memo for my
>> employer at the time: I simulated the same set of filters, implemented
>> in both 32-bit float and 48/56-bit integer, and the integer
>> implementation performed better, particularly in terms of dynamic range.
>>
>> To be fair, the integer implementation was highly optimized while the
>> floating point implementation was unoptimized (i.e., without any regard
>> to such things as the order-of-operations problems that occur when
>> adding multiple floating point numbers of wide-ranging magnitudes). But
>> it did prove that making a switch to floating point, at least to
>> single-precision floating point, while allowing one to avoid overflow
>> and underflow problems, does not necessarily improve audio performance.
>
> Using floating point doesn't allow you to avoid overflow and underflow
> problems; it just masks them in hard-to-find ways.
>
> I warn about this in my controls book, and give some tools to figure out
> what's going on.
>
> For DSP, if precision matters then carefully crafted code with 32-bit
> integers is going to be better than anything you could do with 32-bit
> floating point. 48-bit integers would just make it betterer.
here's a little more of interest regarding the same author (Andy
Moorer). he was sorta the subject of this recent NPR All Things
Considered story 2 weeks ago:
http://www.npr.org/2015/04/11/399034279/know-that-thx-sound-before-movies-thats-actually-20-000-lines-of-code
i didn't know this until this story that Andy was the guy who created
that ubiquitous and annoying monster THX sound at the beginning of movies.
same guy.
i think i did a better job (in 2008
http://www.aes.org/events/125/tutorials/session.cfm?code=T19 ) than Andy
regarding the float vs. fixed-point issue. i tried comparing apples to
apples, where the word size was the same for float and fixed. comparing
32-bit IEEE-748 float (with 8 exponent bits) to 32-bit fixed, you would
have to require a 40 dB headroom (or more) in order for floating-point
samples to have better S/N ratio than with fixed. i have seen a special
in-house implementation of floating point (non-IEEE) with 5 exponent
bits and that seems about optimum for audio. otherwise fixed point is
better given limited bits in the word width, as long as you're willing
to pay a little attention to where the rails are.
--
r b-j rbj@audioimagination.com
"Imagination is more important than knowledge."
Reply by Tim Wescott●April 26, 20152015-04-26
On Sun, 26 Apr 2015 08:36:28 -0500, Greg Berchin wrote:
> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill <lcargill99@comcast.com>
> wrote:
>
>>http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
>>
>>I suspect he's describing a non-problem, or a problem in pretty extreme
>>corner cases.
>
> Actually, no.
>
> I only skimmed the article, but it appears that Moorer is advocating not
> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the
> 48/56-bit internal architecture of the Motorola/Freescale/whatever
> DSP56K.) That double-precision integer processing is superior to
> single-precision floating point processing has been known for a very
> long time. In fact, back in 1995 I proved it in an internal memo for my
> employer at the time: I simulated the same set of filters, implemented
> in both 32-bit float and 48/56-bit integer, and the integer
> implementation performed better, particularly in terms of dynamic range.
>
> To be fair, the integer implementation was highly optimized while the
> floating point implementation was unoptimized (i.e., without any regard
> to such things as the order-of-operations problems that occur when
> adding multiple floating point numbers of wide-ranging magnitudes). But
> it did prove that making a switch to floating point, at least to
> single-precision floating point, while allowing one to avoid overflow
> and underflow problems, does not necessarily improve audio performance.
Using floating point doesn't allow you to avoid overflow and underflow
problems; it just masks them in hard-to-find ways.
I warn about this in my controls book, and give some tools to figure out
what's going on.
For DSP, if precision matters then carefully crafted code with 32-bit
integers is going to be better than anything you could do with 32-bit
floating point. 48-bit integers would just make it betterer.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply by Les Cargill●April 26, 20152015-04-26
Greg Berchin wrote:
> On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill <lcargill99@comcast.com>
> wrote:
>
>> http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
>>
>> I suspect he's describing a non-problem, or a problem in pretty
>> extreme corner cases.
>
> Actually, no.
>
> I only skimmed the article, but it appears that Moorer is advocating not
> 48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the
> 48/56-bit internal architecture of the Motorola/Freescale/whatever
> DSP56K.) That double-precision integer processing is superior to
> single-precision floating point processing has been known for a very
> long time. In fact, back in 1995 I proved it in an internal memo for my
> employer at the time: I simulated the same set of filters, implemented
> in both 32-bit float and 48/56-bit integer, and the integer
> implementation performed better, particularly in terms of dynamic range.
>
> To be fair, the integer implementation was highly optimized while the
> floating point implementation was unoptimized (i.e., without any regard
> to such things as the order-of-operations problems that occur when
> adding multiple floating point numbers of wide-ranging magnitudes). But
> it did prove that making a switch to floating point, at least to
> single-precision floating point, while allowing one to avoid overflow
> and underflow problems, does not necessarily improve audio performance.
>
I got this off Facebook, and somebody came up with exactly
the same explanation as you did - it's about the DPS56K.
Turns out the paper is 20 years old.
Thanks!
--
Les Cargill
Reply by Greg Berchin●April 26, 20152015-04-26
On Sat, 25 Apr 2015 16:26:14 -0500, Les Cargill <lcargill99@comcast.com>
wrote:
Actually, no.
I only skimmed the article, but it appears that Moorer is advocating not
48-bit audio *samples*, but 48-bit audio *processing* (e.g.; the
48/56-bit internal architecture of the Motorola/Freescale/whatever
DSP56K.) That double-precision integer processing is superior to
single-precision floating point processing has been known for a very
long time. In fact, back in 1995 I proved it in an internal memo for my
employer at the time: I simulated the same set of filters, implemented
in both 32-bit float and 48/56-bit integer, and the integer
implementation performed better, particularly in terms of dynamic range.
To be fair, the integer implementation was highly optimized while the
floating point implementation was unoptimized (i.e., without any regard
to such things as the order-of-operations problems that occur when
adding multiple floating point numbers of wide-ranging magnitudes). But
it did prove that making a switch to floating point, at least to
single-precision floating point, while allowing one to avoid overflow
and underflow problems, does not necessarily improve audio performance.
Reply by Les Cargill●April 25, 20152015-04-25
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
I suspect he's describing a non-problem, or a problem in pretty
extreme corner cases.
--
Les Cargill