21 Dec
2009
21 Dec
'09
7:25 a.m.
Hi all,
I have a question about jacksession :
will it be able to handle situations when the PC, for a reason or another, goes to S3
sleep, and resumes from S3 ?
Of course, one can on purpose close the jack session after saving it, put the PC to sleep,
and resume things when awake. However, for more automated environments, or simply if you
run your stuff on a laptop and the latter goes to sleep on its own (due to some power
management scheme in place), could the jack session handle this (intercept some particular
ACPI events maybe) ?
J.
--- On Mon, 12/21/09, alex stone <compose59(a)gmail.com> wrote:
From: alex stone <compose59(a)gmail.com>
Subject: Re: [LAD] LADI
To: "Nedko Arnaudov" <nedko(a)arnaudov.name>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: Monday, December 21, 2009, 6:07 AM
Why not both?
Use either/or compile options:
--enable-jacksession
--enable-dbus
The bit you forgot to mention is the lack of network
session
capability using your dbus method. It's still not suitable
for
clusters.
However Bob Ham, in an earlier post, explained this far
better than i
could, so reading up will bear fruit. He also eloquently
highlighted
the rapidly ensuing complexity of having to run multiple
dbusses in
some fashion to counter the limitations dbus has in
providing cluster
support.
Far too complex, imho, compared to the simplicity, and
minimal impact,
jacksession has on the API. Torben has already proved this
emphatically, imho, and as a user tester i found it SIMPLE
and easy to
use. Surely a criteria for any developer to consider.
Add to that the ease at which he sessionised apps, with a
few lines of
code, compared with the wholesale reconstruction required
by lash, for
instance, and he makes a powerful and compelling case for
jacksession
as a modest additional component in the API. (imho)
Jacksession, as a component, was accused of being
insufficient,
therefore dismissed out of hand, for being "80%". The
situation is no
better with a dbus version, and likely other constructs
too.
So lets compare apples with apples here, if only for fair
assessment.
Alex.
On Mon, Dec 21, 2009 at 10:33 AM, Nedko Arnaudov <nedko(a)arnaudov.name>
wrote:
Patrick Shirkey
<pshirkey(a)boosthardware.com>
writes:
> From a normal users perspective we would need to
have an interface that
> gave us the options:
>
> - killing already running apps before loading a
session
> - attempting to rename the apps without
restarting
them
> - load a new jack instance and connect it
with
netjack
I don't get why these features are supposed to need
support from jack
itself. Session handler/manager starts the apps
and it
for sure knows
how to kill them (ladishd does this already).
Renaming
of the clients is
not needed for ladish to operate, because ladishd
implements graph
virtualization and boxes you see on canvas
(clients)
can be renamed and
ports can be regrouped. For handling apps that
use
multiple JACK
clients, more useful will be to have a function
that
returns the
originally requested JACK client name. netjack
has two
main uses
(Internet and LAN) but I don't see how jack
session
callbacks relate to
it. ladish-2.0 (multihost capable) will be able
to
start additional jack
servers, local or remote and use netjack
tehcnology to
link them in
single multihost studio.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev