AudioTrack(): obtainBuffer timed out

[naveenkrishna.ch]

I started working on audio with OMAP3 + Android.
I have the windrivers audio porting as base the audio playback works fine.
But some times i get a warning prints continuously
with audio playback stopping and logging some entry similar to below.

W/AudioTrack( 566): obtainBuffer timed out (is the CPU pegged?) user=00000100, server=00000000

after that point i could not make it re-play again without restarting.

I have seen a similar issue raised earlier but was not solved at that point of time.
Is there any work around for this issue.

--
Thanks,

(: Naveen Krishna Ch :)

[Sean McNeil]

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.

[naveenkrishna.ch]

On Wed, Jan 7, 2009 at 12:18 PM, Sean McNeil <seanm...@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.

Where can u get the version of the Windriver ALSA audio where the unbloacking I/O
is being implemented

naveenkrishna.ch wrote:
> I started working on audio with OMAP3 + Android.
> I have the windrivers audio porting as base the audio playback works fine.
> But some times i get a warning prints continuously
> with audio playback stopping and logging some entry similar to below.
>
> W/AudioTrack( 566): obtainBuffer timed out (is the CPU pegged?)
> user=00000100, server=00000000
>
> after that point i could not make it re-play again without restarting.
>
> I have seen a similar issue raised earlier but was not solved at that
> point of time.
> Is there any work around for this issue.
>
> --
> Thanks,
>
> (: Naveen Krishna Ch :)
>
> >

--
Thanks,
keep smiling...
keep winning...

[Sean McNeil]

naveenkrishna.ch wrote:
>
>
> On Wed, Jan 7, 2009 at 12:18 PM, Sean McNeil <seanm...@gmail.com
> <mailto:seanm...@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.

>
> Where can u get the version of the Windriver ALSA audio where the
> unbloacking I/O
> is being implemented

It is being reviewed internally at WRS. There are also some minor
changes that need to be made to support Googles change of the interface
recently.

[naveenkrishna.ch]

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.

[Sean McNeil]

naveenkrishna.ch wrote:
>
>
> On Wed, Jan 7, 2009 at 12:35 PM, Sean McNeil <seanm...@gmail.com
> <mailto:seanm...@gmail.com>> wrote:
>
>
> naveenkrishna.ch wrote:
> >
> >
> > On Wed, Jan 7, 2009 at 12:18 PM, Sean McNeil
> <seanm...@gmail.com <mailto:seanm...@gmail.com>

> > <mailto:seanm...@gmail.com <mailto:seanm...@gmail.com>>>

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)?

[naveenkrishna.ch]

I am using 2.6.26 kernel and ported all the OMAP related ASoC stuff from mail line kernel on October 28th 2008 and i took the TWL4030 ASoC driver submitted by
  Steve Sakoman for Overo board.
May i know which kernel is suggestible or where can i get the bug fix patces

[naveenkrishna.ch]

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.

[leemgs]

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 <naveenkr...@gmail.com>:

[Anil Sasidharan]

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

[Dave Sparks]

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

[Neo]

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.

> > >> (: Naveen Krishna Ch :)- Hide quoted text -
>
> - Show quoted text -

[ngl]

Hello,

I have the ObtainBuffer timedOut error too.

I use ALSA on SH-mobile processor with Renesas audio codecs.

My Linux Kernel version is 2.6.27 and i use a Cupcake version of
Android.

The message appears:
- sometimes when read wav or midi files (with the player)
- often when read MP3 or OGG files (with the player)
- always when select a new ringtone.

When the message appears, there is no sound on the speaker.

Is there any work around for this issue ?

[Dave Sparks]

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.