jack and powermanagement ... wrapping it up.

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

jack and powermanagement ... wrapping it up.

torbenh

hi...

merging parts of the discussion we had on irc.

the basic problem:

when suspending or hibernating a laptop while jackd is running.
both jack1 and jack2 go haywire.

jack1 gets killed by the watchdog.
jack2 goes into an infite error loop.


on linux we seem to get a dbus signal from upowerd.
i am not sure, if there still are some scripts being executed, which we
might hook.


one of the questions we have been discussing is whether the suspend is
a backend switch, or not.
during the suspend, usb cards might be unplugged, etc. so upon resume,
we might find ourselves in a situation, where the old backend is not
availabe anymore.

however... quite often the old soundcard is still there.
and since jack1 doesnt even have properly working backend switching. i
am advocating, that suspend/resume is more like freewheeling than
backend switching.

i am pretty convinced, that internally to jack engine, there should
be a pair of jack_engine_suspend() / jack_engine_resume() functions.
jack_engine_resume() might fail.

for jackdbus, its probably enough to expose these functions via control
api. jackdbus can listen for the relevant signals from upower, and
people get happy. (do not expect nedko to implement this though)

question is how to expose these functions to an instance which can hook
to dbus in jack1...

for these consderations it might also be interesting, what happens
during a suspend on osx.
maybe we just need a set of platform specific hooks for this.

i dont think it would be bad to just have some ifdeffed dbus code for
this use-case. (notice that we just listen for 2 signals on the SYSTEM
bus. not the session bus). i actually think that more than 50% of fonss
systems have a system bus ;D

oh well... dont flame me.


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

philippe-62
just a quick note: aside powermanagement, there exit a need for such a
functionality if you want to launch some audio processing when a
usb/ieee1394 audio card become available, and stop it when powering it
off - without cripling the logfiles with jack errors. - I'm using
jack2 on a mac and writing a tiny firewire watcher for this particular
purpose.

On Fri, Oct 29, 2010 at 5:31 PM, torbenh <[hidden email]> wrote:

>
> hi...
>
> merging parts of the discussion we had on irc.
>
> the basic problem:
>
> when suspending or hibernating a laptop while jackd is running.
> both jack1 and jack2 go haywire.
>
> jack1 gets killed by the watchdog.
> jack2 goes into an infite error loop.
>
>
> on linux we seem to get a dbus signal from upowerd.
> i am not sure, if there still are some scripts being executed, which we
> might hook.
>
>
> one of the questions we have been discussing is whether the suspend is
> a backend switch, or not.
> during the suspend, usb cards might be unplugged, etc. so upon resume,
> we might find ourselves in a situation, where the old backend is not
> availabe anymore.
>
> however... quite often the old soundcard is still there.
> and since jack1 doesnt even have properly working backend switching. i
> am advocating, that suspend/resume is more like freewheeling than
> backend switching.
>
> i am pretty convinced, that internally to jack engine, there should
> be a pair of jack_engine_suspend() / jack_engine_resume() functions.
> jack_engine_resume() might fail.
>
> for jackdbus, its probably enough to expose these functions via control
> api. jackdbus can listen for the relevant signals from upower, and
> people get happy. (do not expect nedko to implement this though)
>
> question is how to expose these functions to an instance which can hook
> to dbus in jack1...
>
> for these consderations it might also be interesting, what happens
> during a suspend on osx.
> maybe we just need a set of platform specific hooks for this.
>
> i dont think it would be bad to just have some ifdeffed dbus code for
> this use-case. (notice that we just listen for 2 signals on the SYSTEM
> bus. not the session bus). i actually think that more than 50% of fonss
> systems have a system bus ;D
>
> oh well... dont flame me.
>
>
> --
> torben Hohn
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Paul Davis
On Fri, Oct 29, 2010 at 11:56 AM, philippe <[hidden email]> wrote:
> just a quick note: aside powermanagement, there exit a need for such a
> functionality if you want to launch some audio processing when a
> usb/ieee1394 audio card become available, and stop it when powering it
> off - without cripling the logfiles with jack errors. - I'm using
> jack2 on a mac and writing a tiny firewire watcher for this particular
> purpose.

this is what the JACK Control API is designed for. it includes calls
to change the backend used by a running instance of JACK.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

torbenh
In reply to this post by philippe-62
On Fri, Oct 29, 2010 at 05:56:07PM +0200, philippe wrote:
> just a quick note: aside powermanagement, there exit a need for such a
> functionality if you want to launch some audio processing when a
> usb/ieee1394 audio card become available, and stop it when powering it
> off - without cripling the logfiles with jack errors. - I'm using
> jack2 on a mac and writing a tiny firewire watcher for this particular
> purpose.

hmm... i think this is not totally related.
first of all the backend needs a way to shutdown properly if a removable
card is pulled.
in this case jack2 should automatically backend switch to dummy or
something. i dont know whether its possible to switch jack to another
backend, after this happened on osx.

but i want to stress that unplugging of hardware is something which
surely needs to be considered, but its not the general case.
the general case, is just that the device gets power cycled, and we just
need to handle clock skews and such by open/closing the backend.


since your on osx, could you check the suspend behaviour ?
maybe coreaudio is able to handle this in a transparent way ?


>
> On Fri, Oct 29, 2010 at 5:31 PM, torbenh <[hidden email]> wrote:
> >
> > hi...
> >
> > merging parts of the discussion we had on irc.
> >
> > the basic problem:
> >
> > when suspending or hibernating a laptop while jackd is running.
> > both jack1 and jack2 go haywire.
> >
> > jack1 gets killed by the watchdog.
> > jack2 goes into an infite error loop.
> >
> >
> > on linux we seem to get a dbus signal from upowerd.
> > i am not sure, if there still are some scripts being executed, which we
> > might hook.
> >
> >
> > one of the questions we have been discussing is whether the suspend is
> > a backend switch, or not.
> > during the suspend, usb cards might be unplugged, etc. so upon resume,
> > we might find ourselves in a situation, where the old backend is not
> > availabe anymore.
> >
> > however... quite often the old soundcard is still there.
> > and since jack1 doesnt even have properly working backend switching. i
> > am advocating, that suspend/resume is more like freewheeling than
> > backend switching.
> >
> > i am pretty convinced, that internally to jack engine, there should
> > be a pair of jack_engine_suspend() / jack_engine_resume() functions.
> > jack_engine_resume() might fail.
> >
> > for jackdbus, its probably enough to expose these functions via control
> > api. jackdbus can listen for the relevant signals from upower, and
> > people get happy. (do not expect nedko to implement this though)
> >
> > question is how to expose these functions to an instance which can hook
> > to dbus in jack1...
> >
> > for these consderations it might also be interesting, what happens
> > during a suspend on osx.
> > maybe we just need a set of platform specific hooks for this.
> >
> > i dont think it would be bad to just have some ifdeffed dbus code for
> > this use-case. (notice that we just listen for 2 signals on the SYSTEM
> > bus. not the session bus). i actually think that more than 50% of fonss
> > systems have a system bus ;D
> >
> > oh well... dont flame me.
> >
> >
> > --
> > torben Hohn
> > _______________________________________________
> > Jack-Devel mailing list
> > [hidden email]
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> >
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Fons Adriaensen-2
In reply to this post by torbenh
On Fri, Oct 29, 2010 at 05:31:32PM +0200, torbenh wrote:

> i dont think it would be bad to just have some ifdeffed dbus code for
> this use-case. (notice that we just listen for 2 signals on the SYSTEM
> bus. not the session bus). i actually think that more than 50% of fonss
> systems have a system bus ;D

None of them actually. Unless I run avahi and that is used only for
network printing and started along with cups only when required.
And recently hal has gone as well (since Xorg doesn't require it
anymore).

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

philippe-62
In reply to this post by Paul Davis
Fine, good to know (I don't have years of experience with jack devel -
be gentle :)

Is it in the refman, chapter

2.4 Transport Control

void jack_transport_start (jack_client_t *client);
void jack_transport_stop (jack_client_t *client);
...

?

Thanks.

On Fri, Oct 29, 2010 at 6:00 PM, Paul Davis <[hidden email]> wrote:

> On Fri, Oct 29, 2010 at 11:56 AM, philippe <[hidden email]> wrote:
>> just a quick note: aside powermanagement, there exit a need for such a
>> functionality if you want to launch some audio processing when a
>> usb/ieee1394 audio card become available, and stop it when powering it
>> off - without cripling the logfiles with jack errors. - I'm using
>> jack2 on a mac and writing a tiny firewire watcher for this particular
>> purpose.
>
> this is what the JACK Control API is designed for. it includes calls
> to change the backend used by a running instance of JACK.
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

torbenh
In reply to this post by Fons Adriaensen-2
On Fri, Oct 29, 2010 at 06:17:06PM +0200, [hidden email] wrote:

> On Fri, Oct 29, 2010 at 05:31:32PM +0200, torbenh wrote:
>
> > i dont think it would be bad to just have some ifdeffed dbus code for
> > this use-case. (notice that we just listen for 2 signals on the SYSTEM
> > bus. not the session bus). i actually think that more than 50% of fonss
> > systems have a system bus ;D
>
> None of them actually. Unless I run avahi and that is used only for
> network printing and started along with cups only when required.
> And recently hal has gone as well (since Xorg doesn't require it
> anymore).

ok. was a joke anyways ;)
do your systems handle suspend to ram or something ?
i would be interested how the very basic layer works.

although using scripts running root to control stuff for some users, is
not really elegant.


>
> Ciao,
>
> --
> FA
>
> There are three of them, and Alleline.
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Fons Adriaensen-2
On Fri, Oct 29, 2010 at 06:33:48PM +0200, torbenh wrote:

> do your systems handle suspend to ram or something ?
> i would be interested how the very basic layer works.

There are two laptops and two EEEs in the collection of
systems I'm admin for, none of those is configured for
suspend or hibernate. There just never was any need for
it. So I can't help you...

AFAIK, at least on Archlinux everything is controlled
by scripts triggered by acpi events, so things can be
added there if necessary.


Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Arnold Krille-3
On Friday 29 October 2010 19:44:45 [hidden email] wrote:

> On Fri, Oct 29, 2010 at 06:33:48PM +0200, torbenh wrote:
> > do your systems handle suspend to ram or something ?
> > i would be interested how the very basic layer works.
>
> There are two laptops and two EEEs in the collection of
> systems I'm admin for, none of those is configured for
> suspend or hibernate. There just never was any need for
> it. So I can't help you...
>
> AFAIK, at least on Archlinux everything is controlled
> by scripts triggered by acpi events, so things can be
> added there if necessary.
Here its the same. Even though I am running a big evil DE and dbus, I stopped
all their powermanagement because it became a burden (turning the backlight up
to max every 20secs because the machine is on AC doesn't go well with me
reading late in the night). Now the powersaving is controlled by laptop-mode
and acpi.

If you enrich jack with suspend/resume abilities, also create text tools to be
run by acpid/laptop-mode/fons and not depending on dbus/powerdevil/etc...

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

torbenh
On Fri, Oct 29, 2010 at 08:41:54PM +0200, Arnold Krille wrote:

> On Friday 29 October 2010 19:44:45 [hidden email] wrote:
> > On Fri, Oct 29, 2010 at 06:33:48PM +0200, torbenh wrote:
> > > do your systems handle suspend to ram or something ?
> > > i would be interested how the very basic layer works.
> >
> > There are two laptops and two EEEs in the collection of
> > systems I'm admin for, none of those is configured for
> > suspend or hibernate. There just never was any need for
> > it. So I can't help you...
> >
> > AFAIK, at least on Archlinux everything is controlled
> > by scripts triggered by acpi events, so things can be
> > added there if necessary.
>
> Here its the same. Even though I am running a big evil DE and dbus, I stopped
> all their powermanagement because it became a burden (turning the backlight up
> to max every 20secs because the machine is on AC doesn't go well with me
> reading late in the night). Now the powersaving is controlled by laptop-mode
> and acpi.
>
> If you enrich jack with suspend/resume abilities, also create text tools to be
> run by acpid/laptop-mode/fons and not depending on dbus/powerdevil/etc...
ok. i added servername option and setuid ability to the jack_suspend
command.
i wrote a script which uses knowledge about jackds /dev/shm layout to
enumerate all running jackd.

dropped this into /usr/lib/pm-utils/sleep.d/
and my jackd suspends nicely now.

>
> Have fun,
>
> Arnold



> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


--
torben Hohn

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

60jackd (488 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Fons Adriaensen-2
In reply to this post by Arnold Krille-3
On Fri, Oct 29, 2010 at 08:41:54PM +0200, Arnold Krille wrote:

> If you enrich jack with suspend/resume abilities, also create text tools to be
> run by acpid/laptop-mode/fons and not depending on dbus/powerdevil/etc...

The most unixy way of making jackd suspend would be to send it
some signal. Or make it listen on some dedicated socket, or use
one of its existing ones.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Paul Davis
On Fri, Oct 29, 2010 at 7:25 PM,  <[hidden email]> wrote:
> On Fri, Oct 29, 2010 at 08:41:54PM +0200, Arnold Krille wrote:
>
>> If you enrich jack with suspend/resume abilities, also create text tools to be
>> run by acpid/laptop-mode/fons and not depending on dbus/powerdevil/etc...
>
> The most unixy way of making jackd suspend would be to send it
> some signal. Or make it listen on some dedicated socket, or use
> one of its existing ones.

and since the most JACK-y way of doing it involves sending it a server
RPC via a existing socket, that's the one in use at present.

btw, using signals for this sort of purpose got severely deprecated in
most unix development shops as soon as threads got widespread and
people realized there was no clear semantic for delivery signals to
multithreaded apps. its true that you can do it very carefully with
sigwait() and sigmask_t's, but even so ... ugh.

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Fons Adriaensen-2
On Fri, Oct 29, 2010 at 09:00:44PM -0400, Paul Davis wrote:

> btw, using signals for this sort of purpose got severely deprecated in
> most unix development shops as soon as threads got widespread and
> people realized there was no clear semantic for delivery signals to
> multithreaded apps. its true that you can do it very carefully with
> sigwait() and sigmask_t's, but even so ... ugh.

I've seen this mentioned in several places, but it's not clear to
me ATM what is the real problem. Maybe you could explain it...

If all the signal handler does is to set some global flag (and
it isn't allowed to do much more)  does it  matter which thread
was interrupted to do that ?

There is a problem if a signal is delivered to a blocked thread
or one that won't run for some time, and 'being delivered' means
that the execution of the signal handler in some way depends on
some state associated with that thread, which then could mean
that running the signal handler could be delayed for any time.

But why should the system ever do that ? In other words why
should there be per-thread signal masks at all ? It could have
some meaning if you know that only a single thread is running
at a time. But it's useless in an multiprocessing context.

The whole point of signals is that they are 'interrupts', and
their execution should not depend on the current context. If
the code in a signal handler can't make assumptions on which
thread is runnning when that code is called, doesn't that mean
also that it doesn't matter ?

I must be missing something here...

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

philippe-62
In reply to this post by torbenh
Hallo Torben,

I'm impressed by the suspend behaviour, using the jackosx 0.87
packaging on 10.5 with a motu 828 mk3, not a glitch, the sound drop
and come back, nothing in the log files but I suspect later jackosx
does not log as much in syslog like 6 months or so (at jackosx 0.85
time).

On Fri, Oct 29, 2010 at 6:15 PM, torbenh <[hidden email]> wrote:

> On Fri, Oct 29, 2010 at 05:56:07PM +0200, philippe wrote:
>> just a quick note: aside powermanagement, there exit a need for such a
>> functionality if you want to launch some audio processing when a
>> usb/ieee1394 audio card become available, and stop it when powering it
>> off - without cripling the logfiles with jack errors. - I'm using
>> jack2 on a mac and writing a tiny firewire watcher for this particular
>> purpose.
>
> hmm... i think this is not totally related.
> first of all the backend needs a way to shutdown properly if a removable
> card is pulled.
> in this case jack2 should automatically backend switch to dummy or
> something. i dont know whether its possible to switch jack to another
> backend, after this happened on osx.
>
> but i want to stress that unplugging of hardware is something which
> surely needs to be considered, but its not the general case.
> the general case, is just that the device gets power cycled, and we just
> need to handle clock skews and such by open/closing the backend.
>
>
> since your on osx, could you check the suspend behaviour ?
> maybe coreaudio is able to handle this in a transparent way ?
>

...

> torben Hohn
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

philippe-62
sometime on wake up, some frames lost (rel. clean blanks) before
getting in sync again and this in the logs:

30.10.10 18:17:44 [0x0-0x20020].gpl.elementicaotici.JackPilot[379]
Notice JackCoreAudioDriver::DeviceNotificationCallback
kAudioDeviceProcessorOverload
30.10.10 18:17:44 [0x0-0x20020].gpl.elementicaotici.JackPilot[379]
Notice JackCoreAudioDriver::DeviceNotificationCallback
kAudioDeviceProcessorOverload

On Sat, Oct 30, 2010 at 6:17 PM, philippe <[hidden email]> wrote:

> Hallo Torben,
>
> I'm impressed by the suspend behaviour, using the jackosx 0.87
> packaging on 10.5 with a motu 828 mk3, not a glitch, the sound drop
> and come back, nothing in the log files but I suspect later jackosx
> does not log as much in syslog like 6 months or so (at jackosx 0.85
> time).
>
> On Fri, Oct 29, 2010 at 6:15 PM, torbenh <[hidden email]> wrote:
>> On Fri, Oct 29, 2010 at 05:56:07PM +0200, philippe wrote:
>>> just a quick note: aside powermanagement, there exit a need for such a
>>> functionality if you want to launch some audio processing when a
>>> usb/ieee1394 audio card become available, and stop it when powering it
>>> off - without cripling the logfiles with jack errors. - I'm using
>>> jack2 on a mac and writing a tiny firewire watcher for this particular
>>> purpose.
>>
>> hmm... i think this is not totally related.
>> first of all the backend needs a way to shutdown properly if a removable
>> card is pulled.
>> in this case jack2 should automatically backend switch to dummy or
>> something. i dont know whether its possible to switch jack to another
>> backend, after this happened on osx.
>>
>> but i want to stress that unplugging of hardware is something which
>> surely needs to be considered, but its not the general case.
>> the general case, is just that the device gets power cycled, and we just
>> need to handle clock skews and such by open/closing the backend.
>>
>>
>> since your on osx, could you check the suspend behaviour ?
>> maybe coreaudio is able to handle this in a transparent way ?
>>
>
> ...
>
>> torben Hohn
>> _______________________________________________
>> Jack-Devel mailing list
>> [hidden email]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Stéphane Letz
In reply to this post by philippe-62
Excellent ((-:  

"it just works TM" !!

Jack2 does (so JackOSX 0.87..) *not* have any suspend/resume system at all, but yes CoreAudio layer seems to do what is needed.

Nothing needs to be done on OSX, but this does not mean that nothing has to be done in JACK server in general.

Stéphane


Le 30 oct. 2010 à 18:17, philippe a écrit :

> Hallo Torben,
>
> I'm impressed by the suspend behaviour, using the jackosx 0.87
> packaging on 10.5 with a motu 828 mk3, not a glitch, the sound drop
> and come back, nothing in the log files but I suspect later jackosx
> does not log as much in syslog like 6 months or so (at jackosx 0.85
> time).
>
> On Fri, Oct 29, 2010 at 6:15 PM, torbenh <[hidden email]> wrote:
>> On Fri, Oct 29, 2010 at 05:56:07PM +0200, philippe wrote:
>>> just a quick note: aside powermanagement, there exit a need for such a
>>> functionality if you want to launch some audio processing when a
>>> usb/ieee1394 audio card become available, and stop it when powering it
>>> off - without cripling the logfiles with jack errors. - I'm using
>>> jack2 on a mac and writing a tiny firewire watcher for this particular
>>> purpose.
>>
>> hmm... i think this is not totally related.
>> first of all the backend needs a way to shutdown properly if a removable
>> card is pulled.
>> in this case jack2 should automatically backend switch to dummy or
>> something. i dont know whether its possible to switch jack to another
>> backend, after this happened on osx.
>>
>> but i want to stress that unplugging of hardware is something which
>> surely needs to be considered, but its not the general case.
>> the general case, is just that the device gets power cycled, and we just
>> need to handle clock skews and such by open/closing the backend.
>>
>>
>> since your on osx, could you check the suspend behaviour ?
>> maybe coreaudio is able to handle this in a transparent way ?
>>
>
> ...
>
>> torben Hohn
>> _______________________________________________
>> Jack-Devel mailing list
>> [hidden email]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack and powermanagement ... wrapping it up.

Stéphane Letz
In reply to this post by philippe-62
Yes, CoreAudio driver restart/resynch itself and the kAudioDeviceProcessorOverload event is notified.

Nothing can be done to improve that AFAICS.

Stéphane


Le 30 oct. 2010 à 18:20, philippe a écrit :

> sometime on wake up, some frames lost (rel. clean blanks) before
> getting in sync again and this in the logs:
>
> 30.10.10 18:17:44 [0x0-0x20020].gpl.elementicaotici.JackPilot[379]
> Notice JackCoreAudioDriver::DeviceNotificationCallback
> kAudioDeviceProcessorOverload
> 30.10.10 18:17:44 [0x0-0x20020].gpl.elementicaotici.JackPilot[379]
> Notice JackCoreAudioDriver::DeviceNotificationCallback
> kAudioDeviceProcessorOverload
>
> On Sat, Oct 30, 2010 at 6:17 PM, philippe <[hidden email]> wrote:
>> Hallo Torben,
>>
>> I'm impressed by the suspend behaviour, using the jackosx 0.87
>> packaging on 10.5 with a motu 828 mk3, not a glitch, the sound drop
>> and come back, nothing in the log files but I suspect later jackosx
>> does not log as much in syslog like 6 months or so (at jackosx 0.85
>> time).
>>
>> On Fri, Oct 29, 2010 at 6:15 PM, torbenh <[hidden email]> wrote:
>>> On Fri, Oct 29, 2010 at 05:56:07PM +0200, philippe wrote:
>>>> just a quick note: aside powermanagement, there exit a need for such a
>>>> functionality if you want to launch some audio processing when a
>>>> usb/ieee1394 audio card become available, and stop it when powering it
>>>> off - without cripling the logfiles with jack errors. - I'm using
>>>> jack2 on a mac and writing a tiny firewire watcher for this particular
>>>> purpose.
>>>
>>> hmm... i think this is not totally related.
>>> first of all the backend needs a way to shutdown properly if a removable
>>> card is pulled.
>>> in this case jack2 should automatically backend switch to dummy or
>>> something. i dont know whether its possible to switch jack to another
>>> backend, after this happened on osx.
>>>
>>> but i want to stress that unplugging of hardware is something which
>>> surely needs to be considered, but its not the general case.
>>> the general case, is just that the device gets power cycled, and we just
>>> need to handle clock skews and such by open/closing the backend.
>>>
>>>
>>> since your on osx, could you check the suspend behaviour ?
>>> maybe coreaudio is able to handle this in a transparent way ?
>>>
>>
>> ...
>>
>>> torben Hohn
>>> _______________________________________________
>>> Jack-Devel mailing list
>>> [hidden email]
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>>
>>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org