Mixbus doesn't set the buffer size correctly

[johne53]

BTW - does anyone know if this buffer size mismatch only happens on Windows? Or does it affect the other platforms too?

[deadguy]

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.

From a quick test, you're right - I can't see any difference that would be noticeable - thanks!

[sunrat]

BTW - does anyone know if this buffer size mismatch only happens on Windows? Or does it affect the other platforms too?

I just checked a couple of sessions and changed buffer sizes several times. Displayed buffer sizes matched in Qjackctl and MB 32C each time. MB 32C 6.2.407 and latest Qjackctl from rncbc PPA repo on Debian Bullseye.
Whenever I changed buffer in Qjackctl it would change in MB after restarting both. I didn't try changing it on the fly, somehow makes more sense to restart. Seems also to make more sense to change it in Qjackctl than try changing it in MB.

In Windows, does it make a difference if buffer size is changed in ASIO control panel rather than in Mixbus, or the other way around? I have Win10 but don't think I've booted it this year except maybe to use Izotope RX a couple of times. Not about to do it just to test buffers.

[johne53]

Interesting stuff... on Debian do you have any ability to launch without using Jack? What I see here (Windows 10 / PortAudio / ASIO4ALL) is that the buffer sizes do match if I use Jack. And they also match if I don't use Jack - but only if I select Buffered I/O  (so I guess it's possible that Jack might be using buffered I/O internally?? )

But if I use neither Jack nor Buffered I/O, the sizes only match at 1024 samples or 2048. At any smaller size, the size sent to ASIO4ALL seems to be 512 samples higher than whatever I selected in Mixbus 

[deadguy]

>> In Windows, does it make a difference if buffer size is changed in ASIO control panel rather than in Mixbus, or the other way around?

With Buffer I/O enabled, whatever is set in Mixbus becomes the buffer for me (which is the behaviour I would expect).

Disabling that I get totally different behaviour than I posted before. Now, whatever is set in either the control panel *or* Mixbus results in a buffer of 2048. No idea why that would have changed.

[sunrat]

Ok @johne53 I did some sciencing. With ALSA as backend I tested with 64, 256, 512, 1024 and 2048 shown as buffer size with 2 periods each time. ALSA reports the period size as what MB calls buffer size.
First one MB shows buffer size 64 samples, ALSA reports period size 64, buffer size 128:-

Code:

$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 10
rate: 48000 (48000/1)
period_size: 64
buffer_size: 128

$ cat /proc/asound/card0/pcm0p/sub0/hw_params
...
period_size: 512
buffer_size: 1024

$ cat /proc/asound/card0/pcm0p/sub0/hw_params
...
period_size: 2048
buffer_size: 4096

Audio/MIDI setup at 64 samples, ALSA shows period 64, buffer 128:


And with JACK:

Code:

$ cat /proc/asound/card0/pcm0p/sub0/hw_params
...
period_size: 256
buffer_size: 512

Conclusion - MB always shows the period size and calls it buffer size, whereas it should display period size x no. of periods = buffer size. Note also the latency reported in MB is half that reported in Qjackctl.
Not sure if that's the same in Windows but seems possible.

[johne53]

Interesting... I'd never even noticed before but on Windows, the Periods: entry is always blank !!

[sunrat]

Interesting... I'd never even noticed before but on Windows, the Periods: entry is always blank !!

Indeed. On Linux it's often advised to set 3 periods for USB devices and usually 2 is OK for PCI or PCIe devices. 2 and 3 are the only available options in the dropdown box.