jackd and powermanagement

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

jackd and powermanagement

torbenh

and again.

for the suspend thing, there are 2 orthogonal problems.

a) how should the suspend resume signal get into jackd engine.

    - only adding some method to control API only helps with jack-dbus.
      and we still need some code in jackdbus to support this.
      and this would mean exclusively using upowerd, i guess.

    - maybe we also want to have support for the people who use the
      pm-utils scripts exclusively ?
      i think it should be a goal to make it work out of the box, only by
      installing the distro package. adi already explained, that dropping
      something into /usr/lib/pm-utils/sleep.d would be the most
      convenient thing for debian.
   

b) what should the engine do.

    - do a backend switch ?

    - just stop/start the driver backend, like with freewheel ?

    - how about clients like alsa_out which are actually connected
      to the real world/timebase. they need to get notified that
      there will be a huge xrun.
      for alsa_out it might suffice to emit a freewheel callback.
      (which makes sense if you define freewheeling as "process_cb
      will be completely detached from realtime")

    - one argument for a backend switch is that there are some
      broken drivers, which need to get unloaded. (i guess it
      depends on how many drivers are actually broken....)

    - the backend switch still does not solve the problem of the
      callback.


--
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: jackd and powermanagement

Arnold Krille-3
On Monday 01 November 2010 17:25:29 torbenh wrote:
>     - one argument for a backend switch is that there are some
>       broken drivers, which need to get unloaded. (i guess it
>       depends on how many drivers are actually broken....)

I know you are talking about backends where the kernel modules are "broken"
and have to be unloaded, but:
There are also cases where suspend-and-resume is really a backend switch,
because the device with its backend is not there anymore on resume. Like
suspending in the studio where firewire is connected and waking up at home
where only a small usb device or the built-in hardware is available...

Maybe the solution could be to switch to a "suspend" backend?

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: jackd and powermanagement

torbenh
On Mon, Nov 01, 2010 at 09:33:49PM +0100, Arnold Krille wrote:

> On Monday 01 November 2010 17:25:29 torbenh wrote:
> >     - one argument for a backend switch is that there are some
> >       broken drivers, which need to get unloaded. (i guess it
> >       depends on how many drivers are actually broken....)
>
> I know you are talking about backends where the kernel modules are "broken"
> and have to be unloaded, but:
> There are also cases where suspend-and-resume is really a backend switch,
> because the device with its backend is not there anymore on resume. Like
> suspending in the studio where firewire is connected and waking up at home
> where only a small usb device or the built-in hardware is available...
>
> Maybe the solution could be to switch to a "suspend" backend?

nothing prevents to switch to another backend after the resume failed.
i am aware of this case.
however, who decides which backend to activate ?

the os only tells us, that it resumed.
so we would try to activate the old backend anyways, right ?

its not at all clear, how things should be connected when the new
backend gets fired up.



>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: jackd and powermanagement

Fons Adriaensen-2
On Mon, Nov 01, 2010 at 11:53:28PM +0100, torbenh wrote:

> nothing prevents to switch to another backend after the resume failed.
> i am aware of this case.
> however, who decides which backend to activate ?
>
> the os only tells us, that it resumed.

Normally it doesn't. Suspend/resume is supposed to be transparent
to apps, and jackd is just an app like all others.

> so we would try to activate the old backend anyways, right ?

Assuming nothing was done explicitly to anticipate the suspend,
the old backend will still be there - you're not supposed to do
anything at all. Then it depends on what this backend was if it
will still work. If it's for an internal soundcard it probably
will (and anyway it's not our problem to ensure that - the ALSA
devs have to take care of this).

In the other case (external device, USB or firewire), you really
can't assume *anything* at all. If there's a device it could be
a different one. It may not have the same number of channels. It
may not support the old period size, sample rate, etc. And anyway,
if it is not the same device as before the suspend, you have no
reason to assume it should be used at all. Even less if it's not
the only one available. Trying to go on makes sense only if you
find exactly the same device.

So there seem to be two solutions:

- make sure all backends fail gracefully when their audio device
  disappears without warning (which will happen on resume), or

- *if* you get advised about the imminent suspend, switch to a
  dummy backend, remember the old one, and set a 'suspended' flag.
  On resume, you'll find the 'suspended' flag set. Then either try
  to re-activate the old backend and device, or stay with the dummy
  one and let the user resolve the issue. The latter seems to be the
  safer option.

> its not at all clear, how things should be connected when the new
> backend gets fired up.

Indeed. Note that any initiative to re-connect depends on you being
aware of the suspend/resume cycle - there is no 'reason' to do it
otherwise. The safest approach in that case would be *not* to connect
at all, unless you can restart the backend for the original device.

If you were not aware of the suspend, then the old backend and and
connections will (should) still exist. Then the backend may fail,
and you need some way to handle that.

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: jackd and powermanagement

torbenh
On Tue, Nov 02, 2010 at 12:28:40AM +0100, [hidden email] wrote:

> On Mon, Nov 01, 2010 at 11:53:28PM +0100, torbenh wrote:
>
> > nothing prevents to switch to another backend after the resume failed.
> > i am aware of this case.
> > however, who decides which backend to activate ?
> >
> > the os only tells us, that it resumed.
>
> Normally it doesn't. Suspend/resume is supposed to be transparent
> to apps, and jackd is just an app like all others.

it not really transparent, but it looks like a special xrun.
so what happens on my system with jack1 svn now, is that an xrun
is reported.

this is for the alsa driver.
i hope i can fix the jack1 dummy, which gets severely confused by the
clock skew.
but thats probably because it doesnt properly recover from an xrun.


>
> > so we would try to activate the old backend anyways, right ?
>
> Assuming nothing was done explicitly to anticipate the suspend,
> the old backend will still be there - you're not supposed to do
> anything at all. Then it depends on what this backend was if it
> will still work. If it's for an internal soundcard it probably
> will (and anyway it's not our problem to ensure that - the ALSA
> devs have to take care of this).
>
> In the other case (external device, USB or firewire), you really
> can't assume *anything* at all. If there's a device it could be
> a different one. It may not have the same number of channels. It
> may not support the old period size, sample rate, etc. And anyway,
> if it is not the same device as before the suspend, you have no
> reason to assume it should be used at all. Even less if it's not
> the only one available. Trying to go on makes sense only if you
> find exactly the same device.
>
> So there seem to be two solutions:
>
> - make sure all backends fail gracefully when their audio device
>   disappears without warning (which will happen on resume), or

i can not test the ffado stuff.
would be nice if some ffado people at least gathered facts, of what
happens, if
a) you unplug your device.
b) suspend2RAM ?
c) both.

>
> - *if* you get advised about the imminent suspend, switch to a
>   dummy backend, remember the old one, and set a 'suspended' flag.
>   On resume, you'll find the 'suspended' flag set. Then either try
>   to re-activate the old backend and device, or stay with the dummy
>   one and let the user resolve the issue. The latter seems to be the
>   safer option.

if i shut down the alsa backend, and reopen it after a suspend.
"hw:0" might be a different device. this conflicts with your requirement
of never doing (potentially wrong) connections.

in case i just left the pcm in prepared state, it would still be the
same device, for sure.


>
> > its not at all clear, how things should be connected when the new
> > backend gets fired up.
>
> Indeed. Note that any initiative to re-connect depends on you being
> aware of the suspend/resume cycle - there is no 'reason' to do it
> otherwise. The safest approach in that case would be *not* to connect
> at all, unless you can restart the backend for the original device.
>
> If you were not aware of the suspend, then the old backend and and
> connections will (should) still exist. Then the backend may fail,
> and you need some way to handle that.

yeah. this seems sensible.
now we just need a way to switch backend with jack1 :)


>
> 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: jackd and powermanagement

philippe-62
On Tue, Nov 2, 2010 at 2:32 PM, torbenh <[hidden email]> wrote:
> On Tue, Nov 02, 2010 at 12:28:40AM +0100, [hidden email] wrote:
>> On Mon, Nov 01, 2010 at 11:53:28PM +0100, torbenh wrote:
...
>> > so we would try to activate the old backend anyways, right ?
...

>> In the other case (external device, USB or firewire), you really
>> can't assume *anything* at all. If there's a device it could be
>> a different one. It may not have the same number of channels. It
>> may not support the old period size, sample rate, etc. And anyway,
>> if it is not the same device as before the suspend, you have no
>> reason to assume it should be used at all. Even less if it's not
>> the only one available. Trying to go on makes sense only if you
>> find exactly the same device.
>>
>> So there seem to be two solutions:
>>
>> - make sure all backends fail gracefully when their audio device
>>   disappears without warning (which will happen on resume), or
...
>>
>> - *if* you get advised about the imminent suspend, switch to a
>>   dummy backend, remember the old one, and set a 'suspended' flag.
>>   On resume, you'll find the 'suspended' flag set. Then either try
>>   to re-activate the old backend and device, or stay with the dummy

I second that, for the suspend+unplug case, only test the last used
backend, others scénari tend to complicate the issue a lot.

>>   one and let the user resolve the issue. The latter seems to be the
>>   safer option.
_______________________________________________
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: jackd and powermanagement

Paul Davis
In reply to this post by Fons Adriaensen-2
On Mon, Nov 1, 2010 at 7:28 PM,  <[hidden email]> wrote:

> On Mon, Nov 01, 2010 at 11:53:28PM +0100, torbenh wrote:
>
>> nothing prevents to switch to another backend after the resume failed.
>> i am aware of this case.
>> however, who decides which backend to activate ?
>>
>> the os only tells us, that it resumed.
>
> Normally it doesn't. Suspend/resume is supposed to be transparent
> to apps, and jackd is just an app like all others.

not really. any app that is tracking time is going to notice
suspend/resume. i think torben's work is mostly trying to make sure
that JACK doesn't "freak out" when it notices the huge jump in real
world time.
_______________________________________________
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: jackd and powermanagement

torbenh
On Tue, Nov 02, 2010 at 10:56:19AM -0400, Paul Davis wrote:

> On Mon, Nov 1, 2010 at 7:28 PM,  <[hidden email]> wrote:
> > On Mon, Nov 01, 2010 at 11:53:28PM +0100, torbenh wrote:
> >
> >> nothing prevents to switch to another backend after the resume failed.
> >> i am aware of this case.
> >> however, who decides which backend to activate ?
> >>
> >> the os only tells us, that it resumed.
> >
> > Normally it doesn't. Suspend/resume is supposed to be transparent
> > to apps, and jackd is just an app like all others.
>
> not really. any app that is tracking time is going to notice
> suspend/resume. i think torben's work is mostly trying to make sure
> that JACK doesn't "freak out" when it notices the huge jump in real
> world time.

indeed. i am actually still not sure, why jack1-svn survives a suspend
nicely now, but it actually does :)


> _______________________________________________
> 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: jackd and powermanagement

Adrian Knoth
In reply to this post by torbenh
On Tue, Nov 02, 2010 at 02:32:17PM +0100, torbenh wrote:

> > - make sure all backends fail gracefully when their audio device
> >   disappears without warning (which will happen on resume), or
>
> i can not test the ffado stuff.
> would be nice if some ffado people at least gathered facts, of what
> happens, if
> a) you unplug your device.

Here is what happens on jackd1. On jackd2, basically the same thing
happens, but the machine more or less locks up.

The jackd2 behaviour is http://trac.jackaudio.org/ticket/185 and
http://subversion.ffado.org/ticket/264 which also links to
http://subversion.ffado.org/ticket/304

I haven't looked closer yet why jackd1 cleanly terminates but jackd2 got
stuck. If need be, we could tweak FFADO.

Anyway, here's the log:

00236365459: Error (IsoHandlerManager.cpp)[1350] iterate: IsoHandler
(0xb2a02a98): Failed to iterate handler: No such device
00236365476: Error (IsoHandlerManager.cpp)[1350] iterate: IsoHandler
(0xb2a02a98): Failed to iterate handler: No such device
00236365485: Fatal (IsoHandlerManager.cpp)[ 338] Execute: (0x8dd4240,
Transmit) Handler died: now: AD78F1E2, last: A978F190, diff: 49152082
(max: 49152000)
00236365496: Warning (StreamProcessor.cpp)[ 126] handlerDied: Handler
died for 0xb2a025f8
00237747441: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747463: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747471: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747479: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747485: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747491: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747498: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747505: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747515: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747523: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747532: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747537: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747545: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747553: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747559: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747566: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747575: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747581: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747588: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747597: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747603: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747610: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747618: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747624: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747631: Error (IsoHandlerManager.cpp)[1862] requestEnable: Enable
requested on stream 'Transmit' with state: 2
00237747640: Error (StreamProcessor.cpp)[1173] scheduleStartDryRunning:
Could not start handler for SP 0xb2a025f8
00237747646: Error (StreamProcessorManager.cpp)[ 408] startDryRunning:
Could not put 'Transmit' SP 0xb2a025f8 into the dry-running state
00237747671: Fatal (StreamProcessorManager.cpp)[1100] handleXrun: Could
not syncStartAll...
00237747677: Error (devicemanager.cpp)[ 999] waitForPeriod: Could not
handle XRUN
00237747683: Error (ffado.cpp)[ 264] ffado_streaming_wait: Error
condition while waiting (Unhandled XRUN)
firewire ERR: wait status < 0! (= -1)
DRIVER NT: could not run driver cycle
00237748037: Error (dice_avdevice.cpp)[1789] writeReg: Could not write
to node 0xFFC1 addr 0xFFFFE0000078
00237748048: Warning (devicemanager.cpp)[ 950] stopStreamingOnDevice:
Could not disable streaming on device 0xb2a01710!
00237748060: Error (dice_avdevice.cpp)[1764] readReg: Could not read
from node 0xFFC1 addr 0xFFFFE0000078
00237748069: Error (dice_avdevice.cpp)[1421] stopStreamByIndex: Cannot
stop streams while streaming is enabled
00237748075: Warning (devicemanager.cpp)[ 959] stopStreamingOnDevice:
Could not stop stream 0 of device 0xb2a01710
00237748083: Error (dice_avdevice.cpp)[1764] readReg: Could not read
from node 0xFFC1 addr 0xFFFFE0000078
00237748093: Error (dice_avdevice.cpp)[1421] stopStreamByIndex: Cannot
stop streams while streaming is enabled
00237748098: Warning (devicemanager.cpp)[ 959] stopStreamingOnDevice:
Could not stop stream 1 of device 0xb2a01710
00237748106: Error (dice_avdevice.cpp)[1764] readReg: Could not read
from node 0xFFC1 addr 0xFFFFE0000078
00237748115: Error (dice_avdevice.cpp)[1421] stopStreamByIndex: Cannot
stop streams while streaming is enabled
00237748120: Warning (devicemanager.cpp)[ 959] stopStreamingOnDevice:
Could not stop stream 2 of device 0xb2a01710
00237748163: Error (ieee1394service.cpp)[ 676] lockCompareSwap64:
raw1394_lock64 failed: No such device
00237748173: Warning (dice_avdevice.cpp)[1197] unlock: Could not
unregister ourselves as device owner
00237748179: Warning (devicemanager.cpp)[ 844] finishStreaming: Could
not unlock device (0xb2a01710)!
00237748184: Error (ffado.cpp)[ 201] ffado_streaming_finish: Could not
finish the streaming
00237748401: Error (ieee1394service.cpp)[ 676] lockCompareSwap64:
raw1394_lock64 failed: No such device
00237748411: Warning (dice_avdevice.cpp)[1197] unlock: Could not
unregister ourselves as device owner
00237754281: Error (ieee1394service.cpp)[ 128] ~Ieee1394Service:  Failed
to unregister ARM handler for 0x0000FFFFE0000000
00237754298: Error (ieee1394service.cpp)[ 129] ~Ieee1394Service:  Error:
Bad file descriptor
jack main caught signal 12
no message buffer overruns


> b) suspend2RAM ?

Haven't tested, yet. If nobody is faster, I could try it tomorrow or
later tonight. But I guess we'll see a firewire bus reset, and FFADO is
known to not survive it.



HTH

PS: CC ffado-devel, so other ffado devs might provide more insight.

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
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: jackd and powermanagement

torbenh
On Tue, Nov 02, 2010 at 05:52:13PM +0100, Adrian Knoth wrote:

> On Tue, Nov 02, 2010 at 02:32:17PM +0100, torbenh wrote:
>
> > > - make sure all backends fail gracefully when their audio device
> > >   disappears without warning (which will happen on resume), or
> >
> > i can not test the ffado stuff.
> > would be nice if some ffado people at least gathered facts, of what
> > happens, if
> > a) you unplug your device.
>
> Here is what happens on jackd1. On jackd2, basically the same thing
> happens, but the machine more or less locks up.
>
> The jackd2 behaviour is http://trac.jackaudio.org/ticket/185 and
> http://subversion.ffado.org/ticket/264 which also links to
> http://subversion.ffado.org/ticket/304
>
> I haven't looked closer yet why jackd1 cleanly terminates but jackd2 got
> stuck. If need be, we could tweak FFADO.

jack1 has a watchdog.


>
> Anyway, here's the log:
> [...]
>
> jack main caught signal 12

^^^ watchdog shoots jackd.

> no message buffer overruns
>
>
> > b) suspend2RAM ?
>
> Haven't tested, yet. If nobody is faster, I could try it tomorrow or
> later tonight. But I guess we'll see a firewire bus reset, and FFADO is
> known to not survive it.

probably.
ffado devs around ?
any chances to fix this ?


--
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: jackd and powermanagement

Stéphane Letz
In reply to this post by Adrian Knoth

Le 2 nov. 2010 à 17:52, Adrian Knoth a écrit :

> On Tue, Nov 02, 2010 at 02:32:17PM +0100, torbenh wrote:
>
>>> - make sure all backends fail gracefully when their audio device
>>>  disappears without warning (which will happen on resume), or
>>
>> i can not test the ffado stuff.
>> would be nice if some ffado people at least gathered facts, of what
>> happens, if
>> a) you unplug your device.
>
> Here is what happens on jackd1. On jackd2, basically the same thing
> happens, but the machine more or less locks up.
>
> The jackd2 behaviour is http://trac.jackaudio.org/ticket/185 and

Basically FFADO repeatedly reports an error (firewire ERR: wait status < 0! (= -1)) that is then reported by JACK2.

And this error is not considered non recoverable since it may possibly happen once in the course of "normal" behaviour.

So my feeling is that the issue if inn FFADO at the first place... ((-:

Stéphane


_______________________________________________
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: jackd and powermanagement

Jonathan Woithe
In reply to this post by torbenh
> On Tue, Nov 02, 2010 at 05:52:13PM +0100, Adrian Knoth wrote:
> > On Tue, Nov 02, 2010 at 02:32:17PM +0100, torbenh wrote:
> > :
> > > b) suspend2RAM ?
> >
> > Haven't tested, yet. If nobody is faster, I could try it tomorrow or
> > later tonight. But I guess we'll see a firewire bus reset, and FFADO is
> > known to not survive it.
>
> probably.
> ffado devs around ?

Yes. :-)

> any chances to fix this ?

If by "this" you mean the handling of bus resets, I'm not sure.  Pieter's
been the main author of that low level code.  I recall there was some talk
of making ffado more resilient in the face of bus resets but I don't know
what the current state of play is.  I personally haven't tested the ffado
behaviour after a bus reset for many months.  Perhaps I should - maybe it's
better now.

Earlier in the thread Paul Davis wrote:
> not really. any app that is tracking time is going to notice
> suspend/resume. i think torben's work is mostly trying to make sure
> that JACK doesn't "freak out" when it notices the huge jump in real
> world time.

The problem for firewire devices is that they themselves will not be
suspended by the system in the way internal cards are, so unless ffado gets
forward notice of an impending suspend the devices will not be explicitly
put into a sane state for the duration of the suspend.  For some devices
this won't matter, but there are interfaces out there which will get
horribly upset if the incoming data stream just stops (to the point of
putting high-pitched tones into random output channels at moderate volume).

Certainly jackd and/or ffado can infer the occurance of a suspend at resume
time by observing the time discontinuity.  However, as noted above this is
only useful for allowing a resumption of activity; it doesn't allow the
system to prepare the interface for the suspension of playback data
before the suspend.

So even if jackd itself doesn't end up listening for impending suspend
messages (assuming that's even possible), ffado will probably need to if one
wishes to ensure that ffado-controlled interfaces are put into an inactive
state before the system suspends.

Regards
  jonathan
_______________________________________________
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: jackd and powermanagement

torbenh
On Wed, Nov 03, 2010 at 11:30:59AM +1030, Jonathan Woithe wrote:

> > On Tue, Nov 02, 2010 at 05:52:13PM +0100, Adrian Knoth wrote:
> > > On Tue, Nov 02, 2010 at 02:32:17PM +0100, torbenh wrote:
> > > :
> > > > b) suspend2RAM ?
> > >
> > > Haven't tested, yet. If nobody is faster, I could try it tomorrow or
> > > later tonight. But I guess we'll see a firewire bus reset, and FFADO is
> > > known to not survive it.
> >
> > probably.
> > ffado devs around ?
>
> Yes. :-)
>
> > any chances to fix this ?
>
> If by "this" you mean the handling of bus resets, I'm not sure.  Pieter's
> been the main author of that low level code.  I recall there was some talk
> of making ffado more resilient in the face of bus resets but I don't know
> what the current state of play is.  I personally haven't tested the ffado
> behaviour after a bus reset for many months.  Perhaps I should - maybe it's
> better now.

what does a bus reset mean ?
are the devices in defined state after that ?

>
> Earlier in the thread Paul Davis wrote:
> > not really. any app that is tracking time is going to notice
> > suspend/resume. i think torben's work is mostly trying to make sure
> > that JACK doesn't "freak out" when it notices the huge jump in real
> > world time.
>
> The problem for firewire devices is that they themselves will not be
> suspended by the system in the way internal cards are, so unless ffado gets
> forward notice of an impending suspend the devices will not be explicitly
> put into a sane state for the duration of the suspend.  For some devices
> this won't matter, but there are interfaces out there which will get
> horribly upset if the incoming data stream just stops (to the point of
> putting high-pitched tones into random output channels at moderate volume).

i am assuming, that a bus reset silences them.
when the system has resumed, the ohci will freshly powered up, and the
old raw1394 sockets will probably be in a totally invalid state.



if you can detect this, you just need to make sure that a
driver_stop () ... driver_start () will succed.

(under the assumption, you find the same card on the bus again)


>
> Certainly jackd and/or ffado can infer the occurance of a suspend at resume
> time by observing the time discontinuity.  However, as noted above this is
> only useful for allowing a resumption of activity; it doesn't allow the
> system to prepare the interface for the suspension of playback data
> before the suspend.
>
> So even if jackd itself doesn't end up listening for impending suspend
> messages (assuming that's even possible), ffado will probably need to if one
> wishes to ensure that ffado-controlled interfaces are put into an inactive
> state before the system suspends.
>
> Regards
>   jonathan
> _______________________________________________
> 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: jackd and powermanagement

Jonathan Woithe
> > > On Tue, Nov 02, 2010 at 05:52:13PM +0100, Adrian Knoth wrote:
> > > > > b) suspend2RAM ?
> > > >
> > > > Haven't tested, yet. If nobody is faster, I could try it tomorrow or
> > > > later tonight. But I guess we'll see a firewire bus reset, and FFADO is
> > > > known to not survive it.
> > >
> > > probably.
> > > ffado devs around ?
> >
> > Yes. :-)
> >
> > > any chances to fix this ?
> >
> > If by "this" you mean the handling of bus resets, I'm not sure.  Pieter's
> > been the main author of that low level code.  I recall there was some talk
> > of making ffado more resilient in the face of bus resets but I don't know
> > what the current state of play is.  I personally haven't tested the ffado
> > behaviour after a bus reset for many months.  Perhaps I should - maybe it's
> > better now.
>
> what does a bus reset mean ?

It occurs on the firewire bus whenever the bus topography changes (among
other things).  So if a new device appears or an existing device disappears
a bus reset is triggered.  This forces the bus to rediscover available nodes
and the nodes also must renegotiate their access to the bus.  So if for
example one has an audio interface which is streaming data before the bus
reset it (or more likely the PC) must have requested and been granted
various bus resources to allow for this data flow.  After the bus reset
these resources must be requested from scratch before streaming can be
resumed.

> are the devices in defined state after that ?

I think that will probably depend very much on the device in question.  I'll
have to test this and get back to you about how the devices I have behave.
From my dim memory of the standard I don't think a bus reset is required to
return the device as a whole to some known state - it only stipulates that
the firewire bus interface itself returns to some known state.

My expectation is that at least with one particular family of devices a bus
reset during streaming will cause the device to enter its strange state
whereby it emits tones from random outputs until explicitly reinitialised by
the driver software.  I'll try to test this soon.

> > Earlier in the thread Paul Davis wrote:
> > > not really. any app that is tracking time is going to notice
> > > suspend/resume. i think torben's work is mostly trying to make sure
> > > that JACK doesn't "freak out" when it notices the huge jump in real
> > > world time.
> >
> > The problem for firewire devices is that they themselves will not be
> > suspended by the system in the way internal cards are, so unless ffado gets
> > forward notice of an impending suspend the devices will not be explicitly
> > put into a sane state for the duration of the suspend.  For some devices
> > this won't matter, but there are interfaces out there which will get
> > horribly upset if the incoming data stream just stops (to the point of
> > putting high-pitched tones into random output channels at moderate volume).
>
> i am assuming, that a bus reset silences them.

Unfortunately, based on my previous experience with some of these devices,
this can't be assured of happening in all cases (although I agree that from
a device design point of view it would be the most sensible approach).  The
best way to tell, however, is to explicitly test it which I will try to do
in the next day or so.

> when the system has resumed, the ohci will freshly powered up, and the
> old raw1394 sockets will probably be in a totally invalid state.

One would expect so, yes.

> if you can detect this, you just need to make sure that a
> driver_stop () ... driver_start () will succed.

True.  The question is whether this can be unambiguously detected in
userspace.  I don't know enough about raw1394 to tell right now - I'll have
to do some reading and experimentation I think.

Regards
  jonathan
_______________________________________________
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: jackd and powermanagement

Jonathan Woithe
In reply to this post by torbenh
Hi Torben

Following up on an earlier question of yours:
> are the devices in defined state after that ?
> :
> i am assuming, that a bus reset silences them.

I've now explicitly tested my firewire interface for this and it seems that
the device does behave in a moderately sane manner if a bus reset occurs
while streaming is underway.  I say "moderately" sane because while audio
output stops immediately a bus reset occurs, the device is in a slightly
unpredictable state; when a streaming restart is requested sometime later
(assuming the interface has not been power cycled) the audio output over the
first second or so is corrupt.  This is the typical behaviour of these
interfaces if streaming isn't shut down properly - it's not particular to
bus resets.

Therefore the ideal situation is for the ffado backend to be informed when
suspend is about to happen so it can properly prepare the device for the
interruption of streaming.  This will then allow the interface to come up
cleanly again after the suspend regardless of whether it's been power
cycled.  I say "ideal" here because I'm aware that such a notification may
not be possible for technical reasons as discussed elsewhere in this thread;
if it can't be done we'll live with it, although obviously it wouldn't be my
first choice.

Regards
  jonathan
_______________________________________________
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: jackd and powermanagement

torbenh
On Fri, Nov 05, 2010 at 11:04:17PM +1030, Jonathan Woithe wrote:

> Hi Torben
>
> Following up on an earlier question of yours:
> > are the devices in defined state after that ?
> > :
> > i am assuming, that a bus reset silences them.
>
> I've now explicitly tested my firewire interface for this and it seems that
> the device does behave in a moderately sane manner if a bus reset occurs
> while streaming is underway.  I say "moderately" sane because while audio
> output stops immediately a bus reset occurs, the device is in a slightly
> unpredictable state; when a streaming restart is requested sometime later
> (assuming the interface has not been power cycled) the audio output over the
> first second or so is corrupt.  This is the typical behaviour of these
> interfaces if streaming isn't shut down properly - it's not particular to
> bus resets.
>
> Therefore the ideal situation is for the ffado backend to be informed when
> suspend is about to happen so it can properly prepare the device for the
> interruption of streaming.  This will then allow the interface to come up
> cleanly again after the suspend regardless of whether it's been power
> cycled.  I say "ideal" here because I'm aware that such a notification may
> not be possible for technical reasons as discussed elsewhere in this thread;

its not technical reasons. its people not liking it to happen.
my first proposed patch just notifies jackd of the pending suspend.

anyways. for alsa, and in particular my system, i only need proper
suspend management.



> if it can't be done we'll live with it, although obviously it wouldn't be my
> first choice.
>
> Regards
>   jonathan

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