asked Apr 10 '15 at 13:54 by ratsnake (211)

Hi, I've been testing BW to be a master clock for some hardware devices (DR660, Analog 4 through Midiman Midisport 2x2) and I am getting a very noticeable tempo drift making the feature almost unusable. I haven't had any issues with SEQ24 that sends clock through the Midisport as I am wondering if anyone has any experience with this issue and a workaround. thanks!

I think, the jitter you still have, comes from the audio buffer. Can you see if reducing that to 128 or even 64 samples helps?

If so, we'll have this fixed in one of the next revisions - we'll decouple midi transmissions from the audio buffer - they're linked out of technical reasons right now.

Using Alsa is not recommended at all. That is just bound to procure serious issues in all kinds of areas.


answered May 18 '15 at 16:34 by riot ♦♦ (1.8k)

Hi - i improved a bit on my setup detailed above (by following some additional tips at - ). I think the only thing i didn't bother with was the realtime kernel since i think regular ubuntu is already a realtime kernel. Now I've got it at 64 frames and I get a lot of XOR alerts and what not but the midi is quite stable. I haven't tested the audio though :) - probably suffers but yeah I didn't test is rigorously.

  — (May 18 '15 at 17:13) ratsnake

Any updates on decoupling the MIDI clock from the audio buffer size? When might we expect to see that happen? Really constrains the available resources for DSP to have to have such a small buffer size to keep the clock in sync.

  — (Dec 29 '15 at 17:51) virek

After some long testing I seem to have found a good setting for my setup. The external sequencer clock of the DR-660 is stable but it does slip - so this isn't perfect. The culprit is most likely Jack settings for the machine or the way BW uses it (Causes "ERROR: JackEngine Xrun: client Bitwig Studio was not finished, state = Triggered"/"Running" + "ERROR: JackAudioDriver: ProcessGraphAsyncMaster: Process error" - although these now happen sometimes without ever causing tempo slip. I also get "XRUN callback (#)" + "XRUN callback (# skipped)" messages that seem to trigger slip for sure) Going to post my finds in case it helps someone:

My setup is an elderly Lenovo Ideacentre with an internal sound card and Midispot 2x2, running Ubuntu 14.04.2 LTS / 3.16.0-34-generic. I am using qjack 0.3.10 with BW with the following settings: Priority: 89 Frames/Period: 256 Sample Rate: 96000 Periods/Buffer: 4

only Realtime is checked on the parameters and MIDI Driver is set to none and ALSA Sequencer support is turned off in the Misc tab.

I've removed Pulse Audio, added my username to the Audio group and adjusted the /etc/security/limits.d/audio.conf to contain:

 - @audio - rtprio 95
 - @audio - memlock unlimited
 - #@audio - nice -19

(I also see some different lines for this file at this guide: , so might try those as well.)

I've also installed linux-tools-3.16.0-34-generic and set cpupower frequency-set -g performance (also intalling and adjusting cpufrequtils to use this setting upon system boot (GOVERNOR = "performance")

I have a feeling the above adjustments to the system only marginally help, and the main settings that insure solidity are the Jack settings specific for your system. The XRUN errors seem to happen depending on what I am doing on the system - for example opening the Ubuntu System Settings will cause a "XRUN callback (#)" almost 100% of the time. I also read that WIFI can cause latency issues with audio.

I still believe that SEQ24 provides a better clock and my tests were done before any of the above system adjustments. I did run SEQ24 without and withJack and at that time I was also trying BW using the ALSA driver - which was running better than Jack with default settings, but still unstable compared to SEQ24.

I also tested MIDI Thru chaining earlier, with the clock going to DR-660 and via MIDI THRU to a Nord Micromodular that was running a sequence (with correct external midi clock patching setup). With the previous settings I was able to desync the chained devices - but I would have to test this again now.

I also ran into very funky issues like BW sending only a maximum clock of around 110 even when the setting was turned higher than that. I was able to cause total chaos by changing midi tempos very rapidly. I also had midi issues when running a Micromodular with both BW and the Nomad patch editor at the same time - but these were initial tests with either ALSA in BW or default Jack.

anyway...not solid enough yet..but thats that.


answered Apr 12 '15 at 15:38 by ratsnake (211)

edited Apr 12 '15 at 15:48

bitwig is well established as a crippled machine for any form of MIDI CLOCK implementation..... as a slave to studio one here it wanders aimlessly all over the tempo and settles at about a 2:3 ratio of the selected tempo...COMPLETELY UN USABLE...AND A WASTE OF MONEY


answered Apr 07 '19 at 04:11 by blissbomb (11)

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: Apr 10 '15 at 13:54

Seen: 3,957 times

Last updated: Apr 07 '19 at 04:11