buzz forums

As you know, Polac asio contains within it some additional options which affect how midi is handled within buzz.
Firstly, of course, we have our number of samples, with fewer being better, but facing diminishing returns in the >10ms range

But then we have several other options, some of which seam obvious, but others that are perhaps more arcane. I'll add that in my case, I'm using midi instruments as live controllers, namely a piano and some drum pads. I'm not using any midi output to control synths or anything like that, but by all means feel free to share any wisdom on that subject as well.

So, what do these settings do, and how should I set these to have optimal midi performance? cpu be damned.

Use alternative midi delay compensation (unchecked by default) <-this is the most mysterious one.
boost midi thread priority (unchecked by default) <- this one sounds good to me, I check it!
sync to asio timestamp (unchecked by default) <- this one sounds like it's for synchronizing buzz to an external clock?
exact midi timing (checked by default) <- exact! now that's what I'm talking about
auto resync (unchecked by default) what does it mean!?

My midi interface is the roland um-one usb midi interface if that bears upon anything.
Which reminds me of another related question.

When using midi through usb is it preferable to use a fully modern usb 3 slot? I've occasionally speculated "what if usb3 has higher bandwidth, but also higher jitter and latency due to it's microcontroller or something like that!?" I don't know I'm just speculating, although I do plug into a usb1 as a result of this speculation since I know the bandwidth of midi is vanishingly small by modern standards.

It's best to leave it as it is. Actually i don't know exactly what all these settings do at the moment.

Use alternative midi delay compensation (unchecked by default) <-this is the most mysterious one.

It just adds a fixed offset to the midi delay. Can be enabled when audio and midi is not in sync.

sync to asio timestamp (unchecked by default) <- this one sounds like it's for synchronizing buzz to an external clock?

Every asio driver thread should deliver a timestamp to help syncing audio and midi. By default I'm generating a timestamp on my own in the audio thread instead of using the asio timestamp.

boost midi thread priority (unchecked by default) <- this one sounds good to me, I check it!

On my old system all worked fine without enabling this one here.

@ oncircles: Thank you for your questions on this "midi-switches".

@ polac: Thank you for your answers, good if a "pro" is still present.

For USB v1 & v2 the faster interface in new OS is the windows one. Of course, Polac drive gives more control over I/O but the most of the drivers have slower response times.
The better settings depend on your processor, caches, ram and background usage.
Just do a few testings with an overloaded project and decide how each settings affect your machine.

I'm skeptical of your claims, wikter.

onecircles wrote:I'm skeptical of your claims, wikter.

rightfully so
WASAPI is not bad, especially if you have onboard sound without ASIO support. But even then, there's always ASIO4ALL which does quite a good job too. On professional interfaces, ASIO is still the way to go of course. All these solutions can give you latencies below 10ms, so nothing to complain there. Just stay clear of all the other options (Window Waveform Audio / DirectX etc).

btw the bandwith of usb doesn't matter at all, at least not for stereo operation. even usb1 would work fine for that. some older mainboards do indeed have shoddy usb3 ports though (mostly very early usb3 implementations and on the amd side of things iirc). if you really have problems with usb3, just try a usb2 port. RME website has some info on this. Before anything else i'd see if you have DPC problems though, and hunt down whatever driver is causing them. On multiple occasions i've had to rollback a new network or gpu driver that was causing DPC latencies to spike.

The lion's share of the latency we experience is, of course, derived from the number of samples. I had wondered, and Polac did a shed some light on what might be happen in the more esoteric options in polac's package.

I didn't imagine that bandwidth would be an issue in any case, as the maximum bandwidth of midi is very, very low. I was more concerned about latency and jitter that might be introduced when routing midi through usb. Your comment about early usb3 on amd is very interesting.

Now this is purely speculation, it's really just a question, and I suspect it would require some specialized equipment to test.

1. Given a clean and even midi signal, is jitter the same when being routed through usb 1 2 or 3?

The example of DPC is an illustruative case, because computer hardware and instruction sets are getting better all the time, right? But in the transition to the later socket types you have the introduction of this new factor where the operating system, and the cpu and the chipset are creating inconsistencies in the performance of the machine.

DPC is a big factor for me (and should be for anyone) when picking a motherboard for an audio computer, but I wasn't really keen to the fact that it can be introduced by other drivers! I'll have to dig up that dpc checker and test whenever I change anything now... thanks!

My system feels very responsive to me. I don't find I can tell the difference between latencies under 10ms but above that, things become clear very quickly.

Kurzweil Midi Board
Roland um-one
akai mpd 32

The next thing I'm going to buy is a control surface with a bunch of faaddeerrssssss!