[LAD] JACK latency API clarifications

[Jörn Nettingsmeier]

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.






-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net