On Fri, 2008-01-25 at 12:51 -0500, Paul Davis wrote: > On Fri, 2008-01-25 at 17:29 +0000, Bob Ham wrote: > > > > > Having said that, JACK should be very much more dynamic. You should be > > able to suspend the engine loop, change any setting, even change the > > driver, and resume graph processing without any hiccups. If any > > operation breaks real-time safety, clients should be able to register > > callbacks to be notified of when real-time operation stops and when it > > resumes (assuming all graph-execution is real-time.) > > making jackd/jackdmp do this is easy. > > the reason JACK doesn't do this (at present) is because of the burden it > represents to clients. one of the main reasons JACK has been widely > adopted is that it is simple and it hides almost of all aspects of the > h/w from clients, including sample rate.
Well, I'm surprised to see jack_set_sample_rate_callback in the docs then :-) I appreciate your point, though; very few clients implement that callback. JACK Rack pays attention to the sample rate when it saves and loads files; it will recalculate plugin control values if they're sample rate-dependant and the current rate is different to the rate when the file was saved. However, it *doesn't* implement a callback to do the same; that was always on the TODO list. > if the model changes to one in which clients have to deal with arbitrary > changes in sample rate, presence of absence of h/w ports and more, its > not that it cannot work, but it presents a more challenging API for many > complex clients. > > its has almost no impact on jack itself. so, before pushing for this > kind of thing so enthusiastically, i suggest we first consider how many > clients want to live in a processing graph that is truly this dynamic. Indeed. JACK Rack implements file-based sample rate changes because there is the issue of taking a save file to a different setup. It doesn't implement a JACK callback because a sample rate callback is such a rare event as to be a non-issue.* Regardless, what I'm pointing to really is an ideal. There's a scale of dynamicity. At one end is a system where each bit of the server is behind an abstracted interface and implemented through dynamically loaded and unloaded modules, where these parts communicate through well-defined tubes, where every change of state has its appropriate client-side callbacks, every client implements those callbacks, world peace prevails, etc, etc. At the other end is a jackd with just one big main() function. As it is, jackd is somewhere in between. What I'm proposing is a shift up the scale a little, towards world peace. There will be a limit where the costs in terms of client-side complexity outweigh the benefits. I think, though, that quite a lot could be done to improve the situation before hitting that limit. Bob * I seem to recall we've had this exact discussion before :-) -- Bob Ham <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
