At Wed, 14 Jun 2006 10:20:57 -0700, Sam Revitch wrote: > > > Anyway, re-reading the quote above, it sounds more like a problem > > happening only via suspend. Then, this might be solved automatically > > if the proper suspend/resume is implemented on usb-audio driver. > > > I'm not sure how alsa-lib can decide if device has been disconnected > > permanently or temporary. But if you mean "closing the file descriptor > > in the first time when -ENODEV occurs", it makes a lot of sense for > > alsa-lib and yes, it should be there. > > Thanks for replies. > > The problem with usb_audio_disconnect() getting stuck isn't specific > to suspend, although the part of it that I care about right now is. > That function shouldn't be waiting for handles to be closed, as > somebody can execute a DoS attack on khubd by sending SIGSTOP to any > process that has the sound driver open. > > Perhaps the snd_device dev_disconnect and dev_unregister routines for > the various abstract layers need to be changed so that sysfs/procfs > entries are removed in dev_disconnect? This way it might be possible > to release a slot without freeing anything that might be in use. Yes, it sounds feasible. > As for implementing suspend/resume methods for snd-usb-audio, doesn't > that require explicit support from the device for retaining state in > some sort of low power 0.5mA mode? I don't know whether the card I'm > using even supports that. I don't think the low-poer mode is a requirement although it would be nice to have. The main purpose of suspend/resume is the stop of PCM streams and save/restore the mixer status. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
