Should suspend to RAM work in general with RME Multiface?

I found out that my Multiface keeps silent after the maching woke up from suspend to RAM. I had to reboot to get it working again. Does this work under certain circumstances or is it a wast of time to continue looking for the root cause of this issue?
BTW: The onboad soundcard works in this way and i did not cut that Multiface from the power supply so the firmware keeps loaded.

Then you’ve got some application using the audio device. Is jack running? Or pulseaudio? Or your web browser?

@Paul: just thinking “outloud”

could there be a server side mechanism that would disconnect all clients from jack ? Ardour can do it from the client side, which is kinda cool since you can shut jack down and keep ardour alive. But what if jack provided some callback API that clients could use in the case I decided that I would disconnect all clients at once ?

The problem to solve would be reconnect everything back when jack comes back to life. How would jack know that a client was there dormant and would like to come back in the graph ? Maybe with some sort of polling mechanism from the client ? I have yet to see what ardour does when we “reconnect” it to JACK. Does ardour go through the client_open, port registration, port connection one more time ?

I don’t know, is it something unrealistic ?

You could even imagine a suspend/resume script that would do this:

  • jack_disconnect_all_clients
  • jack_shutdown : save a lock file to know at resume time that jack was on
  • put PC to sleep
  • resume
  • check lock file. If jack was on, start jack, and jack_reconnect_all_clients

(the latter part - rebuilding the client list - is not obvious to me at first glance).

Is it worth at all ? I am not thinking about my own needs, they are too simple for this. But maybe many ppl would find such requirements (to be defined) useful ?

Or maybe one can make use of the LADI stuff, which would save all the session, close it before suspend, and open it again after resume ?

waste of time, I tried to make it work but gave up and have not tried it since kernel 2.6.24. Unless the driver is updated (or ALSA?), I wouldn’t know how to make the multiface resume nicely from S3. A shame but nowadays, booting up is rather fast. However, even if resuming from S3 worked, how would you keep you jack session ? jack itself is not surviving suspend/resume.

Note to Paul: is this something that is feasible (jackd surviving suspend/resume) ? My machine has either to stay ON or I have to shut things down and restart everything. I can cope with it since my jack sessions are rather simple but this may not be the case for other users.

you can “disconnect/reconnect jack” in ardour and then stop jack, so that you can send computer to sleep.
Rather easier than restarting everything but unfortuantely harder than just shutting the laptop lid.

yeah, if you only have ardour opened, that’s fine. But when I talk about “jack session”, I am talking about at least 2 jack clients (one can be ardour of course).

When I compose, I have the following:

  • at least 3 virtual instruments (one drum VSTi . one linux jack client for piano and one soft synth)
  • rosegarden for MIDI
  • ardour for recording / playing back audio
  • jconv and guitarix for improved guitar sounds

So this little crowd can hardly be saved at once, disconnect from jack and be put to sleep. I consider it a rather simple jack session. Others may have way more stuff with tons of linux samplers, netjack clients, etc, etc.

Of course, I did not expect to have Jack running “while going to sleep”. It would be an advantage to be able to use the sound interface after suspend in the same way like after reboot: Starting jack, starting Ardour, starting … but for me it just does not work at all until I reboot the complete system.

BTW: I can start jack without error message, but there is not sound anyway .

@thorgal: to be honest, i don’t know and speaking personally, i don’t care. i would never allow ACPI to be used on a laptop where i was making music for this very reason. there may be engineering solutions to this, but they will be long and fairly complex, i think. just say no to ACPI in this context and the problem goes away.

@thorgal: there was some discussion of jack2 supporting a “disconnect from the backend” operation, partly to support suspend/resume at the kernel driver level, and partly to allow switching backends. not sure where this work stands at present. if it was done then you could tell jack prior to a suspend (or during it) that it should turn off the backend (stopping the audio interface along the way); it would restart using it when resuming. i have read that the ordering of this can be problematic.

@erdie: Instead of rebooting, open a command line window, become root, and reload the sound card module, eg:

$ sudo -s

rmmod snd_hdsp

modprobe snd_hdsp

I do this whenever my Multiface is misbehaving and it usually does the trick!

I get the message that the module is already in use …

There was an issue with older versions of alsa, where the hdsp driver might trigger a kernel oops - if that’s the case (check with dmesg), maybe you should upgrade.

Of course, if the module is in use by jack, it cannot be rmmod’ed - how should it. But as Paul already stated, you either can either have a low latency machine or you can have a energy saving machine. You don’t want power managment and/or frequency scaling to be active.

I agree, but suspend mode while jack is stopped should be possible since the hdsp hardware is, at the end, a “normal” kind of soundcard. I remember about the same issue with the onboard soundchip with a very old Alsa version. Since a certain alsa version the issue was gone. Therefore it should IMHO work in general. And, of course, before i start jack, i disable all kind of speedstepping and powermanagement, therefore you have normally profiles for that purpose.