Hello, I usually see thisd problem when i try playing a playlist in the music application of android. It happens when the track is getting changed and it is not consistent some times it changes track after 3 or 4 times it fails passing this
W/AudioFlinger( 1067): write blocked for 205 msecs W/AudioTrack( 1067): obtainBuffer timed out (is the CPU pegged?) user=00000100, server=00000000 Sean, I dont see any issue with suspend and resume functionality. You were saying that it may be bug in the kernel. I am using omap3 and TWL4030 ASoC stuff with mcbsp-2 as a DIA and DMA Can you suggest me some commons to start looking at. On Wed, Jan 7, 2009 at 1:15 PM, Sean McNeil <seanmcne...@gmail.com> wrote: > > 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)? > > > > > -- Thanks, (: Naveen Krishna Ch :) --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
