On Fri, 15 May 2020 15:30:25 +0200, Dexter Travis wrote: > > Takashi, > > Thank you. That is helpful. In my case we are embedded deeply enough > that there is only one application playing sounds so it may be > possible to improve our user space side to properly close down the > sound. > > When power comes back I do not need to resume playing the previous > sound. From the kernel side is it possible to force the sound to > abort or stop? That can be done by calling snd_pcm_stop(). The function needs the stream locking. You can use snd_pcm_stop_xrun() instead, although it's no XRUN, strictly speaking. > How do more easily removed sound devices handle this? For example a > USB or other hot-pluggable sound device? In the case of actually removed device, the whole device is gone, and at re-plugging, a new device gets created, hence no conflicts between them. They are two different devices, after all. Takashi > > > > Regards, > > > Dexter > > On Fri, May 15, 2020 at 2:32 AM Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > On Thu, 14 May 2020 23:04:09 +0200, > > Dexter Travis wrote: > > > > > > In my system during certain power events the power rail for the > > > TLV320AIC3120 goes away and may come back. > > > > > > To accommodate this I have added a call to snd_soc_unregister_card as > > > soon as I notice via GPIO that this power has been removed. I then > > > call snd_soc_register_card to re-install the sound card after power is > > > restored. > > > > > > If no sound is playing when the asynchronous power removal occurs this > > > works fine. > > > > > > If a sound is playing one of two things will occur. In the first case > > > the sound driver comes back and sound is restored when power is > > > restored. In the second case my deferred work function which calls the > > > snd_soc_unregister_card function gets hung and does not return. > > > > > > I have traced the difference to the wait_for_completion call in > > > snd_card_free. if snd_card_disconnect adds files to shutdown_files > > > list then wait_for_completion will hang forever. > > > > > > Any suggestions on how to further debug this? > > > > > > How to force the immediate unregister of the card even if a sound is playing? > > > > You can unregister the devices, i.e. they disappear from the > > user-space. However, the old stream and the belonging objects are > > still alive, hence you can't release the resources entirely until the > > user-space closes and drops the remaining one. The completion is > > waiting for the release of those remaining handles. So, if you try to > > register again the same objects, it'll conflict. > > > > IOW, it'll be really messy if you try to disconnect and release the > > whole resources temporarily and restore again. I guess the current > > best would be to limit a part of components somehow during the > > temporary absence. > > > > The temporary stop of a stream isn't well handled in the core API, > > admittedly, it's a known problem. We're considering to introduce a > > new state, but it's still under evaluation. > > > > > > thanks, > > > > Takashi >
