[alsa-devel] snd_pcm_pause kills plaback handle on OMAP4

[john at johnandjuliet.com]

I added the patch and no go... I added some printks and it is not even
being called.

I am now suspecting the mcpdm side because when I am doing a
pause/resume on the capture handle that the McBSP does become active and
is spitting out white-noise-like samples but no audio.

So that may mean the mcpdm or the 6040 is the problem???

JBP

> -------- Original Message --------
> Subject: Re: RE: [alsa-devel] snd_pcm_pause kills plaback handle on
> OMAP4
> From: Péter Ujfalusi <peter.ujfalusi at ti.com>
> Date: Tue, September 27, 2011 2:37 am
> To: john at johnandjuliet.com
> Cc: alsa-devel at alsa-project.org
> 
> 
> Hi,
> 
> Can you try this patch, if it helps:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-
> September/044227.html
> 
> --
> Péter
> 
> On Friday 16 September 2011 06:31:09 john at johnandjuliet.com wrote:
> > Thanks for the response.
> > 
> > Yea I guess my question is a bit thin and the setup is a bit more
> > complex so I should list the particulars:
> > 
> > * This is on an OMAP4 BLAZE ES2.2 or 2.3 processor
> > * Running Android Linux 2.6.35 from the TI release version G.1
> > * I am actually configuring ALSA to utilize the MODEM audio path
> > (which is hw:0,5 that routes McBSP2 audio to/from the 6040's speaker and
> > mic.)
> > 
> > 
> > * The McBSP is configured for slave mode network SSI with the audio flow
> > on slots 0 and 1
> > (the default was I2S)
> > * McBSP is configured for 8K sps two channel 32-bit samples (though it
> > could be 16 bit samples too)
> > 
> > I guess the way I wrote the first email that I made it sound like it is
> > the McBSP that is not working
> > however it could be that while I am sending in audio perhaps the McBSP2
> > is working (not sure where I could look at data comming in down in the
> > kernel <help plz> but if the McBSP2 is working then it could be that the
> > data is not getting to the 6040?!
> > 
> > > On Wednesday 14 September 2011 11:13:22 john at johnandjuliet.com wrote:
> > > > I'm trying to control the McBSP2 that is used for the modem in an
> > > > android environment (BLAZE OMAP4)
> > > 
> > > What kernel are you using?
> > 
> > 2.6.35 released by TI for Android Gingerbread.  TI tags this as their G1
> > release (they are up to G3 now)
> > 
> > > > What I am trying to do is control the audio paths for capture and
> > > > playback seperatly like in a SIMPLEX (half duplex) instead of full
> > > > DUPLEX mode audio ..
> > > 
> > > So either playback, or capture, but never both at the same time?
> > 
> > Yes.  The device cannot do full duplex.  The ALSA config for hw:0,5 is
> > to route audio from McBSP2 to/from the 6040 (ABE)
> > 
> > The stock Android alsa lib package opens up handles for both capture and
> > playback and then turns on audio hardware both MICs and Speakers.
> > 
> > > > I also want to stop the audio without total
> > > > shutdown of the audio system.
> > > > 
> > > > From what I can see that would be to call snd_pcm_pause(handle,bool)
> > > > 
> > > > But here is what happens.  With the handle forthe plaback path
> > > > everything works OK... But if I call that then the capture path
> > > > stops
> > > > working... even if I try to turn on (unpause) both paths.
> > > 
> > > So you have both playback and capture opened, if you pause the playback,
> > > and release it, then the capture path stops working?
> > > Or you mean that doing the pause/release with playback, then closing it,
> > > after that the capture is not working?
> > 
> > If they are both flowing and I pause capture then playback stops and
> > though I can un-pause capture playback never comes back.
> > 
> > I'll have to double check but I think if I pause playback and then
> > un-pause it... that too breaks and playback never resumes.
> > 
> > > > This implies some sort of bug in the omap soc driver?
> > > 
> > > Everything is possible. I have not heard such about such a problem
> > > myself. If this issue exist on OMAP4, it should be present on OMAP3 as
> > > well...
> > OK.  perhaps though as I just noted I left out that this could actually
> > be a problem on the speaker flow out and not the McBSP2 flow in.. What
> > do you think?  The OMAP4 audio system is much different than OMAP3 on
> > the speaker/mic side so I guess it could be a problem there?
> > 
> > > Could you be more specific on the scenario?
> > > What codec you have attached to McBSP2 port?
> > > Are you using ABE, or are you using the McBSP2 port directly?
> > 
> > I have my own simplex modem connected and it is generating 8ksps audio
> > on slot 0 (first 32 bits) and the McBSP is configured that way.
> > 
> > I am using the ABE to turn on the speaker hardware and the 6040 side of
> > things.
> > 
> > Mostly I am using the TI ALSA layer they provide for Android ALSA audio
> > control and simply placed into it at a key point a snd_pcm_pause() for
> > when I want to turn the capture off or on and another place for the
> > playback to be off or on.
> > 
> > Typically capture and playback are not both on at the same time.. You
> > are either speaking or you are listening.  This is like a CB radio or a
> > Walkie Talkie type of situation.  To save power and also reduce static
> > the speaker is only turned on when the modem on McBSP2 indicates that it
> > wants to play audio and that is when I would do a
> > snd_pcm_pause(playbackhandle,0); when the audio from the modem stops and
> > I get the signal from the modem then I call
> > snd_pcm_pause(playbackhandle,1);
> > 
> > When I want to talk then I do the snd_pcm_pause(capture_handle,0); and
> > when I stop talking then I do the pause on the capture_handle.
> > 
> > I will have to check but I think if I pause EITHER one then playback
> > stops working.  Playback does work if all I do is an open and not mess
> > with it and just do the ALSA set controls to turn on the speaker.
> > 
> > > CC-ing Jarkko to catch his attention...
> > > 
> > > --
> > > Péter
> > 
> > JBP