At Mon, 12 Jun 2006 14:05:15 -0700, Sam Revitch wrote: > > Hi everybody, > > I'd like to solicit the ALSA brain trust for tips and opinions on how > one might go about implementing a new feature. With some (most?) of > the ALSA driver code base, it is possible, or at least someone > intended for it to be possible to leave an MP3 player or such running > across a suspend-to-RAM or suspend-to-disk operation, and have it pick > up exactly where it left off on resume. To see this in action is just > cool, there's no getting around it. A notable exception to this is > the snd-usb-audio driver, under which devices seem to be disconnected > and re-enumerated as entirely new cards, rather than having their > state explicitly backed up and restored with the assumption that the > hardware will be present on resume. > > I searched hard and couldn't find any prior efforts to address this > problem, so it seemed worthwhile to ask about. > > There are two possibilities that seem promising: > > 1. Rework snd-usb-audio to support a timely reconnect operation. If a > card is unplugged and reconnected within some period of time, its > prior state will be restored and it will be reassociated with open > file handles. Active playback/capture operations may continue without > reopening the device, with only the reconnection/reconfiguration > delay. > > 2. Support reconnection at the alsa-lib layer. I couldn't find > anything that does this already. Somehow all playback/capture file > descriptors would need to be closed on command and > reopened/reconfigured when a replacement device is identified. > Anybody know of an easy way to do this with dmix? Otherwise it seems > like alsa-lib would be stuck funneling playback through an > aserver/jackd process and that would be undesirable. > > Opinions? Does one seem like it would be more robust, more reusable, > or more work than the other? The recent usb drivers have suspend/resume callbacks. So, just implementing them might suffice. > 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? Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
