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


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


>
>
> >
>


-- 
Thanks,


(: Naveen Krishna Ch :)

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to