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
-~----------~----~----~----~------~----~------~--~---

Reply via email to