Posts: 27
Threads: 4
Joined: Mar 2017
Reputation:
0
Hi all
I have a strange behavior on my Uad Apollo and Mixbus 32c .Apollo's buffer is always double the mixbus Session buffer ,if my session buffer is 512 Apollo is jumping to 1024 on mixbus startup, if it is 1024 then Apollo is 2048
Does anybody know why? and a way to fix this?
Another thing is that when i'm pressing stop the reverb tail is not audible until i restart mixbus,but after a while the problem reappears this must be a buffer problem.
I will appreciate any help
I'm new to mixbus and i really try to love it more than my Pro Tools and even make it my main mixing daw.
I love the sound but the workflow is a bit strange for me
Posts: 1,522
Threads: 48
Joined: Oct 2013
Reputation:
35
Are you using ASIO4ALL? I'm guessing you probably aren't but I remember seeing this problem once with ASIO4ALL. The values would only ever match if I selected the very highest buffer size. It was in the very early days of Mixbus3 - though strangely enough, it didn't affect Mixbus2. Updating ASIO4ALL fixed the problem (so maybe try and find out if the Apollo's got a more recent driver available).
Knowledge is knowing a tomato is a fruit...
Wisdom is knowing you don't put tomatoes in a fruit salad !!
Posts: 27
Threads: 4
Joined: Mar 2017
Reputation:
0
I think I found the answer in the 32c manual :
"On Windows, using ASIO drivers, you must choose the buffer size from the device’s control panel. Mixbus does not have control over ASIO buffer sizes."
I miss that during my first reading I think that must be the answer.
Thanks
Posts: 1,522
Threads: 48
Joined: Oct 2013
Reputation:
35
For a time we thought that this only affected older versions of ASIO4ALL but from what you're saying, it seems other ASIO drivers are affected too. You'll need to contact Mixbus support at Harrison.
Knowledge is knowing a tomato is a fruit...
Wisdom is knowing you don't put tomatoes in a fruit salad !!
Posts: 3,159
Threads: 105
Joined: Sep 2013
Reputation:
134
I know we have a lot of Apollo users. So I'm interested to hear if this is a common problem.
Presumably, samples are coming in to Mixbus at one buffersize, or another. We can send a little Lua script that reports the actual buffersize and determine which value is actually in effect. Once you know that, you can pick the correct rate and ignore the wrong display.
Posts: 36
Threads: 5
Joined: Aug 2015
Reputation:
5
As I am learning Mixbus for myself, I ran into this issue with my presonus 2626. It exactly doubles the buffer size on the presonus control panel. Clicking the Buffered I/O button on the mixbus audio setup allowed the audio interfaces to match buffers. My problem is that it doesn't seem to be as solid after doing this. I can't find anything about the buffered I/O setting and the real reason for it or if this is necessary? Thanks
Win 7-64/Dell Precision Dual Quad 3ghz/20gb-MX v5.3/32C v8.2.170-RME UFX/RME ff800
Posts: 3,159
Threads: 105
Joined: Sep 2013
Reputation:
134
The "buffered I/O" setting uses an alternative method of talking to the ASIO driver.
For those who care about such technical details: ASIO data can be transferred from the soundcard using either a "polling" method, or a "callback" method. The "callback" method is preferred and is used by the vast majority of software and devices. The "polling" mode incurs some extra buffers ( latency ) and is considered lower performance. For historical reasons, device drivers should implement both modes because old software might try to use the "polling" method. it's also possible that some device drivers -only- support one method or the other ( or more likely, operate better in one method ).
The "buffered I/O" button was added because it was found necessary in the Roland Octa-Capture devices (at the time of writing). It might also have some effect on other devices, but we don't have a comprehensive list ( and device drivers are updated occasionally, so our data would become outdated anyway )
@Sondy, you might try enabling the "Buffered I/O" setting to see if that resolves any issues for you. Sorry I didn't think of that sooner.
Best,
-Ben
