SOLVED: Please sign this petition: changing MAD from 24-bit to 32-bit ASIO driver

[robertopisa]

Although the following seems to be a technical issue, it involves all the Anubis/Hapi/Horus owners that use ASIO as their driver. What I propose improves audio processing in CPU and memory when using ASIO hosts, without any negative impact on the Ravenna protocol.

Please reply to this message if you agree with the petition below.

Currently MAD identifies itself as a 24-bit ASIO driver. However, todays machine do not require that much, actually 24 bits do not align well with machine that use 64-bit CPUs and memories. We ask Merging to change MAD so that identifies itself as a 32-bit ASIO driver.

• Making MAD a 32-bit ASIO driver is useful as some Pyramix recordings generate WAV files with 32-bit samples. Please do not tell me that we cannot distinguish any difference with 24-bit samples: the point is that one cannot play those Pyramix samples using MAD ASIO.
• Audio data is better aligned with 32-bit ASIO as its buffers require a number of bytes that is a power of 2, which is good for memory access and faster audio processing. For example, a buffer size of 64 samples for 2 channels would need 512 bytes, whereas it is currently 384 bytes.

Note that the above change would not impact the amount of bits transmitted through the Ravenna protocol, which stays the same. Only the CPU processing of audio data would change before sending it through Ravenna.

For the experts, the proposal is to change from "ASIOSTInt24LSB" to "ASIOSTInt32LSB" when MAD introduces itself as an ASIO driver.

P.S. Sorry I misspelled "sign" as "sing" in the title, but if you want to sing this petition is fine anyway, post your recording here

[robertopisa]

Not a very crowded forum indeed: anyway the point is that CPUs work with 8-bit, 16-bit, 32-bit, 64-bit, etc. data. So 24-bit data is a bit strange. It is only useful for Ravenna transmission as probably Anubis/Hapi/Horus have internally a 32-bit bus. For this reason, IMHO the burden of handling 24-bit data should be internal to MAD, rather than on the shoulders of the hosts using it

[robertopisa]

Finally

The latest release Merging Audio Device - MAD Driver - v2.1.0 Build 895 permits to choose between 24-bit and 32-bit samples in the MAD panel!

I strongly suggest to use 32-bit samples, the app using MAD will have less hurdles to handle 32-bit samples rather than 24-bit ones. I checked it, and MAD introduces itself as ASIOSTInt32LSB in this way.

Thank you Merging tech staff

[DJS]

Are you referring to 32bit float or 32bit fixed?

[robertopisa]

Hi DJS:

it's 32bit fixed:
ASIOSTInt32LSB = little-endian 32-bit integers (i.e. lowest byte first in the 4 bytes of each integer sample: B0 B1 B2 B3, where each Bi is a byte).

Note: nobody can hear the info in byte B0, so the relevant info is in the 24-bit B1 B2 B3 with ASIOSTInt32LSB; however it's cool to have B0 B1 B2 B3 for internal CPU processing, as CPUs works on 8-bit, 16-bit, 32-bit or 64-bit data (or even more).
-R