adstatus and sample size: where?


    Dec 21 2006 | 6:20 pm
    Hello,
    In adstatus, I don't find any argument to report and control the
    sample size (16bit, 24bit) of Mac OS X "Built-in Audio".
    Is it well-hidden or do I have to set it manually in Audio Setup?
    Philippe

    • Dec 28 2006 | 1:01 am
      If nobody knows, I guess I have to set it up directly in Audio Setup, correct?
    • Dec 28 2006 | 8:26 am
      Open the Audio Status patch and copy and paste what you need from it.
      :-)
      Trond
      Philippe Gruchet wrote:
      > If nobody knows, I guess I have to set it up directly in Audio Setup, correct?
    • Dec 28 2006 | 11:25 pm
      Trond Lossius wrote on Thu, 28 December 2006 09:26
      ----------------------------------------------------
      > Open the Audio Status patch and copy and paste what you need from
      > it.
      > :-)
      I'd like to! ;-)
      There's nothing in DSP Status to directly setting up the sample size of Built-in Audio.
      "Sampling Rate" works fine: any change from Max is automatically displayed in Apple's "Audio Setup". (1 second later, or 2)
      There's nothing to perform a same task for the sample (or sampling) size: 2ca-16bit 2ca-24bit.
      And I really need that when testing some patchers.
      Feature request?
      Best wishes,
      Philippe
    • Dec 29 2006 | 2:46 am
      > "Sampling Rate" works fine: any change from Max is automatically displayed in Apple's "Audio Setup". (1 second later, or 2)
      > There's nothing to perform a same task for the sample (or sampling) size: 2ca-16bit 2ca-24bit.
      > And I really need that when testing some patchers.
      >
      > Feature request?
      >
      > Best wishes,
      > Philippe
      excuse me if am ignorant or wrong, but in most cases
      24-bit interfaces do not allow to operate in 16 bit mode.
      if the chosen hardware driver dos not allow this, you can
      set it up like this in an app like max.
      -110
    • Dec 29 2006 | 3:30 am
      Roman,
      > excuse me if am ignorant or wrong, but in most cases
      > 24-bit interfaces do not allow to operate in 16 bit mode.
      Depends.
      Ditto for the sampling rate.
      And the sampling rate can be reported in [adstatus sr], not the sampling size.
      "Built-in Audio" allows 32, 44.1 and 48 kHz, 16 or 24 bit for these three sampling rates.
      If you're on Mac, let's see by yourself in Apple's "Audio MIDI Setup", based on a Texas Instruments soundcard.
      > if the chosen hardware driver does not allow this, you can
      > set it up like this in an app like max.
      You probably meant 'you can't'.
      Even if we can't change the sample size, adstatus could report the current value.
      With Built-in Audio, adstatus could also control the current value.
      I'm asking for this feature because when doing some FFT processing, 48kHz/24bit runs faster than 44.1kHz/16bit.
      Around 15-20% faster.
      Regards,
      Philippe
    • Dec 29 2006 | 7:27 am
      MSP is using float representation internally, so any 16bit/24bit
      differences would only make a difference when converting back and forth
      between digital and analog signals in adc~, dac~, etc. AFAIK 32 bit
      floating point representation on both OSX and XP use 24 bits for the
      mantissa.
      My guess would be that if the sound card supports 24 bits, MSP will use
      that. To emulate the sound of a 16 bit card you could use degrade~ after
      adc~ and before dac~, but I would be very surprised if you managed to
      see this having an effect on the CPU usage of FFT. If you have
      experienced differences with FFT CPU load in other applications I
      suspect that it is more a question of what the overload is when
      converting to/from required floating point representation before and
      after the FFT calculation. Maybe this is the case in ProTools, it used
      to do processing on int instead of float. I don't know if that has
      changed in the later years.
      Best,
      Trond
      Philippe Gruchet wrote:
      >> excuse me if am ignorant or wrong, but in most cases
      >> 24-bit interfaces do not allow to operate in 16 bit mode.
      >>
      >
      > Depends.
      > Ditto for the sampling rate.
      > And the sampling rate can be reported in [adstatus sr], not the sampling size.
      > "Built-in Audio" allows 32, 44.1 and 48 kHz, 16 or 24 bit for these three sampling rates.
      > If you're on Mac, let's see by yourself in Apple's "Audio MIDI Setup", based on a Texas Instruments soundcard.
      >
      >> if the chosen hardware driver does not allow this, you can
      >> set it up like this in an app like max.
      >>
      >
      > You probably meant 'you can't'.
      > Even if we can't change the sample size, adstatus could report the current value.
      > With Built-in Audio, adstatus could also control the current value.
      >
      > I'm asking for this feature because when doing some FFT processing, 48kHz/24bit runs faster than 44.1kHz/16bit.
      > Around 15-20% faster.
      >
      > Regards,
      > Philippe
    • Dec 29 2006 | 10:59 am
      Quote: Trond Lossius wrote on Fri, 29 December 2006 08:27
      ----------------------------------------------------
      > My guess would be that if the sound card supports 24 bits, MSP
      > will use that.
      Yes, it does.
      About the CPU load, it seems to stay at 7%, 16 or 24 bit.
      When playing a guitar pitch-shifted in gizmo~ , I clearly hear a lower latency at 48kHz-24bit than at 16bit: around -10%.
      I just used the "latency-test.pat" and it confirmed what I heard.
      So, I looked for this setting in [adstatus]...
      Best,
      Philippe
    • Dec 30 2006 | 5:56 pm
      Philippe Gruchet wrote:
      > I'm asking for this feature because when doing some FFT processing,
      > 48kHz/24bit runs faster than 44.1kHz/16bit. Around 15-20% faster.
      Max is always using 32-bit floating point. I don't know from where your
      figures come from... Must be an illusion... Or maybe a programm which
      converts after processing and that accounts for the additional time...
      Philippe Gruchet wrote:
      > Yes, it does. About the CPU load, it seems to stay at 7%, 16 or 24
      > bit. When playing a guitar pitch-shifted in gizmo~ , I clearly hear a
      > lower latency at 48kHz-24bit than at 16bit: around -10%. I just used
      > the "latency-test.pat" and it confirmed what I heard.
      This is exactly the difference in the sample rate between 44.1 and 48
      kHz... The CPU should be higher though...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Dec 30 2006 | 11:25 pm
      Hi Stefan!
      ----------------------------------------------------
      > This is exactly the difference in the sample rate between 44.1
      > and 48kHz...
      Yes!
      I just tracked the latency through gizmo~ and "Built-in Audio":
      4092 samples = 85.25 ms at 48 khz/24 bits
      4092 samples = 92.79 ms at 44.1 khz/24 bits
      4092 samples = 127.875 ms at 32 khz/24 bits
      At 16 bits, I got a higher latency, around +10%.
      > The CPU should be higher though...
      Ah, probably. I'll check again with new tests.
      Could I get better results at 96 khz with a good audio interface?
      Thanks for your insight!
      Regards,
      Philippe
    • Dec 31 2006 | 12:13 am
    • Dec 31 2006 | 10:02 am
    • Dec 31 2006 | 3:43 pm
    • Dec 31 2006 | 4:57 pm
    • Dec 31 2006 | 5:29 pm
    • Jan 01 2007 | 8:58 pm
      Philippe Gruchet wrote:
      > At 16 bits, I got a higher latency, around +10%.
      How do you switch gizmo~ from 24-bit to 16-bit? I'd try it in 32-bit
      should be faster then... ;-)
      If your interface (which?) does add latency, keep it in its highest
      resolution always, just don't bother with anything else... (never!)
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Jan 02 2007 | 12:16 am
      Quote: Stefan Tiedje wrote on Mon, 01 January 2007 21:58
      ----------------------------------------------------
      > > At 16 bits, I got a higher latency, around +10%.
      >
      > How do you switch gizmo~ from 24-bit to 16-bit? I'd try it in
      > 32-bit should be faster then... ;-)
      > If your interface (which?) does add latency, keep it in its
      > highest resolution always, just don't bother with anything
      > else... (never!)
      I just switch the whole built-in Apple's soundcard in the "Audio Midi Setup" application.
      OMM, I just have 16 or 24-bit, not 96-bit, at 32k, 44.1k or 48kHz. No less, no more.
      I think I'm going to pick up another interface this week, 96-kHz/24-bit or even 32-bit. The RME Fireface 400 seems a good candidate.
      Thanks a lot Stefan and Jean-Charles!
      Best wishes for 2007 ;-)
      Philippe
    • Jan 02 2007 | 1:48 am
      > Depends.
      > Ditto for the sampling rate.
      > And the sampling rate can be reported in [adstatus sr], not the sampling size.
      > "Built-in Audio" allows 32, 44.1 and 48 kHz, 16 or 24 bit for these three sampling rates.
      are you sure that is the actual hw converter setting, an
      not the data resolution (sent to coreaudio) when recording?
    • Jan 02 2007 | 2:18 am
      Hi Roman!
      That's what I was thinking first: the recording settings.
      I'm not sure, but it seems this is applied to the whole hardware AD/DA converters.
      Otherwise, I didn't get so much latency discrepancies.
      To be continued ;-)
      Philippe
    • Jan 06 2007 | 4:42 am
      Hi,
      (Not a hype, just a research I did for myself from this thread.)
      For people reading French, a good and impartial online review about the RME Fireface 400 at AudioFanzine:
      Bye,
      Philippe
    • Jan 07 2007 | 8:46 pm
      Quote: Philippe Gruchet wrote on Mon, 01 January 2007 19:18
      ----------------------------------------------------
      > Hi Roman!
      >
      > That's what I was thinking first: the recording settings.
      > I'm not sure, but it seems this is applied to the whole hardware AD/DA converters.
      > Otherwise, I didn't get so much latency discrepancies.
      no ... you are still on the wrong path. :)
      even if your built-in audio hardware could operate
      in 16 AND 24 bit mode, that there is a setting for
      32 bit too indicates that this is definetlay not
      the hardware setting ... because there is no 32 bit
      audio IO hardware.
      that setting is simply a conversion to coreaudio,
      which is irrelevant in MAX/MSP (as well as in quicktime
      player)
      then, what got resolution to do with latency? normally, nothing.