Re: [Jack-Devel] S24_3LE

Ok thanks. I think I should have said dynamic range when I said resolution.
I was definitely not talking about frequency resolution but the number of
values you have to represent a range like -1 to 1.

Anyway my example should be illustrative of the differencen between n-point
fixed and n-point float. If one tone max out the range, there are no
decimal points left to represent an added low-level tone. For instance, you
could add a tone with amp 1.234*10^3 to another with amp 3.000*10^0. A
fixed-point presentation could use the exponent bits to represent the
low-level tone slightly better. No?

I agree that 24 bit ints are fully contained in 32 bit floats, and my
preference here is cosmetic, I admit, to speak the language of my audio
interface : ).

br, Anders

Ps I'm very familiar with nyquist... low-level audio implementation, not as
much...
Den 11/08/2013 21.36 skrev "Paul Davis" <[hidden]>:

> my answer probably wasn't clear.
>
> the ability to correctly sample different frequencies is dependent only on
> sample rate.
>
> dynamic range depends on bit depth, but floating point sample formats have:
>
>    (a) the same dynamic range as signed 24 bit integer with ZERO losss of
> precision
>    (b) essentially infinite dynamic range if you are willing to live with
> some loss of precision
>
> so you don't ever gain by switching from float to 24 bit integer. you
> don't gain switching the other way, except:
>
>    * dedicated FP h/w (e.g. SSE) purposely designed to parallelize
> floating point operations
>    * if the sum of your signals exceeds 0dBFS, you don't clip in floating
> point format
>
> these are fairly significant benefits
>
>
>
>
> On Sun, Aug 11, 2013 at 3:23 PM, Paul Davis <[hidden]>wrote:
>
>> resolution has nothing to do with bit depth, only with sample rate. basic
>> signal processing theory, nyquist, etc.
>>
>>
>> On Sun, Aug 11, 2013 at 3:12 PM, Anders Tornvig <[hidden]>wrote:
>>
>>> Hi Paul, thanks for your rapid answer!
>>>
>>> Ok I see. Float if I want the jack api.
>>>
>>> The wordlengths we operate with today may make the discussion less
>>> relevant, but I don't understand the benefit of adding resolution to
>>> something which was not converted correspondingly.
>>>
>>> Say you have a low- and a high-frequency tone added together. Say the lf
>>> tone amplitude is 1000 times that of the hf tone. I happen to be only
>>> interested in the low-amplitude hf tone but the lf tone "steals" the
>>> resolution to represent it. And that resolution changes with the level of
>>> the lf tone! Am I right?
>>>
>>> With integers I know what resolution I have, no more, no less.
>>>
>>> Best, Anders
>>> Den 11/08/2013 16.03 skrev "Paul Davis" <[hidden]>:
>>>
>>>
>>>>
>>>>
>>>> On Sun, Aug 11, 2013 at 7:11 AM, Anders Tornvig <
>>>> [hidden]> wrote:
>>>>
>>>>> Dear list,
>>>>>
>>>>> I'm writing a full-duplex program (2in/2out) which will output
>>>>> something, record it as a block of data (1024-3268 samples), analyze it and
>>>>> decide what to output next. I'm on Ubuntu, at the moment with a UA-25ex USB
>>>>> audio interface, speaking S24_3LE.
>>>>>
>>>>> The Jack API looks fantastic except for one thing: I prefer working
>>>>> with integers and not float. In ALSA I can set the sample format to
>>>>> SND_PCM_FORMAT_S24_3LE and then I can give it data in that format directly,
>>>>> 3 bytes per sample per channel. On the capture side, I receive nice 24-bit
>>>>> integers.
>>>>>
>>>>
>>>> You should know that almost all audio software on almost every platform
>>>> these days using floating point. Even platforms that used to use fixed
>>>> point (e.g. protools DSP boxes) now use floating point.
>>>>
>>>> Adding a new data type to JACK is not particularly hard if it is
>>>> intended only for client-to-client communication. Adding a new data type to
>>>> JACK that involves the backends is a major undertaking.
>>>>
>>>>  You really should try to get over your attachment to integers - they
>>>> are fundamentally inappropriate for working with audio, something it has
>>>> taken the industry 10-20 years to realize but is now accepted by almost
>>>> everyone.
>>>>
>>>> --p
>>>>
>>>>
>>>>
>>
>

1376252572.13005_0.ltw:2,a <CAMeZe4Hruey_=p2nuieVH+74MvfntXC=svQ+=fzj2JbfAq65LA at mail dot gmail dot com>