Re: [LAD] Summercode 2008: LASH as a D-Bus service

On Fri, 2008-01-25 at 14:11 +0200, Juuso Alasuutari wrote: I'd point out that it's been a while since I did any work on jackd, so things could have changed. I get the impression, just from using it, that they haven't but I've not been into the code so I don't know. Also, I'm seeing things through the fog of time so my view may be blurred. 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.) It was the case that the engine and driver were pretty immutable. If the server was up and running, it meant a driver was loaded and the engine loop was executing. If a driver was unloaded or the engine loop stopped, it generally meant that the system was exiting (or crashing :-) Clients were either running in real-time, or the system was checking them out. I think this shouldn't be the case. There should be an intermediate state where there is a client graph but no driver. There should be a state where there is no client graph and no driver and if there is an empty client graph for whatever amount of time, the system should revert to this state automatically, thus releasing audio hardware. More importantly, there should be no problem changing from one state to another, and staying in any state indefinitely. The somewhat monolithic "jackd" should be broken into distinct parts, which cleanly and robustly go up and down: server-as-a-whole, engine, driver, graph, etc. If their existence is independant of one another, they should go up and down independantly. Like a car with a running motor, waiting for the driver to release the clutch and the gears to mesh, jackd should be happy to sit there doing nothing until enough of its parts are brought up for the system to burn some rubber. Moreover, it should be able to cope with the user pushing the clutch in, changing gears and releasing the clutch again. That's all I have to say about that. Bob -- Bob Ham <rah(a)bash.sh>