Working in 32 bit

[Hibernatus]

Is it better to work and record in 32 bit sample rate (if storage is not an issue) since DAWs process audio in that format. Does it save processing power that way? What if the sound card can only go up to 24 bit and you record at 32 bit, where do the extra bits come from? I'm only interested in processing efficiency (i.e. how many VSTs I can put on a given channel), not 16vs24v32 fidelity wars.

 

[altitude909]

you cannot record in 32bit, no such hardware exists. Keeping a project in 32 bit float does not really gain you anything since the engine will always be 32bit float and the output will always be less than that

 

[Farview]

There is no such thing as a 32 bit soundcard. So even if you have the session in 32 bit, you are still recording 24 bit with an extra 8 zeros tacked on to the end.

The only reason for doing this is if you do a lot of destructive processing to the files themselves. If you just use real time processing, 32 bit is a waste.

 

[Hibernatus]

I'm still confused. I thought that if the DAW converts the 24 bit into 32 in real time (when I press play) having files in 32 bit in the first place would eliminate the need to convert and save CPU.

 

[Farview]

I'm still confused. I thought that if the DAW converts the 24 bit into 32 in real time (when I press play) having files in 32 bit in the first place would eliminate the need to convert and save CPU.

Converting from 24 bit to 32 bit is just a matter of adding eight zeros to the end of the 24 bits. It really doesn't take any CPU.

 

[dgatwood]

Converting from 24 bit to 32 bit is just a matter of adding eight zeros to the end of the 24 bits. It really doesn't take any CPU.

Uh... no. It's not 32-bit integer. It's 32-bit float. Converting from 24-bit integer to 32-bit float is definitely a non-zero amount of work. To avoid precision loss, you first must convert the integer to a double (64-bit float), then multiply by a scaling factor, then reduce the double to a 32-bit float. It's not a huge amount of computation, but it is probably at least twenty or thirty clock cycles or so per sample. (I'm not going to sit down and write out the instruction stream to get an accurate estimate, but it is a fair number of instructions, most of which take multiple clock cycles even if the data is already in a cache line.)

That said, you have to weigh the conversion against the I/O cost. 32-bit float is going to take 33% more I/O bandwidth to your hard drive, and that costs a bit in terms of CPU overhead. In the grand scheme of things, I'd expect the I/O overhead from staying in 32-bit float to be greater than the overhead caused by conversion if I were guessing.... In any case, which one is faster would be machine-dependent. A machine whose I/O uses relatively little CPU (SATA) might do better with 32-bit float files (not sure); a machine doing I/O with a piggish bus (USB) would almost certainly be better off using 24-bit files and doing the conversion.

 

[Hibernatus]

Uh... no. It's not 32-bit integer. It's 32-bit float. Converting from 24-bit integer to 32-bit float is definitely a non-zero amount of work. To avoid precision loss, you first must convert the integer to a double (64-bit float), then multiply by a scaling factor, then reduce the double to a 32-bit float. It's not a huge amount of computation, but it is probably at least twenty or thirty clock cycles or so per sample. (I'm not going to sit down and write out the instruction stream to get an accurate estimate, but it is a fair number of instructions, most of which take multiple clock cycles even if the data is already in a cache line.)

That said, you have to weigh the conversion against the I/O cost. 32-bit float is going to take 33% more I/O bandwidth to your hard drive, and that costs a bit in terms of CPU overhead. In the grand scheme of things, I'd expect the I/O overhead from staying in 32-bit float to be greater than the overhead caused by conversion if I were guessing.... In any case, which one is faster would be machine-dependent. A machine whose I/O uses relatively little CPU (SATA) might do better with 32-bit float files (not sure); a machine doing I/O with a piggish bus (USB) would almost certainly be better off using 24-bit files and doing the conversion.

Excellent info, I think some tests are in order.