Thanks Dave, it worked fine. We're using an own implementation for ALSA, but I think that also alsa_sound implementation will have the same problem. We'll move to that implementation soon, so I think it's a good idea to start working on it.
-Misa 2009/1/23 Dave Sparks <[email protected]> > > The correct place to spin up the audio hardware is in the > AudioOutputStream::write() method. In our other implementations, we > have a standby flag that is checked at the start of write and if true, > the kernel driver is opened. In AudioOutputStream::standby(), we close > the driver and set the standby flag to true. > > On Jan 23, 7:24 pm, Misael Lopez <[email protected]> wrote: > > We are having problems trying to put system in "suspend" state because > some > > clock are kept alive. These clocks are audio related. > > > > AudioFlinger's constructor calls openOutputStream method, which opens > ALSA > > pcm interface by calling "snd_pcm_open" (ALSA API). In ALSA kernel driver > it > > means that resources will be allocated and hardware codec will be on. > > However, even if no output stream is being transmitted, stream channel is > > never closed making audio resources being active always at kernel level. > > This prevents the system to sleep. > > > > I think we should only open ALSA PCM interface when needed and not > directly > > from boot-time, but it seems that openOutputStream method is the right > place > > to call "snd_pcm_open", isn't it? Is there any other better place to open > > ALSA interface? Or any other solution? > > > > -Misa > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
