You are not logged in. Please login or register.
RME User Forum → MADI/AES Premium Line → Madiface ufx III and buffer size
Hello,
I'm under MAC M2 (Tahoe).
Is it possible to set the buffer size to more than 2048 ?
Best
Hi Babose, and welcome to the RME user forum.
I heard somewhere that using too high buffer sizes might cause issues.
I am not 100% sure whether this is really the case, but 2048 is already very high.
Also, under Windows, you do not have a higher value than 2048 at single speed.
What is the issue that you think you would need it, and which driver do you currently use?
The driver kit driver allows adding a higher "safety offset" in the driver settings, which means "more buffers", see manual p. 34.
EDIT: Higher safety offsets are also possible with the kernel extension driver; see manual p. 35.
EDIT2: See posting below: https://forum.rme-audio.de/viewtopic.ph … 77#p250077
Yes, but depending on the audio app.
CoreAudio sets the maximum buffer buffer size for a device, not the audio driver.
EDIT: Although the audio driver may be able to influence the maximum buffer size, by setting the size of the driver's internal ring buffer to a smaller size
Yes, but I only referred to the size of the buffer, like him.
It doesn't matter much whether the driver sets it or the application for Core Audio.
It's about the size of the buffer, and he wants more than 2048.
If the audio app doesn't offer a buffer size higher than 2048 samples, then the only option would be to use an audio app that does if you really need those higher buffer sizes.
CoreAudio sets the buffer size range. For kernel drivers at least, CoreAudio takes the size of the driver's internal ring-buffers into account when setting the maximum buffer size for that buffer size range.
It's totally up to audio apps to choose which buffer sizes within that range users are allowed to set/select.
By the way, on my Monterey iMac, CoreAudio now seems to cap the maximum buffer size to 4,096 samples.
Ah, now I am getting your point. I didn't know that macOS allows for more than 2048 and that this is being handled by applications differently.
With Windows you also have higher buffers in the driver, but only at higher sample rates because of the higher data throughput.
The double amount at double speed and four times at quad speed (up to 8192).
So with macOS, you could also use, e.g., 8192 at single speed?
Ah, now I am getting your point. I didn't know that macOS allows for more than 2048 and that this is being handled
So with macOS, you could also use, e.g., 8192 at single speed?
Sorry my last line was added as an edit. CoreAudio now seems to cap the maximum buffer size to 4,096 samples.
CoreAudio used to just set the maximum buffer size to 3/8ths the size of the driver's internal ring-buffer. But it now won't allow a maximum buffer size higher than 4,096 samples on my Monterey system any more.
The maximum buffer size can also be lower than 4,096 samples. CoreAudio sets my HDSPe Digiface's maximum buffer size to 3,072 samples.
Ok, and what happens if you use 192 kHz?
With Windows ASIO, the buffer sizes are at quad speed between 128 (4x32) and 8192 (4x2048).
Is the maximum with macOS still 4096 with quad speed?
Would it be possible to try to use only 32 samples at quad speed?
The maximum buffer size for my UFX III is 4,096 samples for 88.2k, 96k, 176.4k, and 192k.
For 44.1k and 48k, the UFX III's maximum buffer size is 3,072 samples.
For my Digiface, running on the kernel driver, the maximum buffer size is 3,072 samples at ALL sample rates.
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.
Low enough, much lower compared to ASIO, maybe due to higher internal safety offsets, see RME manuals about Core Audio
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.
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 ?
Yep, 53 @ 176.4k! I know, it's a weird looking number. But there is a reason, and the reason is that CoreAudio sets the minimum buffer size to as close to 300 microseconds as possible at each sample rate, without going below 300 μs.
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.
300 microseconds ? Where you got this from ?
you have calculated 53 samples buffer from somewhere ? From where ?
What DAW are you talking ?
Reaper uses Milliseconds for buffer and it has no max or minimum number given.
The setting has to be useful.
If I understood correctly from DanRand.
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.
Thanks for enlighting it makes sense.
Coming back to Babose's initial question.
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.
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.
Reaper uses Milliseconds for buffer and it has no max or minimum number given.
The setting has to be useful.
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.
Thanks for your answer it is helpful.
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.
RME User Forum → MADI/AES Premium Line → Madiface ufx III and buffer size
Powered by PunBB, supported by Informer Technologies, Inc.