These all sound like symptoms of the same problem. We don't have anything internally using the ALSA drivers and I haven't looked at them myself. Maybe somebody from WindRiver can lend a hand.
On Jan 10, 12:05 am, Neo <naveenkrishna...@gmail.com> wrote: > On Jan 9, 11:31 pm, Dave Sparks <davidspa...@android.com> wrote: > > > /dev/eac is only necessary if you are using the generic user space > > audio driver. If you are using ALSA driver, /dev/eac should not come > > into play at all unless you are running your code in emulation. > > Yeah, > We are using the Windrivers Audio ALSA integration in Android. > And i have the ObtainBuffer timedOut message from AudioFlinger. > Where i should look for a promissing solution. > I have a couple of other issues regarding Audio on Android. > > 1. AudioRecord: BufferOverflow > Error message when trying to record with asimple record applciation. > This message follows a condition of getting a nextBuffer in the > queue. > It arives after 2 or 4 seconds of recording and nothing records after > this message. > But, there is no crash or any other prints. > > 2. Underrun Occured > Message comes from alsa lib. > when trying to change the medio volume with some other applications > too. > But, this dosent seems to cause any problem to any applications > progress. > > Any kind of help is appreciable. > > > > > On Jan 9, 2:24 am, "Anil Sasidharan" <anil...@gmail.com> wrote: > > > > Hi leemgs, > > > > I guess the question was about ALSA integration into > > > Android, hence the point regarding the presence of /dev/eac is a > > > little confusing. From the descriptions given by Naveen about their > > > implementation, its clearly evident that the initial integration with > > > ALSA driver is complete and they have issues only in terms of buffer > > > management (obtainBuffer timing out) in certain use cases. It would be > > > nice if you could just give a brief idea on the reason why there is > > > suspicion on /dev/eac. > > > > Warm Regards, > > > anil > > > > On Thu, Jan 8, 2009 at 8:18 PM, leemgs <lee...@gmail.com> wrote: > > > > > Hi, > > > > > I have one opinion about your question. > > > > > Maybe, /dev/eac device node file didn't made by default.... > > > > > About audio probelm, see ./system/core/init/devices.c file, > > > > If audio is subsystem audio, this is consist of /dev/snd/ sub directory. > > > > If audio is generic audio , AudioHardwareInterface.cpp consist > > > > that open audio with /dev/eac device node file. > > > > So, after all, .... you will meet audio fail problem. > > > > stop to protect that consist audio subsystem in devices.c file, > > > > and then, modify code with pattern that /dev/eac can open . > > > > Good lucks... > > > > > 2009/1/8 naveenkrishna. ch <naveenkrishna...@gmail.com>: > > > >> 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 :)- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
