At Wed, 14 Jun 2006 15:51:01 +0200 (CEST), Jaroslav Kysela wrote: > > On Wed, 14 Jun 2006, Takashi Iwai wrote: > > > At Wed, 14 Jun 2006 14:19:14 +0200, > > I wrote: > > > > > > At Wed, 14 Jun 2006 13:37:14 +0200 (CEST), > > > Jaroslav Kysela wrote: > > > > > > > > On Wed, 14 Jun 2006, Takashi Iwai wrote: > > > > > > > > > > As another individual pointed out a few months ago, there are some > > > > > > other problems with snd-usb-audio similar to those described above. > > > > > > If a certain usb audio device has open file handles and is > > > > > > disconnected or the system is suspended, > > > > > > snd_usb_audio_disconnect()->snd_card_free() will block in the khubd > > > > > > context while ALSA waits for the file handles to be closed, preventing > > > > > > khubd from doing anything else useful like processing probe requests. > > > > > > Using snd_card_free_in_thread() can be just as bad as it uses > > > > > > schedule_work() and blocks one of the "events" threads. A hang in > > > > > > either context can cause problems for a resume-from-RAM operation. > > > > > > > > > > Hm, this has to be fixed. Just skipping the wait for file close will > > > > > solve the problem? > > > > > > > > Skipping the wait means calling snd_card_free() in last fops->release(), > > > > > > No, snd_card_free() is called in disconnect callback. > > > > I was too desnse. You meant "a part of jobs of snd_card_free()" is > > going to be executed in the last release? > > Yes, exactly. > > > 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. > > Yes, but we have a problem when an user remove an hotplug device, if > apps do not check the state of file descriptor. After disconnect, > read()/write() syscalls return immediately with -ENODEV and poll() with > POLLERR | POLLNVAL, thus it should be possible to close the disconnected > devices ASAP. Then such a thing should be implemented in alsa-lib, not in app codes. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
