Ability to change audio buffer size to different values within software settings. (Currently 512)
Useful for reducing latency.
I’ve opened this feature request for community voting.
Just a question @smokris, would this be best as a node or a preferences item? If we export Apps there may be pros and cons for each implementation?! For example you may want your app to be able to check the hardware of computer then assign a buffer value. (maybe check hardware node could be future node request?)
Also if its a menu item then people can change manually (in app).
Possibly it should be both?! Or at least preferences item first.
would this be best as a node or a preferences item?
I envision this being a port on nodes that receive or send audio data (e.g., Receive Live Audio, Play Audio File, Play Movie, Send Live Audio). Then the composition can statically or algorithmically decide which buffer size to use (or expose it as a preference for the person using the composition, using Make Button or other forthcoming UI widgets).
Is that to say you could mix audio buffer settings? A small size for midi computations and control inlets- yet a large buffer for summing etc?
Is there an easy way to make this happen without changing all audio nodes?
Is that to say you could mix audio buffer settings? A small size for midi computations and control inlets- yet a large buffer for summing etc?
Yes, this would enable a single composition to have multiple independent audio event streams with different buffer sizes. (I’m not yet sure whether OS X allows opening the same device with different buffer sizes though.)
Is there an easy way to make this happen without changing all audio nodes?
(Not that I know of.)
@smokris are we sure multiple size buffers is the best road to take? Are there any examples of other software that has this solution? I can imagine that they may get out of time?
Considering that each buffer needs to be computed before handing it to the next node- it sounds complex.
Maybe simply allow a user to set the block size and buffer multiples in the .vuo file?
That way someone could then make a composition a node and simply change that #define (or however it is encoded)
Apologies for the necromancy, but this is seriously important for anything with live audio. 512 introduces a lot of latency.
Yes it is. It may also be interesting to instead of having a buffer size per node, to allow audio nodes to split their buffer when a new event occurs.
This would mean there would be a Vuo buffer preference, (where we set the value), and internally the buffer can’t go longer than that value.
IIRC both VST & LV2 pass the buffer size to the audio function. Thus allowing those plugins to compute different buffer sizes on the fly.
That sounds slick. So by setting your buffer size, you’re setting a maximum length, but the buffer you end up with is dynamically set by the demands of the incoming data, right? Glorious.
I bought Vuo specifically for an upcoming project which will have visuals that are triggered by live audio. If I can’t get latency down to much smaller margins, it just ain’t gon’ look good! As it stands now the lag is… palpable. Definitely hoping we get this feature on a forthcoming release.
1 Like
Ardour is a GPL DAW that has ability to split buffers. Hence why all LV2 plugins always need to know the buffer size (not the sample rate, that’s set).
This allows as you said, a buffer to work with timming that are between buffers.
I don’t know how this would work in a live context, as Vuo would need to know in advanced where when to split the buffer. Which would mean that all incoming data (MIDI/OSC/controll) would need to be delayed by one buffer cycle.
I think that would be ok, given the benefit it would bring.
Hmm. Delaying anything by a buffer cycle would be okay in certain circumstances but very much not in others. It would certainly be great to have as an option, but I wouldn’t love being stuck with no option to disable it. For some things you just need as low a latency as possible, ya know?