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

Reply via email to