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

On Fri, 2008-01-25 at 14:11 +0200, Juuso Alasuutari wrote:
> On Thursday 24 January 2008 13:09:55 Bob Ham wrote:
> > > In a debug version, it could be desirable, but for "production" use
> > > (sorry for webspeak) it is unacceptable. It should be as fault-tolerant
> > > as possible in those situations.
> >
> > Yes, you're right, JACK should be as fault tolerant as possible :-)
>
> I believe everyone on this list agrees on that. Would you have any ideas for
> improving the current situation? I have the impression that JACK should be
> able to produce a lot more debug on demand than it currently does; maybe this
> could ease the bug hunting?

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@email-addr-hidden>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev