No snd_pcm_resume_all() ?

No snd_pcm_resume_all() ?

[Benjamin Herrenschmidt]

Hi !

While tweaking a bit the power management code in Johannes' new snd-aoa
for powermac, I got it to properly suspend & resume playback on
sleep/waekup of the machine. However, an Alsa bit is missing for that to
work and I'd like to understand why.

On suspend, it's fairly simple, we call snd_pcm_suspend_all() to suspend
all streams before we go put the hardware into low power state.

On resume, I would expect to have a similar snd_pcm_resume_all() to call
after I've restored the hardware & codecs state. However... it's not
there. I hacked one up myself (patch below) and it seems to work fine.

It appears that Alsa expects the streams to be resumed via some userland
initiated ioctl, which for some reason is never called on my machine.
What is the rationale there ? it's userland that is expected to
save/restore hardware state ? That doesn't really match the linux PM
model at this point and it seems that Alsa userland isn't notified of
suspend/resume at least on powermacs.

Just adding snd_pcm_resume_all() and calling it at the right time seems
to work fine for us, thus is there any reason why the patch below
couldn't be pushed upstream ?

Cheers,
Ben.

Index: linux-work/sound/core/pcm_native.c
===================================================================
--- linux-work.orig/sound/core/pcm_native.c	2006-04-13 09:58:55.000000000 +1000
+++ linux-work/sound/core/pcm_native.c	2006-04-18 10:34:46.000000000 +1000
@@ -1176,6 +1176,35 @@
 	return res;
 }
 
+/**
+ * snd_pcm_resume_all
+ * @pcm: the PCM instance
+ *
+ * Trigger RESUME to all substreams in the given pcm.
+ * After this call, all streams that were SUSPENDED gets resumed to RUNNING state.
+ */
+int snd_pcm_resume_all(struct snd_pcm *pcm)
+{
+        struct snd_pcm_substream *substream;
+        int stream, err = 0;
+
+        if (! pcm)
+                return 0;
+
+        for (stream = 0; stream < 2; stream++) {
+                for (substream = pcm->streams[stream].substream;
+                     substream; substream = substream->next) {
+                        /* FIXME: the open/close code should lock this as well */
+                        if (substream->runtime == NULL)
+                                continue;
+                        err = snd_pcm_resume(substream);
+                        if (err < 0 && err != -EBUSY)
+                                return err;
+                }
+        }
+        return 0;
+}
+
 #else
 
 static int snd_pcm_resume(struct snd_pcm_substream *substream)
@@ -1183,6 +1212,11 @@
 	return -ENOSYS;
 }
 
+int snd_pcm_resume_all(struct snd_pcm *pcm)
+{
+	return -ENOSYS;
+}
+
 #endif /* CONFIG_PM */
 
 /*
Index: linux-work/include/sound/pcm.h
===================================================================
--- linux-work.orig/include/sound/pcm.h	2006-04-13 09:58:51.000000000 +1000
+++ linux-work/include/sound/pcm.h	2006-04-18 10:37:23.000000000 +1000
@@ -464,6 +464,7 @@
 #ifdef CONFIG_PM
 int snd_pcm_suspend(struct snd_pcm_substream *substream);
 int snd_pcm_suspend_all(struct snd_pcm *pcm);
+int snd_pcm_resume_all(struct snd_pcm *pcm);
 #endif
 int snd_pcm_kernel_ioctl(struct snd_pcm_substream *substream, unsigned int cmd, void *arg);
 int snd_pcm_open_substream(struct snd_pcm *pcm, int stream, struct file *file,
Index: linux-work/sound/core/pcm.c
===================================================================
--- linux-work.orig/sound/core/pcm.c	2006-04-13 09:58:55.000000000 +1000
+++ linux-work/sound/core/pcm.c	2006-04-18 10:36:35.000000000 +1000
@@ -1110,6 +1110,7 @@
 #ifdef CONFIG_PM
 EXPORT_SYMBOL(snd_pcm_suspend);
 EXPORT_SYMBOL(snd_pcm_suspend_all);
+EXPORT_SYMBOL(snd_pcm_resume_all);
 #endif
 EXPORT_SYMBOL(snd_pcm_kernel_ioctl);
 EXPORT_SYMBOL(snd_pcm_mmap_data);




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Lee Revell]

On Tue, 2006-04-18 at 10:58 +1000, Benjamin Herrenschmidt wrote:
> It appears that Alsa expects the streams to be resumed via some
> userland
> initiated ioctl, which for some reason is never called on my machine.
> What is the rationale there ? it's userland that is expected to
> save/restore hardware state ? That doesn't really match the linux PM
> model at this point and it seems that Alsa userland isn't notified of
> suspend/resume at least on powermacs. 

The app is expected to handle this by resetting the stream, the same way
you would handle an xrun.

What sound app(s) are you testing with?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Benjamin Herrenschmidt]

On Mon, 2006-04-17 at 21:20 -0400, Lee Revell wrote:
> On Tue, 2006-04-18 at 10:58 +1000, Benjamin Herrenschmidt wrote:
> > It appears that Alsa expects the streams to be resumed via some
> > userland
> > initiated ioctl, which for some reason is never called on my machine.
> > What is the rationale there ? it's userland that is expected to
> > save/restore hardware state ? That doesn't really match the linux PM
> > model at this point and it seems that Alsa userland isn't notified of
> > suspend/resume at least on powermacs. 
> 
> The app is expected to handle this by resetting the stream, the same way
> you would handle an xrun.
> 
> What sound app(s) are you testing with?

How are apps supposed to know about system suspend/resume ? There is no
proper way to do so that works accross architectures and suspend/resume
methods so far ... I yet have to see a single audio app that knows about
it ... (tried various KDE based things like Amarok, mpg123, xine, ... )

Is there any reason why the driver couldn't resume the playback itself ?
That is, is there any reason why the patch I proposed couldn't go in for
drivers to resume automatically ?

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Lee Revell]

On Tue, 2006-04-18 at 11:27 +1000, Benjamin Herrenschmidt wrote:
> How are apps supposed to know about system suspend/resume ? There is
> no proper way to do so that works accross architectures and
> suspend/resume methods so far ... I yet have to see a single audio app
> that knows about it ... (tried various KDE based things like Amarok,
> mpg123, xine, ... ) 

They don't specifically have to know about suspend and resume - from the
application point of view it just looks like an underrun - poll() or
write() will return an error code so the app checks the state with
snd_pcm_state() and recovers if it is SND_PCM_STATE_XRUN or
SND_PCM_STATE_SUSPENDED.

Are any of these native ALSA apps, or do they all go through artsd which
uses the OSS emulation layer?

Does it work OK with aplay?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Lee Revell]

On Mon, 2006-04-17 at 21:36 -0400, Lee Revell wrote:
> Are any of these native ALSA apps, or do they all go through artsd
> which
> uses the OSS emulation layer?
> 
> Does it work OK with aplay?
> 

Argh, actually it looks like aplay doesn't even handle this (and I was
wrong - apps do have to know about suspend they just don't have to do
anything special to handle it).

I don't know why snd_pcm_resume_all() can't be added.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Benjamin Herrenschmidt]

On Mon, 2006-04-17 at 21:45 -0400, Lee Revell wrote:
> On Mon, 2006-04-17 at 21:36 -0400, Lee Revell wrote:
> > Are any of these native ALSA apps, or do they all go through artsd
> > which
> > uses the OSS emulation layer?
> > 
> > Does it work OK with aplay?
> > 
> 
> Argh, actually it looks like aplay doesn't even handle this (and I was
> wrong - apps do have to know about suspend they just don't have to do
> anything special to handle it).
> 
> I don't know why snd_pcm_resume_all() can't be added.

Ok, well, you have the patch, here's a signed-off for it too: :)

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Benjamin Herrenschmidt]

On Mon, 2006-04-17 at 21:36 -0400, Lee Revell wrote:
> On Tue, 2006-04-18 at 11:27 +1000, Benjamin Herrenschmidt wrote:
> > How are apps supposed to know about system suspend/resume ? There is
> > no proper way to do so that works accross architectures and
> > suspend/resume methods so far ... I yet have to see a single audio app
> > that knows about it ... (tried various KDE based things like Amarok,
> > mpg123, xine, ... ) 
> 
> They don't specifically have to know about suspend and resume - from the
> application point of view it just looks like an underrun - poll() or
> write() will return an error code so the app checks the state with
> snd_pcm_state() and recovers if it is SND_PCM_STATE_XRUN or
> SND_PCM_STATE_SUSPENDED.
> 
> Are any of these native ALSA apps, or do they all go through artsd which
> uses the OSS emulation layer?
> 
> Does it work OK with aplay?

I'm not sure what they use at this point, I'll check later. I think I
didn't enabled artsd and amarok is using xine engine so it's probably
using alsa directly though.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: No snd_pcm_resume_all() ?

[Takashi Iwai]

At Tue, 18 Apr 2006 10:58:38 +1000,
Benjamin Herrenschmidt wrote:
> 
> Hi !
> 
> While tweaking a bit the power management code in Johannes' new snd-aoa
> for powermac, I got it to properly suspend & resume playback on
> sleep/waekup of the machine. However, an Alsa bit is missing for that to
> work and I'd like to understand why.
> 
> On suspend, it's fairly simple, we call snd_pcm_suspend_all() to suspend
> all streams before we go put the hardware into low power state.
> 
> On resume, I would expect to have a similar snd_pcm_resume_all() to call
> after I've restored the hardware & codecs state. However... it's not
> there. I hacked one up myself (patch below) and it seems to work fine.
> 
> It appears that Alsa expects the streams to be resumed via some userland
> initiated ioctl, which for some reason is never called on my machine.
> What is the rationale there ? it's userland that is expected to
> save/restore hardware state ? That doesn't really match the linux PM
> model at this point and it seems that Alsa userland isn't notified of
> suspend/resume at least on powermacs.

Possibly didn't set SNDRV_PCM_INFO_RESUME bit to snd_pcm_hardware.info
flags?

> Just adding snd_pcm_resume_all() and calling it at the right time seems
> to work fine for us, thus is there any reason why the patch below
> couldn't be pushed upstream ?

Indeed, the pcm resume was designed to be called from application to
restart.  The flow is like below:

When suspended, the app calls snd_pcm_resume() (via ioctl), and it's
firstly blocked by snd_power_wait() until the power state becomes D0.
At resume, the driver resume callback sets to D0 once after the chip
is re-initialized and ready for use.  Then woken-up snd_pcm_resume()
triggers the stream.  So, calling snd_pcm_resume_all() in the resume
callback is basically superfluous.

When SNDRV_PCM_INFO_RESUME is not set, snd_pcm_resume() doesn't
trigger but returns an error.  Then the app is supposed to do
reset-and-restart by itself.  (Or use a helper function in alsa-lib
to do this all, too.)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: No snd_pcm_resume_all() ?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On Tue, 2006-04-18 at 15:12 +0200, Takashi Iwai wrote:

> Indeed, the pcm resume was designed to be called from application to
> restart.  The flow is like below:

Why does the app even need to know?!

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Re: No snd_pcm_resume_all() ?

[Takashi Iwai]

At Tue, 18 Apr 2006 19:55:22 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-04-18 at 15:12 +0200, Takashi Iwai wrote:
> 
> > Indeed, the pcm resume was designed to be called from application to
> > restart.  The flow is like below:
> 
> Why does the app even need to know?!

We cannot freeze the running user process at the very same moment the
driver's suspend callback is called...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: No snd_pcm_resume_all() ?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

On Tue, 2006-04-18 at 20:05 +0200, Takashi Iwai wrote:

> We cannot freeze the running user process at the very same moment the
> driver's suspend callback is called...

Yeah but we can freeze the pcm before the app, so for the app it's just
as though there was a small pause/hiccup/whatever

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Re: No snd_pcm_resume_all() ?

[Takashi Iwai]

At Tue, 18 Apr 2006 20:06:30 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-04-18 at 20:05 +0200, Takashi Iwai wrote:
> 
> > We cannot freeze the running user process at the very same moment the
> > driver's suspend callback is called...
> 
> Yeah but we can freeze the pcm before the app, so for the app it's just
> as though there was a small pause/hiccup/whatever

That's the point.  The resume is handled just like another type of
xrun, which requires a recover.  So, the app needs to know what is
going on.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: No snd_pcm_resume_all() ?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Tue, 2006-04-18 at 20:10 +0200, Takashi Iwai wrote:

> That's the point.  The resume is handled just like another type of
> xrun, which requires a recover.  So, the app needs to know what is
> going on. 

Maybe I'm misunderstanding this, but it isn't an xrun is it? I thought
an xrun was when the app was too slow, but in our case the
'hardware/driver' is too slow, which doesn't really do anything.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Re: No snd_pcm_resume_all() ?

[Takashi Iwai]

At Tue, 18 Apr 2006 20:12:09 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-04-18 at 20:10 +0200, Takashi Iwai wrote:
> 
> > That's the point.  The resume is handled just like another type of
> > xrun, which requires a recover.  So, the app needs to know what is
> > going on. 
> 
> Maybe I'm misunderstanding this, but it isn't an xrun is it? I thought
> an xrun was when the app was too slow, but in our case the
> 'hardware/driver' is too slow, which doesn't really do anything.

Yes, of course, it's not an XRUN but "another type" of state.
The driver just notifes the SUSPENDED state when any access comes from
the app.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: No snd_pcm_resume_all() ?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Tue, 2006-04-18 at 20:25 +0200, Takashi Iwai wrote:

> Yes, of course, it's not an XRUN but "another type" of state.
> The driver just notifes the SUSPENDED state when any access comes from
> the app.

I still don't see why it is necessary. I can see two cases:

1) the app is frozen before the driver suspends, so that we get into a
regular xrun situation. That can be handled as an xrun

2) the driver suspends before the app is frozen, which means that the
app won't be getting any pcm progress for a bit of time, which doesn't
matter at all. Or is that the point where I'm mistaken, and it does
matter to the app if the hardware pauses for a bit (say for video/audio
sync)?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Re: No snd_pcm_resume_all() ?

[Takashi Iwai]

At Tue, 18 Apr 2006 20:40:53 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-04-18 at 20:25 +0200, Takashi Iwai wrote:
> 
> > Yes, of course, it's not an XRUN but "another type" of state.
> > The driver just notifes the SUSPENDED state when any access comes from
> > the app.
> 
> I still don't see why it is necessary. I can see two cases:
> 
> 1) the app is frozen before the driver suspends, so that we get into a
> regular xrun situation. That can be handled as an xrun
> 
> 2) the driver suspends before the app is frozen, which means that the
> app won't be getting any pcm progress for a bit of time, which doesn't
> matter at all. Or is that the point where I'm mistaken, and it does
> matter to the app if the hardware pauses for a bit (say for video/audio
> sync)?

Another reason is that not all drivers provide the full resume
capability.  Most drivers provide only the partial suspend -- the
driver can restore the hardware setting but the PCM must be restarted
for a proper operation.  In this case, the app requires the explicit
reset-and-restart.  So, it matter for apps what the current status
is.

IIRC, I discussed it for using a XRUN instead of an individual
SUSPENDED state in order to simplify the system, but it was rejected
by reasons I forgot :)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: No snd_pcm_resume_all() ?

[Jaroslav Kysela]

On Tue, 18 Apr 2006, Takashi Iwai wrote:

> At Tue, 18 Apr 2006 20:06:30 +0200,
> Johannes Berg wrote:
> > 
> > On Tue, 2006-04-18 at 20:05 +0200, Takashi Iwai wrote:
> > 
> > > We cannot freeze the running user process at the very same moment the
> > > driver's suspend callback is called...
> > 
> > Yeah but we can freeze the pcm before the app, so for the app it's just
> > as though there was a small pause/hiccup/whatever
> 
> That's the point.  The resume is handled just like another type of
> xrun, which requires a recover.  So, the app needs to know what is
> going on.

Also note that resume() is not supported with all hardware. Some hardware 
requires full prepare() / write() cycles and in this case only application 
can hadle this situation correctly. Also, some real-time applications 
might use this information for the time-dependent recovery (in some 
situations the resume has no sense).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: No snd_pcm_resume_all() ?

[Benjamin Herrenschmidt]

On Tue, 2006-04-18 at 20:05 +0200, Takashi Iwai wrote:
> At Tue, 18 Apr 2006 19:55:22 +0200,
> Johannes Berg wrote:
> > 
> > On Tue, 2006-04-18 at 15:12 +0200, Takashi Iwai wrote:
> > 
> > > Indeed, the pcm resume was designed to be called from application to
> > > restart.  The flow is like below:
> > 
> > Why does the app even need to know?!
> 
> We cannot freeze the running user process at the very same moment the
> driver's suspend callback is called...

On ppc, I don't freeze processes at all... though from my experience,
just doing the suspend at sleep and the resume on wakeup from the driver
without freezing the app just works... the samples just stop getting
pumped for a little while. 

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642