OS X mavericks - Integer Mode is back

[Demondes]

Noticed that Jriver 19 for Mac now has an option to select integer mode.

 

So far I haven't had a chance to review any affect on sound quality.

 

 

Anyone else noticed features Good or Bad in Mavericks relating to audio?

Edited October 28, 2013 by Demondes

[hochopeper]

Gotta say I'm pretty dubious about Integer Mode. It's important to know that 32bit float has exactly the same number of discrete levels as 24bit integer .... 

 

There are a few things, IMO the memory and power related improvements can't hurt and might help. I thought there was a thread about it around here somewhere from back in June/July or whenever it was first announced there was some discussion about those issues in there.

[DoggieHowser]

Gotta say I'm pretty dubious about Integer Mode. It's important to know that 32bit float has exactly the same number of discrete levels as 24bit integer .... 

 

There are a few things, IMO the memory and power related improvements can't hurt and might help. I thought there was a thread about it around here somewhere from back in June/July or whenever it was first announced there was some discussion about those issues in there.

 

It's not about discrete levels I think but that the computer does a conversion to FP and back again. It's all about minimising any spikes in load, I guess.

[sir sanders zingmore]

What is integer mode?

[hochopeper]

It's not about discrete levels I think but that the computer does a conversion to FP and back again. It's all about minimising any spikes in load, I guess.

 

Not that simple, some processors are optimised for floating point and may well require exactly the same number of operations for integer or floating point math. Intel processors allow SIMD (single instruction multiple data) so there can be no increase in cycles necessary for either so no spikes in load, same amount of bits transferred from HDD to memory for both int and floating point (memory addressing has power of two addresses so 24bit int transfers in a 32bit int container inside the computer they are likely stored in 4byte packets). Like I said, I'm dubious because all of the reasons stated for it to be a good thing are not necessarily even true (more cycles, less conversions etc). I've given this a fair amount of thought at the DSP algorithm level and I'm not saying that it might not make a difference in some systems in some applications, but IMO it doesn't need to be different if both are done with the same level of care ....

Edited October 28, 2013 by hochopeper

[kdoot]

Chris I think the purported benefit is in the receiving end rather than the computer. Not having to convert from float to int in a tiny CPU or ASIC may make some difference.

[hochopeper]

Fair point kdoot, transport processor maybe ... I'll have a think about that.

i2s, pcm and spdif are twos complement though so no integers there, right?

Edit ... I'm still going to stay on the side of doubting the magnitude of any effect of integer mode processing I think.

2nd edit ... I2s isn't twos complement, unsigned binary int I'm pretty sure or I've now made two mistakes from not being bothered to look it up.

Edited October 28, 2013 by hochopeper

[Demondes]

Some Background on Integer mode.  A paper written by Damien Plisson (audirvana) 

 

 

http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf

 

The key point explaining Integer Mode

 

In Integer Mode (see figure 3) the player software

supplies a stream already formatted in

the native DAC format, thus optimizing synchronous

CPU load at the driver level. 

Edited October 28, 2013 by Demondes

[hochopeper]

I read that this afternoon Demondes and it's what lead me to my Post #5, it's an oversimplification and draws some conclusions without being based on anything other than intuition and that is a risk IMO because the way processors and data transfer happen in a modern electronic system is not always intuitive. 

 

I'm just not really seeing what they're 'optimising'. I've got more reading to do on CoreAudio in the next few weeks for some tests that I'm writing so if I find anything that sheds any light on that I'll come back here and share my learnings

 

 

I'm still sticking to my belief that OS tick coalescing, app nap, memory management and memory compression are more important to me than integer mode.

[kdoot]

Fair point kdoot, transport processor maybe ... I'll have a think about that.

i2s, pcm and spdif are twos complement though so no integers there, right?

Edit ... I'm still going to stay on the side of doubting the magnitude of any effect of integer mode processing I think.

2nd edit ... I2s isn't twos complement, unsigned binary int I'm pretty sure or I've now made two mistakes from not being bothered to look it up.

 

Twos-complement is signed, but it's still "integer" in the sense of being fixed-precision rather than floating-point. It's also the native representation for PCM audio data.

 

Some Background on Integer mode.  A paper written by Damien Plisson (audirvana) [/size]

 

 

http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf

 

The key point explaining Integer Mode

 

In [/size]Integer Mode [/size](see figure 3) the player software[/size]

supplies a stream already formatted in[/size]

the native DAC format, thus optimizing synchronous[/size]

CPU load at the driver level. [/size]

With all due respect to Damien, whose software I use daily, something there doesn't seem right. Let me explain.

Taking that section of the paper at face value you would think that Integer Mode is all about the player software sending data to the driver in integer format so that the driver can forward it to the "DAC" in its "native format" without performing conversions in the PC's CPU. If that were true, we would have "Integer mode" available for all DACs. But in the real world we know that many USB-attached audio devices (and Firewire too, I think) *cannot* accept integer-format data and so the software - even Audirvana - has to use floating point format instead. The Hiface 1 interface is a perfect example of this: it has never supported integer mode.

Instead, the difference between integer mode and floating point mode is defined at the other end of the USB cable. Many devices - such as my Audiophilleo - support both data formats. This is not about SPDIF or I2S which always use integer formats. It's about the format of the data as it moves over the USB connection.

Here's a relevant section of the USB specification:

http://www.usb.org/developers/devclass_docs/frmts10.pdf

See the "bFormatType" field of the Type I Format Type Descriptor in table 2-1 on page 10, the following section 2.2.6 (esp 2.2.6.1 and 2.2.6.3 on PCM format and IEEE_FLOAT format respectively), and table A-1 on page 29. What this part of the USB Device Class Definition for Audio Formats is telling us is that audio data can be represented in different ways within a USB packet. But note that 24-bit PCM data can be *losslessly* carried within a single-precision 32 bit IEEE_FLOAT format, which is what non-integer-capable devices are doing.

(That all refers to the version 1.0 of the USB Audio spec... version 2.0 doesn't contradict this but it's harder to offer a direct link to the document. If you want to read it, start here: http://www.usb.org/developers/devclass_docs/ )

So in plain English: when you plug in a USB audio device it tells the driver software what kinds of audio data encoding it supports, and the driver software relays that information up to the host operating system. Sitting on top of the OS are applications that want to send audio data to devices. They typically rely on a high-layer API like CoreAudio to invisibly take care of a bunch of routine tasks, such as converting between float and integer formats if necessary.

It seems that in Lion and Mountain Lion, CoreAudio decided that it would be simpler if all the apps just used floating point format and stopped giving applications the option to provide integer data. Damien worked around this in Audirvana by bypassing CoreAudio completely and talking in "Direct Mode" to the USB drivers. So if the USB audio hardware declared itself compatible with PCM format USB audio packets Audirvana could use Integer Mode.

Now Mavericks' CoreAudio seemingly has re-introduced PCM data format compatibility for software such as BitPerfect which knows the difference but doesn't want to go to all the insane effort that was required to make Audirvana work for the past two years.

[Demondes]

Hmm, Kdoot what you state seems reasonable.  

 

I would really need to dig deep into the tech barrel to even attempt a rebuttal.  Your knowledge in this digital arena certainly surpasses my own

 

D

[hochopeper]

 

Twos-complement is signed, but it's still "integer" in the sense of being fixed-precision rather than floating-point. It's also the native representation for PCM audio data.

 

that's what I was getting at but you said it much better than I 

 

 

 

So in plain English: when you plug in a USB audio device it tells the driver software what kinds of audio data encoding it supports, and the driver software relays that information up to the host operating system. Sitting on top of the OS are applications that want to send audio data to devices. They typically rely on a high-layer API like CoreAudio to invisibly take care of a bunch of routine tasks, such as converting between float and integer formats if necessary.

It seems that in Lion and Mountain Lion, CoreAudio decided that it would be simpler if all the apps just used floating point format and stopped giving applications the option to provide integer data. Damien worked around this in Audirvana by bypassing CoreAudio completely and talking in "Direct Mode" to the USB drivers. So if the USB audio hardware declared itself compatible with PCM format USB audio packets Audirvana could use Integer Mode.

Now Mavericks' CoreAudio seemingly has re-introduced PCM data format compatibility for software such as BitPerfect which knows the difference but doesn't want to go to all the insane effort that was required to make Audirvana work for the past two years.

 

I think we're generally on the same page wrt integer mode implementation in software. But perhaps you could help me nut something out that's got me a bit puzzled tonight ... I wrote a script a while ago that I was hoping to keep adding to until I can do a hardware level loopback to prove that bitperfect transfer is happening at hardware level rather than software loopback. This is sort of step one in my personal investigation into what the hell is going on with software and what stuff really is making a difference. I wanted to make my script basically OS agnostic so I used python and pyAudio and the first step is to evaluate what data formats are supported by the transmitter and receiver. Now I don't have a copy of the output from pre-Mavericks but I'm 90% sure the output has changed. I might have to sneak a copy of pyAudio onto my wife's MacBook Air before I update it later in the week and see what I get. I certainly wasn't expecting internal spdif input to support all of these:

{'16bit Int176400': True,
 '16bit Int192000': True,
 '16bit Int44100': True,
 '16bit Int48000': True,
 '16bit Int88200': True,
 '16bit Int96000': True,
 '24bit Int176400': True,
 '24bit Int192000': True,
 '24bit Int44100': True,
 '24bit Int48000': True,
 '24bit Int88200': True,
 '24bit Int96000': True,
 '32bit Float176400': True,
 '32bit Float192000': True,
 '32bit Float44100': True,
 '32bit Float48000': True,
 '32bit Float88200': True,
 '32bit Float96000': True,
 '32bit Int176400': True,
 '32bit Int192000': True,
 '32bit Int44100': True,
 '32bit Int48000': True,
 '32bit Int88200': True,
 '32bit Int96000': True}

Does that look right to you?

[kdoot]

I'm not sure what layer of abstraction that list is being produced from. Similar lists are available in the debug info from Audirvana.

[hochopeper]

pyAudio uses Port Audio to keep things transportable between platforms, I've read the docs a bit better and tonight I'll try adding something platform specific for OSX using: paMacCoreFailIfConversionRequired- http://people.csail.mit.edu/hubert/pyaudio/docs/#platform-specific

 

Sorry for brief tangent folks ... I do hope to eventually be able to share this project that I mention once I've got a few more bits of code written up  I hope it will give folks the ability to know for sure what parts are/aren't working as expected and know what settings are going to be sub-optimal for their hardware, at least cut down a few of the options.

Edited October 28, 2013 by hochopeper