Re: [LAD] LADI

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

> From: alex stone <compose59@email-addr-hidden>
> Subject: Re: [LAD] LADI
> To: "Nedko Arnaudov" <nedko@email-addr-hidden>
> Cc: linux-audio-dev@email-addr-hidden
> 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@email-addr-hidden>
> wrote:
> > Patrick Shirkey <pshirkey@email-addr-hidden>
> 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@email-addr-hidden
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >
> >
>
>
>
> --
> www.openoctave.org
>
> midi-subscribe@email-addr-hidden
> development-subscribe@email-addr-hidden
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

      
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Dec 21 16:15:02 2009