proper suspend / resume for PCM streams

proper suspend / resume for PCM streams

[Jaroslav Kysela]

Hi,

	I'm digging to add the proper suspend and resume to the HDA intel 
driver (PCM) and I noticed that some drivers incorrectly uses 
the SNDRV_PCM_INFO_RESUME flag (notably intel8x0.c, intel8x0m.c, 
hda_intel.c and perhaps more - I'll check).
	The semantics of this flag is: The driver can do full recovery
for the suspended stream and can trigger it back to previous state 
(including position in the ring buffer and all other related things).
If the PCM stream must be restarted with the prepare callback, this flag 
MUST NOT be set.
	For the first glance: cs4281.c and es1968.c drivers are restoring 
the registers, so it appears that the full resume should work for them.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Jaroslav Kysela]

On Mon, 15 Aug 2005, Jaroslav Kysela wrote:

> Hi,
> 
> 	I'm digging to add the proper suspend and resume to the HDA intel 
> driver (PCM) and I noticed that some drivers incorrectly uses 
> the SNDRV_PCM_INFO_RESUME flag (notably intel8x0.c, intel8x0m.c, 
> hda_intel.c and perhaps more - I'll check).
> 	The semantics of this flag is: The driver can do full recovery
> for the suspended stream and can trigger it back to previous state 
> (including position in the ring buffer and all other related things).
> If the PCM stream must be restarted with the prepare callback, this flag 
> MUST NOT be set.
> 	For the first glance: cs4281.c and es1968.c drivers are restoring 
> the registers, so it appears that the full resume should work for them.

And here is the simplest way to test the suspend/resume for PCM:

first console : aplay -Dplughw:0 <some_file>
second console: alsactl power off ; alsactl power on

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Takashi Iwai]

At Mon, 15 Aug 2005 21:47:41 +0200 (CEST),
Jaroslav wrote:
> 
> Hi,
> 
> 	I'm digging to add the proper suspend and resume to the HDA intel 
> driver (PCM) and I noticed that some drivers incorrectly uses 
> the SNDRV_PCM_INFO_RESUME flag (notably intel8x0.c, intel8x0m.c, 
> hda_intel.c and perhaps more - I'll check).
> 	The semantics of this flag is: The driver can do full recovery
> for the suspended stream and can trigger it back to previous state 
> (including position in the ring buffer and all other related things).
> If the PCM stream must be restarted with the prepare callback, this flag 
> MUST NOT be set.
> 	For the first glance: cs4281.c and es1968.c drivers are restoring 
> the registers, so it appears that the full resume should work for them.

Do we need another flag, then?  Currently, alsa-lib doesn't handle the
cases with a half-way suspend/resume support as most of drivers
provide.

Nevertheless, the current way of snd_pcm_resume() is quite
user-unfriendly.  snd_pcm_prepare() and other complex procedure must
be handled inside snd_pcm_resume(), instead of forcing each app to do
it.

Also we can provide a standard PCM error handling routine to do the
standard job like XRUN and PM recovery, too.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Jaroslav Kysela]

On Tue, 16 Aug 2005, Takashi Iwai wrote:

> > 	For the first glance: cs4281.c and es1968.c drivers are restoring 
> > the registers, so it appears that the full resume should work for them.
> 
> Do we need another flag, then?  Currently, alsa-lib doesn't handle the
> cases with a half-way suspend/resume support as most of drivers
> provide.

I don't understand the requirement for the new flag. Could you explain?

> Nevertheless, the current way of snd_pcm_resume() is quite
> user-unfriendly.  snd_pcm_prepare() and other complex procedure must
> be handled inside snd_pcm_resume(), instead of forcing each app to do
> it.
> 
> Also we can provide a standard PCM error handling routine to do the
> standard job like XRUN and PM recovery, too.

Well, I'm not against a helper function for really simple apps, but there 
is drastic difference between resume and restart of the PCM stream 
(buffering), so the enhanced applications must have a way to know about 
these events.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Takashi Iwai]

At Tue, 16 Aug 2005 12:57:32 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 16 Aug 2005, Takashi Iwai wrote:
> 
> > > 	For the first glance: cs4281.c and es1968.c drivers are restoring 
> > > the registers, so it appears that the full resume should work for them.
> > 
> > Do we need another flag, then?  Currently, alsa-lib doesn't handle the
> > cases with a half-way suspend/resume support as most of drivers
> > provide.
> 
> I don't understand the requirement for the new flag. Could you explain?

There are drivers which don't support PM at all (the ones without
suspend/resume callback).  But some do support PM but just lack
prepare().  Trying resume for the former could be harmfull.

> > Nevertheless, the current way of snd_pcm_resume() is quite
> > user-unfriendly.  snd_pcm_prepare() and other complex procedure must
> > be handled inside snd_pcm_resume(), instead of forcing each app to do
> > it.
> > 
> > Also we can provide a standard PCM error handling routine to do the
> > standard job like XRUN and PM recovery, too.
> 
> Well, I'm not against a helper function for really simple apps, but there 
> is drastic difference between resume and restart of the PCM stream 
> (buffering), so the enhanced applications must have a way to know about 
> these events.

I've never seen such apps, so far :)

See the current situation.  Now we have only two worlds:
- Players/recorders using ALSA API or another layer like gstreamer
- RT-apps using JACK

The suspend/resume is anyway out of question for JACK.
OTOH, the former case prefers a simple way of error handling.
All higher layer libraries do the same job as a standard error
handling, too.

If the simple error handling really matters, we can provide another
function to turn this feature off.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Jaroslav Kysela]

On Tue, 16 Aug 2005, Takashi Iwai wrote:

> At Tue, 16 Aug 2005 12:57:32 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Tue, 16 Aug 2005, Takashi Iwai wrote:
> > 
> > > > 	For the first glance: cs4281.c and es1968.c drivers are restoring 
> > > > the registers, so it appears that the full resume should work for them.
> > > 
> > > Do we need another flag, then?  Currently, alsa-lib doesn't handle the
> > > cases with a half-way suspend/resume support as most of drivers
> > > provide.
> > 
> > I don't understand the requirement for the new flag. Could you explain?
> 
> There are drivers which don't support PM at all (the ones without
> suspend/resume callback).  But some do support PM but just lack
> prepare().  Trying resume for the former could be harmfull.

Yes, but they don't have set the INFO_RESUME flag, thus the midlevel
returns an error code for the resule ioctl...

> > > Nevertheless, the current way of snd_pcm_resume() is quite
> > > user-unfriendly.  snd_pcm_prepare() and other complex procedure must
> > > be handled inside snd_pcm_resume(), instead of forcing each app to do
> > > it.
> > > 
> > > Also we can provide a standard PCM error handling routine to do the
> > > standard job like XRUN and PM recovery, too.
> > 
> > Well, I'm not against a helper function for really simple apps, but there 
> > is drastic difference between resume and restart of the PCM stream 
> > (buffering), so the enhanced applications must have a way to know about 
> > these events.
> 
> I've never seen such apps, so far :)

And it's really bad... They should care.

> See the current situation.  Now we have only two worlds:
> - Players/recorders using ALSA API or another layer like gstreamer
> - RT-apps using JACK
> 
> The suspend/resume is anyway out of question for JACK.
> OTOH, the former case prefers a simple way of error handling.
> All higher layer libraries do the same job as a standard error
> handling, too.
> 
> If the simple error handling really matters, we can provide another
> function to turn this feature off.

It's not about error handling, it's about PCM state handling.
As I said, we may add some helper functions to handle these states in some 
default way (like aplay does) and rest of applications will do the state 
handling itself.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Takashi Iwai]

At Tue, 16 Aug 2005 13:18:15 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 16 Aug 2005, Takashi Iwai wrote:
> 
> > At Tue, 16 Aug 2005 12:57:32 +0200 (CEST),
> > Jaroslav wrote:
> > > 
> > > On Tue, 16 Aug 2005, Takashi Iwai wrote:
> > > 
> > > > > 	For the first glance: cs4281.c and es1968.c drivers are restoring 
> > > > > the registers, so it appears that the full resume should work for them.
> > > > 
> > > > Do we need another flag, then?  Currently, alsa-lib doesn't handle the
> > > > cases with a half-way suspend/resume support as most of drivers
> > > > provide.
> > > 
> > > I don't understand the requirement for the new flag. Could you explain?
> > 
> > There are drivers which don't support PM at all (the ones without
> > suspend/resume callback).  But some do support PM but just lack
> > prepare().  Trying resume for the former could be harmfull.
> 
> Yes, but they don't have set the INFO_RESUME flag, thus the midlevel
> returns an error code for the resule ioctl...

That's the very problem.  We can't see whether the device suppose PM
or not from this level.  So, from the app level, it can't see whether
the PM is possible or not.

> > > > Nevertheless, the current way of snd_pcm_resume() is quite
> > > > user-unfriendly.  snd_pcm_prepare() and other complex procedure must
> > > > be handled inside snd_pcm_resume(), instead of forcing each app to do
> > > > it.
> > > > 
> > > > Also we can provide a standard PCM error handling routine to do the
> > > > standard job like XRUN and PM recovery, too.
> > > 
> > > Well, I'm not against a helper function for really simple apps, but there 
> > > is drastic difference between resume and restart of the PCM stream 
> > > (buffering), so the enhanced applications must have a way to know about 
> > > these events.
> > 
> > I've never seen such apps, so far :)
> 
> And it's really bad... They should care.
> 
> > See the current situation.  Now we have only two worlds:
> > - Players/recorders using ALSA API or another layer like gstreamer
> > - RT-apps using JACK
> > 
> > The suspend/resume is anyway out of question for JACK.
> > OTOH, the former case prefers a simple way of error handling.
> > All higher layer libraries do the same job as a standard error
> > handling, too.
> > 
> > If the simple error handling really matters, we can provide another
> > function to turn this feature off.
> 
> It's not about error handling, it's about PCM state handling.
> As I said, we may add some helper functions to handle these states in some 
> default way (like aplay does) and rest of applications will do the state 
> handling itself.

Well, what's the difference of error handling and PCM state handling?

The point in my last post is that both mean the same for almost all
cases.  I.e. when snd_pcm_readx/writex() (or avail & mmap) receives
-EXXX, do the standard error handling.  Nothing else is required.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Jaroslav Kysela]

On Tue, 16 Aug 2005, Takashi Iwai wrote:

> > Yes, but they don't have set the INFO_RESUME flag, thus the midlevel
> > returns an error code for the resule ioctl...
> 
> That's the very problem.  We can't see whether the device suppose PM
> or not from this level.  So, from the app level, it can't see whether
> the PM is possible or not.

It's not a problem. If the driver does not support resume, the SUSPENDED 
PCM state never occurs. Thus the -ESTRPIPE error code won't be ever seen 
with an application.

> > It's not about error handling, it's about PCM state handling.
> > As I said, we may add some helper functions to handle these states in some 
> > default way (like aplay does) and rest of applications will do the state 
> > handling itself.
> 
> Well, what's the difference of error handling and PCM state handling?
> 
> The point in my last post is that both mean the same for almost all
> cases.  I.e. when snd_pcm_readx/writex() (or avail & mmap) receives
> -EXXX, do the standard error handling.  Nothing else is required.

Okay, the error code carries the state information, but the point is 
that the application should do necessary things in this stage like:

1) try recovery from resume and continue (standard players)
2) stop the stream and tell to the user that he/she is stupid to do such 
   things for live performance (for example JACK will do it ;-))

The point is that the application must decide what to do with this state.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Takashi Iwai]

At Tue, 16 Aug 2005 13:33:58 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 16 Aug 2005, Takashi Iwai wrote:
> 
> > > Yes, but they don't have set the INFO_RESUME flag, thus the midlevel
> > > returns an error code for the resule ioctl...
> > 
> > That's the very problem.  We can't see whether the device suppose PM
> > or not from this level.  So, from the app level, it can't see whether
> > the PM is possible or not.
> 
> It's not a problem. If the driver does not support resume, the SUSPENDED 
> PCM state never occurs. Thus the -ESTRPIPE error code won't be ever seen 
> with an application.

Ah, I see.  OK, then it's superfluous.

> > > It's not about error handling, it's about PCM state handling.
> > > As I said, we may add some helper functions to handle these states in some 
> > > default way (like aplay does) and rest of applications will do the state 
> > > handling itself.
> > 
> > Well, what's the difference of error handling and PCM state handling?
> > 
> > The point in my last post is that both mean the same for almost all
> > cases.  I.e. when snd_pcm_readx/writex() (or avail & mmap) receives
> > -EXXX, do the standard error handling.  Nothing else is required.
> 
> Okay, the error code carries the state information, but the point is 
> that the application should do necessary things in this stage like:
> 
> 1) try recovery from resume and continue (standard players)
> 2) stop the stream and tell to the user that he/she is stupid to do such 
>    things for live performance (for example JACK will do it ;-))
> 
> The point is that the application must decide what to do with this state.

Sure, I understand this.  However, the reality tells us that the case
2 is so rare.  Almost all apps does only the case 1.

Now the question is why we don't do this as default, or at least,
didn't provide any function to do it in the simple way.

I'm not stuck with the change of resume in this stage, but we should
keep a better usability in mind...


<slightlyofftopic>
What I've learned about a "better" API from ALSA development are:

1. Provide as minimal capabilities as possible as at a first glance
2. Make the "enhanced" features are optional
3. Avoid structs in API as much as possible
4. Avoid arch-dependent variables and struct fields in the exported
   API (e.g. pointer and long)

Let's consider such things for the future (extended) API.
</slightlyofftopic>


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Lee Revell]

On Tue, 2005-08-16 at 13:33 +0200, Jaroslav Kysela wrote:
> Okay, the error code carries the state information, but the point is 
> that the application should do necessary things in this stage like:
> 
> 1) try recovery from resume and continue (standard players)
> 2) stop the stream and tell to the user that he/she is stupid to do
> such things for live performance (for example JACK will do it ;-))
> 
> The point is that the application must decide what to do with this
> state.
> 

I think 2) is broken anyway.  JACK should keep going like any other app.
suspend/resume should just look like an xrun.

I would expect to be able to suspend/resume while using ASIO apps on
Windows.  What if the neighbors complain, so you have to move band
practice to another room quickly?

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Takashi Iwai]

At Tue, 16 Aug 2005 11:00:14 -0400,
Lee Revell wrote:
> 
> On Tue, 2005-08-16 at 13:33 +0200, Jaroslav Kysela wrote:
> > Okay, the error code carries the state information, but the point is 
> > that the application should do necessary things in this stage like:
> > 
> > 1) try recovery from resume and continue (standard players)
> > 2) stop the stream and tell to the user that he/she is stupid to do
> > such things for live performance (for example JACK will do it ;-))
> > 
> > The point is that the application must decide what to do with this
> > state.
> > 
> 
> I think 2) is broken anyway.  JACK should keep going like any other app.
> suspend/resume should just look like an xrun.
> 
> I would expect to be able to suspend/resume while using ASIO apps on
> Windows.  What if the neighbors complain, so you have to move band
> practice to another room quickly?

Yep, I agree that it should be handled _somehow_ as an error.
And I guess the handling of resume is (and will be) not different from
XRUN in JACK.

That's the whole point of my suggestions.  If we handle xrun/resume,
the procedure is same in almost all cases.
But, currently, each app has to implement the quite same code by
itself.  This makes harder not only to write an app but also to
support a new error-handling feature or even fix a bug in alsa-lib.

Whether we should change the default behavior of snd_pcm_resume() at
this stage -- I don't know.  Just providing a function like
snd_pcm_handle_error(pcm, err) might suffice, though.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: proper suspend / resume for PCM streams

[Jaroslav Kysela]

On Tue, 16 Aug 2005, Takashi Iwai wrote:

> Whether we should change the default behavior of snd_pcm_resume() at
> this stage -- I don't know.  Just providing a function like
> snd_pcm_handle_error(pcm, err) might suffice, though.

Yes, the function should be like xrun_recovery() in alsa-lib/test/pcm.c .

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf