12 Jan
2005
12 Jan
'05
2:39 p.m.
Restarting JACK is not a very satisfactory recovery
scheme.
All clients ports and their connections will be lost.
Well, running clients could remember the ports which they have
been connected to and auto-reconnect as soon JACKd appears
again (»active sensing« ;-). Clients could also do so
persistentely by saving the last used ports to the config
file. If the port isn't available any more, no auto
connection gets made. Just an idea. Hydrogen already can do
so, AFAIR. Very convenient.
JACK does not work very well without RT privileges.
So, it'll still need some time until the security issues are
addressed and prohibited.
[...]
JACK is not designed for sharing between users. Any
shared-memory approach like JACK would be hopelessly
insecure running as root while allowing arbitrary user
connections.
JACK does (recently and still only in CVS) support running
multiple concurrent servers. Each runs as a single user
and connects to a single card. So, multiple users could
each have their own card, or one user could use several
devices.
But I could not start two sessions for two different users and
both having sound support on the same card? OK, thanks, I
understood.
One-at-a-time sequential use of a single card by
multiple
users works better now. There were formerly a number of
problems with it.
Perhaps, some day, jack will be able to run as root and allow
different users with priviledges to do so to make connections
to it :) .
[...]
This is currently supported in JACK CVS, but not in
any
release version.
I already heard about it. I'm wondering how much the drift
between the different cards would be, let's say, in a period
of one hour. Perhaps I can try this out some day.
[...]
Yes, we'll see. Am I just hallucinating this or
did
someone say they run everything as root? In that
specialized environment, some of these problems might be
more manageable.
(System security would suck, of course.)
AFAIR I have heard the users always work as root. I really do
not want to support this design.
Steve is right that this is the hard part. And,
something
like gstreamer is probably the best approach. JACK is
really not intended to be a general-purpose sound server.
Much of its success comes from Paul's clear focus on
synchronous execution and low latency.
Well, I think a server between the common desktop applications
and jack is absolutely the best thing. But I really like the
idea that JACK is always present for the user, so if the user
wants to run an audio application (like a guitar FX rack) he
only needs to start it and it will connect to JACK directly
instead of using the 'desktop' soundserver.
If I had time, I'd play around with gstreamer and
try to
get it working really well with JACK. Maybe someone here
could do that and send progress reports to jackit-devel.
Give us a chance to be proactive about fixing problems.
I still didn't understand gstreamer completely (OK, I only
spend some minutes on the website). But AFIR gstreamer is not
a soundserver like arts or esound.
Thanks a lot for your wothy information.
Best regards
ce