naveenkrishna.ch wrote: > > > On Wed, Jan 7, 2009 at 12:35 PM, Sean McNeil <seanmcne...@gmail.com > <mailto:seanmcne...@gmail.com>> wrote: > > > naveenkrishna.ch wrote: > > > > > > On Wed, Jan 7, 2009 at 12:18 PM, Sean McNeil > <seanmcne...@gmail.com <mailto:seanmcne...@gmail.com> > > <mailto:seanmcne...@gmail.com <mailto:seanmcne...@gmail.com>>> > wrote: > > > > > > There is a version of the WindRiver ALSA audio that uses > unblocked I/O > > and will kick-start the audio if this happens. The real > problem is > > that > > the ALSA driver usually doesn't survive well over a > > suspend/resume. The > > way to reproduce the problem is if: > > > > 1) Play something. > > 2) Stop play. > > 3) Suspend. > > 4) Resume. > > 5) Play something. > > > > It shouldn't allow the platform to sleep when playing, so if > it is a > > suspend/resume issue you are seeing then this is the only way to > > reproduce it. > > > > Yeah i was able to reproduce the problem. But, the basic underlying > > reason of the problem is what i dont understand. > > Is this because of the buffer size it takes or DSP bridge not being > > implemented. > > It is the audio driver in the kernel not resetting properly. This > causes > the write to the device to block indefinitely and then buffers > never get > freed. > > I am using ASoC omap framwork with twl4030 ASoC driver. > The buffer/period sizes are defined only in sound/soc/omap/omap-pcm.c > We have not yet implemented the suspend and resume yet. > I usually see the above issue when i try changing the media volume or > trying to > use the music player applications drastically. > I dont see any chance of suspend and resume activity in my case. In > this case > how the audio driver gets reset. > > Could you please consider to explain this scenario.
I've explained the major issue here - it is your audio drivers fault. It isn't returning from a write. This could be for any number of reasons. In your case, I'd look at how you've MUXd the interface between the OMAP and the TWL. Then, if you are using mcBSP1 or 2 with DMA, I'd consider perhaps you are losing an interrupt somewhere. Then there is the ALSA layer implementation on top of the low level stuff. Wind River has had no issues with audio on Zoom reference platforms and customer hardware, so it isn't really the ALSA layer in Android. Maybe your kernel version is too old (missing bug fixes) or too new (recently introduced bug)? --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
