[LAD] JACK latency API clarifications

Lieven Moors lievenmoors at gmail.com
Fri Feb 21 20:30:18 UTC 2014

On Fri, Feb 21, 2014 at 08:34:16PM +0100, Jörn Nettingsmeier wrote:
> On 02/21/2014 07:52 PM, Lieven Moors wrote:
> >>it was part of the API very early on, then we decided we didn't want to
> >>impose the possibility of change on clients. as time goes on, it becomes
> >>clear (to me at least) that we should have implemented it.
> >
> >What would be use cases for changing the sample rate dynamically?
> having wired up a complex signal graph, which for the most part depends on
> the studio, not on the project at hand, and then having to deal with
> different projects in different sample rates.
> say your studio involves three monitoring setups, one main stereo, one
> nearfield, and one surround, you are using jack to do EQ on those things, in
> my case there's an ambisonic decoder in the loop as well. that means the
> jack graph is already quite elaborated. in that case, it would be nice to
> leave it running while switching from, say, a cd project at 44k1 to a tv
> thing at 48k.
> as it is now, i have decided to do _everything_ at 48k (i have no second
> thoughts about a final resampling step), but if a client brings material at,
> say, 96k, i have to downsample first. sometimes i wish for an easy way to
> reclock a graph. obviously, nobody expects this to be gapless. fading
> everthing down and then taking a few seconds to reclock everything would be
> fine.
> but then, many pieces of software in my chain would need changes. for
> instance, an important piece of dsp for me is jconvolver, as it sits in
> front of all my speakers.
> of course, the impulse responses i use for EQ and room correction only make
> sense for a given sample rate - it would have to be changed to swap one set
> of IRs for another during a reclocking call, and of course that needs to be
> configured and the user actually needs to provide those different IRs.

Yes, I see...
I got into the habbit of using the same sample rate for all my projects
as well. And I can remember a few times I wished to change the sample rate 
on the fly. 

Now I wonder if this would be difficult to implement. Do many clients
expect the sample rate to remain stable? Aren't most clients checking for 
the sample rate in the process callback anyway? Of course, clients depending 
on samples or IR's would have to play back at the wrong rate...


More information about the Linux-audio-dev mailing list