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
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
