Mixbus doesn't set the buffer size correctly

[jeff_sloan]

Hi guys,
I wanted to put in my two cents as well on this issue.
I had the same problem described here, and it was driving me NUTS!
I know the last post here was well over a year ago, but it seems the issue still exists.

I was finally able to make things work reliably by following a set procedure.
1st...
Win 10 64, newest build.
MB 6.2.270
Behringer UMC 1820
Behringer ADA8200 adding 8 more i/o over adat
A mega machine, 3 nvme pro 970 drives in raid 0 on the motherboard.
32 gig of mem, etc.
Extra raid ssd drives for storage.

I can now get as low as:
16 samples at 48k, but at 100% DSP 4.00 ms i/o latency
32 samples at 48k at 90%, but not usable audio, 4.33 ms i/o
64 samples at 42% DSP, 5.00 ms i/o, very usable in the vocal booth, but I would like it to be less of course, and I am going to try a Presonus Quantum TB3 2626 interface to see if I can get that down to about 2.00 ms I hope.

Here is what I have to do now to get it to repeatably set the buffers on the UMC to 64, and match what MB says it is trying to do:
1. Set the buffers on the UMC Control panel 1st to 16 Buffers.
2. Then start MB audio engine set at 64 buffers / samples.
Now check UMC Control panel again, it is set at 64.

If I already have it at 64, and try to start MB at 64, UMC jumps to 128.
So I have to follow the 1st two steps above to get it right, and it works every time.
If I can find a command line option for the UMC to set the samples to 16 with a batch file, I would create a shortcut that would run that command first, then start MB with the autostart feature turned on.

[jeff_sloan]

I have since replaced the UMC 1820 and moved to the Quantum 2626.
I still have to set the interface to something low like 16 first, in order to get MB to set the interface to the same as what I set MB to, such as:
1. Set Quantum to 16
2. Set MB to 256
3. Start audio.
Then they are both set to 256

256 on the Quantum still equates to less latency than 64 or the UMC...

So anyway, it still seems to be a Mixbus issue, and not a UMC issue. Diffrent brand and even type of interface (USB, Thunderbolt) doesn't matter.

[deadguy]

I am also having this problem. I am primarily using a Behringer UMC202HD interface on Windows 10 (although this happens on other interfaces as well).

To reproduce:

• Set buffer in the ASIO control panel (e.g. 128 samples)
  
• Set the same buffer in Mixbus
  
• When the audio engine is started, the buffer immediately doubles to 256 samples
  
• If I close and open Mixbus again (with the audio engine set there to 128 samples), the buffer will increase to 512 samples)
  

I made a recording of this behaviour (note that this will loop):




The only solution I can find is to intentionally set the buffer to half of what I actually want - then it doubles to the size I need. It's easy to overlook this, though, and end up with a buffer that is too high.

[johne53]

It's probably not relevant - but if you read all the buffer sizes in your UMC Control Panel, do they match the values you see in the Mixbus Setup dialog ?

[deadguy]

Thanks for the reply! They do, they're exactly the same (8, 16, 32, 64, 128, 256, 512, 1024, 2048).

[GMSweet]

Did you try it with the "Use Buffered I/O" option enabled?

[deadguy]

Aha! With buffered I/O enabled it doesn't seem that the buffer size changes. Do you know if there are any implications to selecting this? I can't really find any information about it other than it's an "older version of the ASIO protocol". I'm particularly keen to avoid increasingly latency.

[Dingo]

https://forum.harrisonconsoles.com/threa...l#pid26774

[deadguy]

Interesting, thanks! I didn't manage to find that when searching. It sounds like something I'd want to avoid if possible, which would leave me with remembering to halve the buffer size

[johne53]

It sounds like something I'd want to avoid if possible, which would leave me with remembering to halve the buffer size

You might as well try the Buffered I/O option - I just tried it here and on my system, there was no difference in the audio or in Mixbus's DSP reading. So if it makes any difference at all, there's a good chance it won't be noticeable.