[LAD] Buffer size changes. Was: Re: [LAU] Session management with NSM

Tim E. Real termtech at rogers.com
Thu Sep 4 02:28:57 UTC 2014

Hi, I'd like to get some feedback here in LAD.

On September 3, 2014 07:44:55 PM Fons Adriaensen wrote:
>> On Wed, Sep 03, 2014 at 11:57:05AM -0700, J. Liles wrote:

> > (when I go from recording to mixing I usually change the JACK buffer
> > size... is NSM supposed to do this for me automatically? I don't see how
> > or why it would).

> RE switching buffer sizes, if your system works reliably with some
> size, there is no reason to use a larger one.

Did Paul say recently Jack's buffer size change system was never implemented?
Do I recall correctly that there is no way to switch?
Is the difficulty with internals, or conceptually? Or compatibility - how about: 
If any client in the graph doesn't implement the callback or the callback 
 returns false, simply don't switch buffer size. Zero compatibility issues?

*** Usage Scenario 1:
You start your favourite DAW with what seems a moderate Jack buffer size.
As you work, you start adding effects to various tracks.
But you go too far, adding one too many CPU intensive plugins, 
 say Phase Vocoders and so on, and now you have at best xruns, 
 at worst slowness/freezing.

Now you must shut the app down, shut Jack down, adjust Jack's buffer size, 
 restart Jack, restart the application.

In light of the Pulse-on-Jack-QJackCtl threads these steps may not be easy.

Pushing an app button to be able to quickly switch to a higher buffer size 
 would be cool !

*** Usage Scenario 2: 
J. Liles pretty much just said what I wanted to say:

During (but not limited to) recording, if you require to be able to monitor
 one or more live inputs, low latency small buffers are absolutely required.
When I say monitor, I mean WITH effects plugins, otherwise hardware 
 monitoring can be used.
Here the DAW is being used as BOTH a recorder and an effects unit.
I do it a lot and it's a PITA to have to keep restarting with a new size.

After recording, when live input is no longer needed, we no longer care
 about the buffer size and in fact DEMAND high latency higher buffer sizes.

The caveat here is that when switching to the 'live' low-latency mode,
 we often have to first turn off some CPU-hungry plugins (non-essential on 
 playback tracks) and save the song before switching, otherwise after the 
 switch the app is slow/locked/frozen.
Then after switching back to non-live high-latency mode, we can safely
 turn on those plugins again. 
So we absolutely need those higher buffer sizes too sometimes.

I've been dreaming of having such a dual 'mode' switch in MusE.
>From lazy to tight at the push of a button. 


More information about the Linux-audio-dev mailing list