/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.
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 :) --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
