For a device with this amount of channels this should be sufficient. I think the HDSPe MADI FX has even higher buffers due to the much higher amount of channels (3 MADI buses). UFX III: 188 channels, HDSPe MADI FX: 390 channels.

Sorry, don't know how this is with CC-mode.

I did some tries a few months ago. I think I put the CC-mode. I don't remember, but I'm pretty sure, because I test the card during several days. I see that new firmware is available, I 've to try it, but for the moment, I don't have time.

Someone can use the madiface UFX III on linux ?

For MacOS, when I put the card, and only in totalMix (or the other tool, i don't remember, 2 apps open with RME card), no other app, the size is 2048 max. I can't set it higher in TotalMix (or the other).

Best.

Regarding buffer size handling, this differs by operating system:

- Windows: The ASIO buffer size is set globally in the RME driver settings and applies system-wide to all applications.
- macOS: The buffer size is set per application; within the DAW/audio application itself, there is no global, system-wide setting.

- Linux (CC mode): AFAIK (I am not using it) no RME driver or TotalMix FX is active in Class Compliant mode.
The buffer size is therefore not defined by RME at all; it is determined by whichever Linux audio subsystem you are using. You have to investigate there whether/how it is changeable.

Sorry, it seems that I don't check the notifications. So, I just see now yours answers. Thank you very much.

At the beginning, I buy this card for linux, because class compliant. Unfortunately, it doesn't work under linux !
So i tried on a mac.

I use Jack audio and faust for audio processing. I'm not interested in real-time, it's just a "post-traitement". But, i have a lot of channels (ambisonic, 5th order) and my process under Faust and jack runs with a buffer of 4096 (under linux on another old rme HDSPe class compliant). With 2048, there is/are a lot of Xruns.

So, I see on the manual that the card accept a buffer size from 32 up to 8192 (p.8 of the manual). I don't know very well MACOS and I wonder if it's coming from MAC or RME...

Best

At a sample rate of 176.4 kHz, the calculation is:
53/176,400=0.00030045 seconds≈300.45 μs.

If you used 52 samples, you would be at 294.8 μs, which is below that 300 μs threshold.
That’s why the system rounds up to exactly 53.

Exactly correct.

300 microseconds ? Where you got this from ?

Originally from Jeff Moore from the CoreAudio team on the CoreAudio mailing list.  But the list is down so I can't link to his post.  IIRC, in reference to the 300μs figure he used a phrase something like "300μs is the smallest schedulable time quantum".

But I just simply get the buffer size range (min/max) for each sample rate from Apple's HALLab app. 

On my Mac, with Reaper 7, "Request block size" is in samples, and Reaper accepts block/buffer sizes that are not powers of 2 :

Preferences > Audio > Device > Request block size

Unfortunately, Reaper doesn't show what the minimum or maximum buffer sizes are.  But if you set a block/buffer size that is outside of the buffer size range, then the buffer size is capped to the minimum or maximum buffer size.

If the information from the internet is correct, then CoreAudio requests from the driver which range (min, max) it supports.
The application communicates with CoreAudio and shows the available buffer size either in ms or possibly as buffer size.
I assume both can happen, as he talks about a real number 2048 und I remember some people reported buffer sizes in ms.

So, as I suggested already. He should best add information to his feature request about why he wants bigger buffers.

RME certainly needs a good reason to change this in all drivers and for all buffer sizes.

CoreAudio sets a minimum buffer floor of approximately 300 microseconds (μs).

At a sample rate of 176.4 kHz, the calculation is:
53/176,400=0.00030045 seconds≈300.45 μs.

If you used 52 samples, you would be at 294.8 μs, which is below that 300 μs threshold.
That’s why the system rounds up to exactly 53.

You can see this constant logic across other sample rates too:
- At 44.1 kHz, the minimum is 14 samples (14/44100≈317 μs). 13 samples would be 294 μs.
- At 96 kHz, the minimum is 29 samples (29/96000≈302 μs). 28 samples would be 291 μs.

While most DAWs and Windows/ASIO drivers stick to powers of two (32, 64, 128...), CoreAudio is flexible and allows these "odd" buffer sizes if they meet the time-based minimum of the hardware abstraction layer.

Reaper might show milliseconds in some menus, but the communication with the RME driver always happens in discrete samples; in this specific case, 53.
DanRand likely derived the 300 μs figure from developer documentation or by "reverse engineering" the lowest possible buffer size at every sample rate and calculating the time for it.

The minimum possible buffer size would only be settable by an audio app that displays/allows it.  Possibly Reaper?

CoreAudio creates and maintains a buffer size range for each audio device.  The buffer size range consists of 2 numbers - the minimum and maximum buffer sizes.

Audio apps can choose to display a smaller set of buffer sizes within the device's buffer size range, often a short list of powers of 2.  Audio apps are also free not to allow/display very low or high buffer sizes within the buffer size range.

CoreAudio sets the buffer size range's minimum buffer size to 53 samples

Confusing... Where do you set this buffer size ?

Core Audio or the interface do not have buffer size settings.

LogicPro has buffer settings from 32 to 1024, single and double-speed sample rate.
Never seen a number 53 in digital world...? typo ?

Core Audio's Safety Offset
Under OS X, every audio interface has to use a so called Safety Offset, otherwise Core Audio won't operate click-free. The Fireface uses a safety offset of 64 samples. This offset is signalled to the system, and the software can calculate and display the total latency of buffer size plus AD/DA offset plus safety offset for the current sample rate.

Would it be possible to try to use only 32 samples at quad speed?

No.

For my UFX III, CoreAudio sets the buffer size range's minimum buffer size to 53 samples for 176.4k, and 58 samples for 192k.

A 32 sample buffer would only be possible at 96k and below on my system.