5 Mar
2009
5 Mar
'09
10:02 a.m.
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
sincerely,
Marije
5 Mar
5 Mar
10:07 a.m.
On Thu, Mar 5, 2009 at 9:02 AM, nescivi <nescivi(a)gmail.com> wrote:
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, do
not let your computer sleep, or suspend, or engage in CPU frequency scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
2:18 p.m.
2009/3/5 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
Wouldn't it make sense, to provide a notify for jack (from the
hibernate script),
before the system goes to sleep, so jack could then pause processing
appropriately?
Hibernation is becoming very common and a favored feature.
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, do
not let your computer sleep, or suspend, or engage in CPU frequency scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
6 Mar
6 Mar
5:51 a.m.
Only for mobile machines. I really cannot do without at least frequency
scaling (heat) and sleep (suspend-to-ram; quick access).
8:05 a.m.
On Fri, Mar 6, 2009 at 4:51 AM, Ray Rashif <schivmeister(a)gmail.com> wrote:
Only for mobile machines. I really cannot do without
at least frequency
scaling (heat) and sleep (suspend-to-ram; quick access).
sorry, but you just don't do realtime low latency audio on a machine that
has either of these things happening to it. at least not today.
i agree that a signal to tell JACK to "sleep" when the machine is suspended,
hibernated or whatever would be a good idea. it probably already exists via
d-bus and/or other similar mechanisms on non-linux platforms.
9 Mar
9 Mar
5:37 p.m.
Wouldn't it make sense, to provide a notify for
jack (from the
hibernate script),
before the system goes to sleep, so jack could then pause processing
appropriately?
Hibernation is becoming very common and a favored feature.
On Friday 06 March 2009 07:05:35 Paul Davis wrote:
On Fri, Mar 6, 2009 at 4:51 AM, Ray Rashif
<schivmeister(a)gmail.com> wrote:
Any hints/examples on how to do this?
sincerely,
Marije
Only for mobile machines. I really cannot do
without at least frequency
scaling (heat) and sleep (suspend-to-ram; quick access).
sorry, but you just don't do realtime low latency audio on a machine that
has either of these things happening to it. at least not today.
i agree that a signal to tell JACK to "sleep" when the machine is
suspended, hibernated or whatever would be a good idea. it probably already
exists via d-bus and/or other similar mechanisms on non-linux platforms. 
15 Mar
15 Mar
2:06 a.m.
If you run a graphical Ubuntu desktop system, there is a necessary step to
do "dpkg-reconfigure gnome-applets" and suid root enable the CPU selector...
for older distributions of Ubuntu. Newer Ubuntu distributions have a keyring
managed access to the cpu frequency selection from the cpu frequency applet.
On Mon, Mar 9, 2009 at 2:37 PM, nescivi <nescivi(a)gmail.com> wrote:
already
Wouldn't it make sense, to provide a notify
for jack (from the
hibernate script),
before the system goes to sleep, so jack could then pause processing
appropriately?
Hibernation is becoming very common and a favored feature.
On Friday 06 March 2009 07:05:35 Paul Davis wrote:
On Fri, Mar 6, 2009 at 4:51 AM, Ray Rashif
<schivmeister(a)gmail.com>
wrote:
Only for
mobile machines. I really cannot do without at least frequency
scaling (heat) and sleep (suspend-to-ram; quick access).
sorry, but you just don't do realtime low latency audio on a machine that
has either of these things happening to it. at least not today.
i agree that a signal to tell JACK to "sleep" when the machine is
suspended, hibernated or whatever would be a good idea. it probably exists via d-bus and/or other similar mechanisms
on non-linux platforms.
Any hints/examples on how to do this?
sincerely,
Marije
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
22 Mar
22 Mar
1:10 p.m.
2009/3/9 nescivi <nescivi(a)gmail.com>om>:
Wouldn't it make sense, to provide a notify
for jack (from the
hibernate script),
before the system goes to sleep, so jack could then pause processing
appropriately?
Hibernation is becoming very common and a favored feature.
On Friday 06 March 2009 07:05:35 Paul Davis wrote:
On Fri, Mar 6, 2009 at 4:51 AM, Ray Rashif
<schivmeister(a)gmail.com> wrote:
Only for mobile machines. I really cannot do
without at least frequency
scaling (heat) and sleep (suspend-to-ram; quick access).
sorry, but you just don't do realtime low latency audio on a machine that
has either of these things happening to it. at least not today.
i agree that a signal to tell JACK to "sleep" when the machine is
suspended, hibernated or whatever would be a good idea. it probably already
exists via d-bus and/or other similar mechanisms on non-linux platforms. Any hints/examples on how to do this?
There seem to be different methods/scripts for sleeping available.
A comparision:
http://www.tuxonice.net/features
The freedesktop approach (pm-utils):
http://pm-utils.freedesktop.org/wiki/
More HAL/sleep info:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html
kpowersave seems to use powersave:
http://powersave.sourceforge.net/powersave/Events.html#Events
Here is uwsusp:
http://suspend.sourceforge.net/
I think, one needed to notify jack over dbus
from either a script (in /etc/pm or /etc/powersave)
or from a HAL callback.
Although I could not find any event-hook in the HAL specifications:
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properti…
I think resume doesn't work with jack, because my
usb-card requires 2 seconds to power on itself (over the usb-port).
So jack would have to sleep about 2.2 seconds, before
reenabling audio processing.
--
Emanuel Rumpf
6 Mar
6 Mar
8:01 a.m.
On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
do
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, not let your computer sleep, or suspend, or engage in
CPU frequency
scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
While cpu freq scaling *might* confuse JACK, it seems is not the case here.
Sleep is a whole different story...
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
10:56 a.m.
MarcO'Chapeau wrote:
On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
It's interesting that I haven't had major issues with sleep on my laptop
(running OSX). I didn't expect JACK to survive the first time and was
surprised to see it come back to life with just an xrun or two. More
often than not that's what happens, though it has crashed a few times on
resume. (disclaimer: I don't have JACK going all the time, so the sample
size isn't great. Also, I might have had it in soft mode.)
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
do
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, not let your computer sleep, or suspend, or
engage in CPU frequency
scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
While cpu freq scaling *might* confuse JACK, it seems is not the case here.
Sleep is a whole different story... 
11:08 a.m.
Le 6 mars 09 à 15:56, Hans Fugal a écrit :
MarcO'Chapeau wrote:
There is *nothing* specific done on OSX. I guess the CoreAudio
interrupt just stops and restart when system resume.
Stephane
On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis
<paul(a)linuxaudiosystems.com
wrote:
It's interesting that I haven't had major issues with sleep on my
laptop
(running OSX). I didn't expect JACK to survive the first time and was
surprised to see it come back to life with just an xrun or two. More
often than not that's what happens, though it has crashed a few
times on
resume. (disclaimer: I don't have JACK going all the time, so the
sample
size isn't great. Also, I might have had it in soft mode.)
On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
do
Hiho,
It seems that JACK (just tested with v0.116) does not survive
when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using
JACK, not let your computer sleep, or suspend, or
engage in CPU frequency
scaling.
These all appear to JACK as indistinguishable from your audio
interface
ceasing to function in a way that leads it to quit or die.
Remember that
JACK is watching the passing of absolute time.
While cpu freq scaling *might* confuse JACK, it seems is not the
case here.
Sleep is a whole different story...
11:19 a.m.
I'm managing somehow with an Intel-based laptop. I only stop everything
before suspending, and I never hibernate since it's a PITA (doesn't help
because my bootup time is nearly as fast).
And wait, now that it's mentioned, I remember I also used to have a system
where QJackCtl just appears to have only met xruns after a sleep. Now,
though, it's stopping. And it's not a Mac.
2:58 p.m.
MarcO'Chapeau wrote:
On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
for the record, i have not seen problems due to frequency scaling
either. at least i've switched it off whenever i encountered jack
problems, and it has never made a difference.
On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
do
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, not let your computer sleep, or suspend, or
engage in CPU frequency
scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
While cpu freq scaling *might* confuse JACK, it seems is not the case here.
Sleep is a whole different story... 
4:53 p.m.
On Fri, 2009-03-06 at 19:58 +0100, Jörn Nettingsmeier wrote:
for the record, i have not seen problems due to
frequency scaling
either. at least i've switched it off whenever i encountered jack
problems, and it has never made a difference.
Second previous speaker after - as a result of this discussion -
violently switching low/high clock.
What we can learn is that Jack is possibly vulnerable but we are not
sure of exactly of what?
/j
7:39 p.m.
On Fri, 06 Mar 2009 21:52:55 +0100, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
What we can learn is that Jack is possibly vulnerable
but we are not
sure of exactly of what?
Jack is not vulnerable since it has been created by God. C'mon ! Everybody
knows that...
PS: Paul, this one is free. The next one will only be 100 euros ;)
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
7 Mar
7 Mar
5:14 p.m.
On Fri, 2009-03-06 at 19:58 +0100, Jörn Nettingsmeier wrote:
MarcO'Chapeau wrote:
I find that I always have to turn cpu scaling off when I want to do real
jack audio work - unless it is very light load. Otherwise it is bound to
happen that as load changes the cpu slows down, then the cpu load goes
up, perhaps suddenly, and you get xruns. They quickly go away as the cpu
switches speed again - but by then it is too late.
-- Fernando
On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
for the record, i have not seen problems due to frequency scaling
either. at least i've switched it off whenever i encountered jack
problems, and it has never made a difference. On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
do
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, not let your computer sleep, or suspend, or
engage in CPU frequency
scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
While cpu freq scaling *might* confuse JACK, it seems is not the case here.
Sleep is a whole different story... 
6 Mar
6 Mar
5:49 p.m.
On Fri, Mar 06, 2009 at 01:01:01PM +0100, MarcO'Chapeau wrote:
On Thu, 5 Mar 2009 09:07:10 -0500, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
yup. i still using frequency scaling too, although it is going to fade
away, because, according to some kernel dev, you save more power with a
tickless kernel when cpu is running full speed
however my CPU is hotter then and the fan wouldnt stop, so i still
prefer frequency scaling ondemand governor.
i guess this is due to jack_get_microseconds using hpet timer default.
which shouldnt get hit by frequency changes.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Thu, Mar 5, 2009 at 9:02 AM, nescivi
<nescivi(a)gmail.com> wrote:
do
Hiho,
It seems that JACK (just tested with v0.116) does not survive when the
computer is put to sleep, and woken up again.
Is there any reason why this is so?
JACK will see this as a major system malfunction. If you are using JACK, not let your computer sleep, or suspend, or
engage in CPU frequency
scaling.
These all appear to JACK as indistinguishable from your audio interface
ceasing to function in a way that leads it to quit or die. Remember that
JACK is watching the passing of absolute time.
While cpu freq scaling *might* confuse JACK, it seems is not the case here.
Sleep is a whole different story...
6:21 p.m.
On Fri, Mar 6, 2009 at 4:46 PM, <torbenh(a)gmx.de> wrote:
i guess this is due to jack_get_microseconds using hpet timer default.
which shouldnt get hit by frequency changes.
its true that using the HPET time would/should eliminate all issues with
freq scaling.
how to tell users this?
6:44 p.m.
On Fri, 2009-03-06 at 17:21 -0500, Paul Davis wrote:
its true that using the HPET time would/should eliminate all issues
with freq scaling.
how to tell users this?
I just ticked that option because it kind of sounded incredibly cool.
You say that one really has to know exactly what one is doing?
/j :o)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
7:34 p.m.
On Fri, 06 Mar 2009 23:44:32 +0100, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
On Fri, 2009-03-06 at 17:21 -0500, Paul Davis wrote:
When you say you ticked the option, you mean the kernel one ? Or is there a
JACK one that I haven't seen ?
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
its true that using the HPET time would/should eliminate all issues
with freq scaling.
how to tell users this?
I just ticked that option because it kind of sounded incredibly cool.
You say that one really has to know exactly what one is doing? 
8:41 p.m.
On Fri, 2009-03-06 at 17:21 -0500, Paul Davis wrote:
On Fri, Mar 6, 2009 at 4:46 PM, <torbenh(a)gmx.de> wrote:
i guess this is due to jack_get_microseconds using hpet timer
default.
which shouldnt get hit by frequency changes.
its true that using the HPET time would/should eliminate all issues
with freq scaling.
how to tell users this?
HPET instead of what? TSC? It seems these days the TSC is fraught with
trouble. The Wikipedia article on it is interesting:
http://en.wikipedia.org/wiki/Time_Stamp_Counter
Regards,
Steve.
5753
days inactive
5770
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
13 participants
participants (13)
-
Emanuel Rumpf -
Eric Shattow -
Fernando Lopez-Lezcano -
Hans Fugal -
Jens M Andreasen -
Jörn Nettingsmeier -
MarcO'Chapeau -
nescivi -
Paul Davis -
Ray Rashif -
Steve Fosdick -
Stéphane Letz -
torbenh＠gmx.de