Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Mixbus doesn't set the buffer size correctly
#1
Hi!

I just bought the Mixbus32C v5 update and started checking it out. I notice that the latency on my VST instruments is very high. The audio setup says the buffer size is 128, but the Asio control panel says it's 2048. Whenever I start the audio, the buffer size on the Asio control panel will reset to 2048, no matter what I set it to in Mixbus.

Any one had the same problem and found a fix?

My audio card is a Focusrite Saffire 24. It works as expected in other Asio applications.

Cheers!

Edit: After changing the buffer size to 256 in another Asio app, quitting and starting MB5 again, the new "reset" value is 256. MB5 still does not set it to 128 as indicated in UI.
Reply
#2
Mixbus wont set your buffer.

(In mixbus’s audio/midi setup) Stop the engine....it has a button to open the device control panel, where you set the buffer you want, close control panel, “refresh devices” in Mixbus, and start the audio engine back up.

Not sure why Ardour (and therefore Mixbus) is the only app ever to not be able to change the ASIO sample rate or buffer size, but it cant. If its any consolation, it didnt do it reliably on OSX either, which is itself sadder, given that CoreAudio was intended for the average tech challenged Mac user to operate.

Anyway-the order of the above is important. Stop engine....make all changes....start engine.
Win10pro(2004) : i7 8700/RX570 8gb/16gb/970evo : RME PCIe Multiface : Mixbus 32c 4.3 & 7.2
Other DAWs: Logic 10.4 (MacBook) Cubase 10.5 (PC)
Music: https://jamielang.bandcamp.com
Reply
#3
Yes... you need to set things up in the ASIO Control Panel first, then (with the engine stopped) set everything in Mixbus to match the new values you've just set - then start the engine and it should work.

In other words, Mixbus can neither set your ASIO values and nor can it retrieve them - but the values in Mixbus must match the values in your ASIO Control panel.
Knowledge is knowing a tomato is a fruit...
Wisdom is knowing you don't put tomatoes in a fruit salad !!
Reply
#4
Hi,

Thanks for the replies. I have done some more testing and it doesn't work exactly as suggested, but somewhat like it.

When I do the stop - refresh - start cycle in MB5, the latency will double in the asio control panel each time. For example:

1. Stop audio
2. Set buffer size to 64 in MB
3. Set buffer size to 64 in Asio Control Panel
4. Refresh devices
5. Start audio

The actual buffer size in Asio Control Panel is now 128. The buffer size in MB5 Audio setup is 64. Audio out works despite the buffer sizes not being equal.

Continue:

6. Stop audio
7. Refresh devices
8. Start audio

The buffer size in Asio Control Panel is now 256. Each time steps 6 - 8 are repeated, the buffer size will double as per the Asio Control Panel, while being unchanged in MB5 Audio setup. The value in the Asio Control Panel seems to be the actual buffer size used.

Continue:

9. Stop audio
10. Start audio

Steps 9 and 10 do not change the buffer size reported by the Asio Control Panel.

I have only tested with my Focusrite Saffire interface so far.

Cheers
Reply
#5
And your sample rates match all along the way? The two settings are directly related....as in 128@96khz=256@48khz....and I HAVE seen Mixbus occasionally refers tho the wrong sample rate, and thus "double" my buffer--where ASIO is 128@88.2 it will show 256@44.1 when I hit refresh....takes a quit and back in kid of thing to get it straight.

....but, it doesn't happen here on any regular basis. Not sure what the set of conditions are that cause it.
Win10pro(2004) : i7 8700/RX570 8gb/16gb/970evo : RME PCIe Multiface : Mixbus 32c 4.3 & 7.2
Other DAWs: Logic 10.4 (MacBook) Cubase 10.5 (PC)
Music: https://jamielang.bandcamp.com
Reply
#6
(10-10-2019, 03:23 PM)JamieLang Wrote: And your sample rates match all along the way? The two settings are directly related....as in 128@96khz=256@48khz....and I HAVE seen Mixbus occasionally refers tho the wrong sample rate, and thus "double" my buffer--where ASIO is 128@88.2 it will show 256@44.1 when I hit refresh....takes a quit and back in kid of thing to get it straight.

....but, it doesn't happen here on any regular basis. Not sure what the set of conditions are that cause it.

Hi Jamie,

Good question. While testing this on my Focusrite interface they do match. If they don't match then the sample rate for the interface will change to what MB5 is using (48kHz for my project). The buffer size in the Asio Control Panel will double all the same, regardless of what the sample rate is before the interface is locked.

I've also tested with my other (USB) interface which is also Focusrite (2i4) and the behavior is there as well, but doesn't double. It goes 32 -> 64 -> 128 -> 192 -> 256 -> 320 -> 384 -> 448 -> ... I suspect this is a behavior related to the Focusrite driver, although I don't see it in other Asio applications. (Other applications don't have Refresh Devices, which is the feature that seems to cause the problem.)

The problem seems to be that when the interface is locked, the sample rate is set, but the buffer size is not and this causes undefined behavior.

Cheers
Reply
#7
(10-11-2019, 12:11 AM)jonasry Wrote: I've also tested with my other (USB) interface which is also Focusrite (2i4) and the behavior is there as well, but doesn't double. It goes 32 -> 64 -> 128 -> 192 -> 256 -> 320 -> 384 -> 448

[...]

The problem seems to be that when the interface is locked, the sample rate is set, but the buffer size is not and this causes undefined behavior.

Rather than being a doubling issue, this sounds as if Mixbus is somehow requesting a buffer size that's "one value higher" than the one selected by the user.

Does your Focusrite 2i4 also work using ASIO? It's strange that it should only happen with Focusrite interfaces but if you're not seeing the problem with other DAW's maybe the Mixbus dev team should investigate?
Knowledge is knowing a tomato is a fruit...
Wisdom is knowing you don't put tomatoes in a fruit salad !!
Reply
#8
Just came here looking for some similar information. Starting earlier week, my old Focusrite Saffire Pro 24 DSP stopped working in Mixbus and Reaper. Launching either app, the FW lock light would "freak out" for 10-20 seconds before re-locking, and then I got a similar experience as listed above. Since this was happening in multiple applications, and I wanted move to a USB interface so I purchased an Audient ID44 which came in today. Repear sync'd no problem, Mixbus however is not still sync'ing up on samples sizes. I'll be getting back to it a little later on, but I wanted to add a bit more information to the mix.

Of note, even if I set the interface to the rate the Mixbus is choosing, it's not right. Mixbus represents 512 samples, but when playing through it (I monitor through the DAW), it sounds more like 2048. I'll post back later when I have more data to share.
Tech specs: Windows 11, Asus Prime Z790-A, I7-12700K @ 7.7K; Hyper-threading enabled, G.Skill DDR5-5600 64GB RAM, Integrated GPU, Samsung 980 Pro M.2 1TB SSD, Benq 32" 4K Monitor
Mixbus 32C versions: 9.2
Reply
#9
Following up here... I started with a fresh session and was able to finally get the buffers to synchronize and stabilized. Once getting through a sync in the new session, I was able to close Mixbus and get back in to the original sessions that wouldn't synchronize the buffers and move about my day. I have not tried re-connecting my old Focusrite though as that was flaking out in every app.
Tech specs: Windows 11, Asus Prime Z790-A, I7-12700K @ 7.7K; Hyper-threading enabled, G.Skill DDR5-5600 64GB RAM, Integrated GPU, Samsung 980 Pro M.2 1TB SSD, Benq 32" 4K Monitor
Mixbus 32C versions: 9.2
Reply
#10
(10-12-2019, 03:57 PM)GMSweet Wrote: Just came here looking for some similar information. Starting earlier week, my old Focusrite Saffire Pro 24 DSP stopped working in Mixbus and Reaper. Launching either app, the FW lock light would "freak out" for 10-20 seconds before re-locking, and then I got a similar experience as listed above. [...]

I had that problem with the Focusrite not locking and having flashing lights, solved by updating to the latest Saffire Mix Control version. The flashing happened after a Windows update recently. Hope you get it sorted.

I've done some more testing and browsed the Port Audio code (it's open source). The Port Audio includes a wrapper on top of Asio, which I think Mixbus 5 is using.

The Port Audio Asio implementation does have a search function that searches for a valid buffer size using the user's requested one. This may explain why I see this progression of higher selected buffer sizes after pressing Refresh devices (assuming this means that a user setting is not available from MB at this point).

Here are my findings so far. (Document sample rate is 48k.)

1. If I select a buffer size of 256 or higher it works. The interface will use the buffer size selected by user in MB and the audio dialog will also show the correct buffer size.
2. If I select a buffer size below 256, Port Audio will adjust it up to 256, but MB does not update the selected buffer size in the list. So the buffer size in MB may show 128, but the effective one used will be 256.
3. Refresh devices is broken. If I click Refresh devices followed by Start, the Port Audio Asio implementation will select next higher allowed buffer size, even if the current one is allowed. This results in a progression of higher and higher buffer sizes each time Refresh devises and Start is clicked. When this happens, MB does not update the selected buffer size in the list, so it still shows (for example) 128, even though the buffer size used might be 2048.

Summary:

* MB has a UI bug where the selected buffer size is not updated if it's changed by the underlying Asio implementation (Port Audio in this case)
* Port Audio has an unexpected behavior for smaller buffer sizes (less than 256) not observed in other applications (including the Asio Control application for the interface)

The source code mentioned above is located here:
https://github.com/supercollider/portaud....cpp#L1820

Cheers
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)