Re: introduction of blacklist for autosuspend

On Fri, 9 Feb 2007, Jon Smirl wrote:

> On 2/9/07, Alan Stern <[email protected]> wrote:
> > Are you certain?  The mute button is on the top front edge, but the light
> > appears about 2/3 of the way up the front side.  (There may be another
> > light right on the mute button as well; I can't remember.)
> 
> The light on the front is the volume indicator.  They are horizontal
> bars. I think I convinced myself that it doesn't have a hardwired
> power light, all lights are under software control.

So apparently it resumes with the volume turned off -- which you would 
expect if it resumed with Mute on.  Or maybe the lights have no direct 
connection with the actual volume level and need to be synchronized by 
software.

> > So you're suggesting that perhaps the device resumes with the Mute turned
> > on?  That would still be a bug, but not a terribly serious one.
> 
> This may be a case of USB audio's state getting out of sync with what
> is set into the device. Here's an experiment I never figured out how
> to do, get the device playing music, and then suspend/resume it. That
> is different than quickly suspending the device before USB audio has a
> chance to set it up.

That test won't work, because the USB audio driver doesn't have support
for suspend/resume.

> Actually, do any USB audio devices work with the new suspend code, has
> anyone checked other devices?

I haven't heard from anyone with USB audio hardware, other than you.

>  Maybe the first suspend is happening
> before USB audio gets everything set up and then when the device
> resumes USB audio doesn't know what to do with it. The hub works
> because it gets suspended later and USB audio has had a chance to set
> things up. What happens if USB audio sends commands to a suspended
> device, do they wake it up or return errors, does USB audio check the
> errors?

In fact, the problem you originally reported was that the device _was_
getting suspended before the USB audio driver could load.  The device was
resumed when the driver loaded, but by then it was already too late -- the
device was no longer working.  (Although maybe it really was working but
was Muted...)

As long as you're not actually playing anything, the USB audio driver is
quiescent.  A suspend and resume could occur without its even noticing.  
If you tried playing something during a suspend, the driver would
immediately encounter a number of errors (failure to send data to the
device) and completely bomb out.  That isn't happening here.

> Another experiment would be to switch the initial auto-suspend delay
> to one minute instead of two seconds. That would give the boot process
> time to finish before the suspends start to happen.

I tried that.  Same effect.

Alan Stern


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel