Reg: Implementation of GSM digital audio path

Reg: Implementation of GSM digital audio path

[shariff]

Hi all,

        Iam working on OMAP3 based custom board. On our board, GSM digital
audio path is connected to McBSP3 and
TWL4030 digital audio path is connected to McBSP2.

I want to implement a module that transfers GSM audio data and store audio
data into some buffer and redirect it to TWL4030 audio codec through McBSP2.

I question is how can I implement this in ASoC?

I studied ASoC framework, but I am unable to understand where to implement
my stuff.

Regards,
Shariff

Re: Reg: Implementation of GSM digital audio path

[Peter Ujfalusi]

On Thursday 25 June 2009 12:47:54 ext shariff wrote:
> Hi all,
>
>         Iam working on OMAP3 based custom board. On our board, GSM digital
> audio path is connected to McBSP3 and
> TWL4030 digital audio path is connected to McBSP2.
>
> I want to implement a module that transfers GSM audio data and store audio
> data into some buffer and redirect it to TWL4030 audio codec through
> McBSP2.
>
> I question is how can I implement this in ASoC?
>
> I studied ASoC framework, but I am unable to understand where to implement
> my stuff.

I think the following should do something like that:

arecord -Dplughw:0.0 | aplay -Dplughw:0.1
or
arecord -Dhw:0.0 | aplay -Dhw:0.1

I don't know what is the order of the PCMs with the twl4030 codec on your 
board, this is with the assumption:
plughw:0.0 - Voice PCM (McBSP3)
plughw:0.1 - Digital audio PCM (McBSP2)

You might want to try the --rate parameter for arecord to use 16KHz recording 
from the Voice interface..

>
> Regards,
> Shariff
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
Péter

Re: Reg: Implementation of GSM digital audio path

[Mark Brown]

On Thu, Jun 25, 2009 at 03:17:54PM +0530, shariff wrote:

>         Iam working on OMAP3 based custom board. On our board, GSM digital
> audio path is connected to McBSP3 and
> TWL4030 digital audio path is connected to McBSP2.

In this scenario your GSM modem is essentially functioning as a CODEC
within ASoC.  The simplest thing to do is set up a dummy DAI in your
machine driver for the GSM modem, register that at startup and then set
up a dai_link for that as normal.  You can then address the two streams
individually as devices on the card.

The OpenMoko is doing something similar with its bluetooth chipset,
though that is connected to a second DAI on the CODEC rather than the
CPU.

Re: Reg: Implementation of GSM digital audio path

[shariff]

Hi Peter,

      Thanks for quick response. I understood some what from your mail.

      I will explain, how my hardware is connected.


                        USB GSM chip -> McBSP3

                                                    McBSP2 -> TWL4030

      Here, playback functionality will not be there in the GSM path. I need
to take audio data from GSM. and redirect this
      to TWL4030 codec.

      The thing is, How and where to implement this GSM path without
playback? as I am new to this ASoC framework.

      What I understood from ur mail is.  Audio is being redirected from the
application space i.e arecord will record and store in buffer and this
buffer is

      being played using aplay to other hardware (twl4030).

      Can we handle the same thing in kernel space ( i.e in driver itself).

Regards,
Shariff


On Thu, Jun 25, 2009 at 4:05 PM, Peter Ujfalusi <peter.ujfalusi@nokia.com>wrote:

> On Thursday 25 June 2009 12:47:54 ext shariff wrote:
> > Hi all,
> >
> >         Iam working on OMAP3 based custom board. On our board, GSM
> digital
> > audio path is connected to McBSP3 and
> > TWL4030 digital audio path is connected to McBSP2.
> >
> > I want to implement a module that transfers GSM audio data and store
> audio
> > data into some buffer and redirect it to TWL4030 audio codec through
> > McBSP2.
> >
> > I question is how can I implement this in ASoC?
> >
> > I studied ASoC framework, but I am unable to understand where to
> implement
> > my stuff.
>
> I think the following should do something like that:
>
> arecord -Dplughw:0.0 | aplay -Dplughw:0.1
> or
> arecord -Dhw:0.0 | aplay -Dhw:0.1
>
> I don't know what is the order of the PCMs with the twl4030 codec on your
> board, this is with the assumption:
> plughw:0.0 - Voice PCM (McBSP3)
> plughw:0.1 - Digital audio PCM (McBSP2)
>
> You might want to try the --rate parameter for arecord to use 16KHz
> recording
> from the Voice interface..
>
> >
> > Regards,
> > Shariff
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> --
> Péter
>

Re: Reg: Implementation of GSM digital audio path

[shariff]

Hi Mark,

      Thanks for response.

      On my hardware, GSM is connected to McBSP3 not to the TWL4030 CODEC
directly. What  I have to do is Copy from McBSP3 and redirect this to

      McBSP2.


                        USB GSM chip -> McBSP3

                                                    McBSP2 -> TWL4030

        I have understood some thing from ur mail. I will study Openmoko
ASoC and I will get back to you.

        Suggest me wat else I can do?

Regards,
Shariff

On Thu, Jun 25, 2009 at 4:11 PM, Mark Brown <
broonie@opensource.wolfsonmicro.com> wrote:

> On Thu, Jun 25, 2009 at 03:17:54PM +0530, shariff wrote:
>
> >         Iam working on OMAP3 based custom board. On our board, GSM
> digital
> > audio path is connected to McBSP3 and
> > TWL4030 digital audio path is connected to McBSP2.
>
> In this scenario your GSM modem is essentially functioning as a CODEC
> within ASoC.  The simplest thing to do is set up a dummy DAI in your
> machine driver for the GSM modem, register that at startup and then set
> up a dai_link for that as normal.  You can then address the two streams
> individually as devices on the card.
>
> The OpenMoko is doing something similar with its bluetooth chipset,
> though that is connected to a second DAI on the CODEC rather than the
> CPU.
>

Re: Reg: Implementation of GSM digital audio path

[Peter Ujfalusi]

On Thursday 25 June 2009 14:11:04 ext shariff wrote:
> Hi Peter,
>
>       Thanks for quick response. I understood some what from your mail.
>
>       I will explain, how my hardware is connected.
>
>
>                         USB GSM chip -> McBSP3
>
>                                                     McBSP2 -> TWL4030
>
>       Here, playback functionality will not be there in the GSM path. I
> need to take audio data from GSM. and redirect this to TWL4030 codec.

I see. Sorry I have confused things a bit,
In this case you need to do what Mark has suggested:
dummy dai for the codec, connect it to McBSP3 as it were a normal codec.
Than you will have two PCM on the sound card:
0.0: TWL digital audio
0.1: Your codec

arecord -Dplughw:0.1 | aplay -Dplughw:0.0
or
arecord -Dhw:0.1 | aplay -Dhw:0.0


>
>       The thing is, How and where to implement this GSM path without
> playback? as I am new to this ASoC framework.
>
>       What I understood from ur mail is.  Audio is being redirected from
> the application space i.e arecord will record and store in buffer and this
> buffer is
>
>       being played using aplay to other hardware (twl4030).
>
>       Can we handle the same thing in kernel space ( i.e in driver itself).

You anyway have to copy from one buffer to another to be in the safe side (in 
theory you could use the same buffer for recording and playback, but it should 
be avoided).
So you have to copy the samples from the capture buffer to the playback 
buffer. It really does not matter if it is done inside of the kernel or in 
user space.
This kind of 'routing' clearly belongs to the user space.

>
> Regards,
> Shariff



-- 
Péter

Re: Reg: Implementation of GSM digital audio path

[shariff]

Hi Peter,

         Thanks for your suggestions.

         I have one more question:

         In GSM mode. I have to also take audio data from TWL4030 MIC input
and redirect to GSM.

         From your theory,  If

                          0.0: TWL digital audio
                          0.1: My GSM codec

                          arecord -Dplughw:0.1 | aplay -Dplughw:0.0
GSM to TWL4030.

                          Can I specify,  for TWL4030 to GSM

                          arecord -Dplughw:0.0 | aplay
-Dplughw:0.1            .Is this the correct thing? Can  I both things at
the same time?


        If I want to record a GSM call?  I have to record both the
conversations and copy in one file. since here both the buffers are
independent.

        How this can be done?



Thanks & Regards,
Shariff

On Thu, Jun 25, 2009 at 5:02 PM, Peter Ujfalusi <peter.ujfalusi@nokia.com>wrote:

> On Thursday 25 June 2009 14:11:04 ext shariff wrote:
> > Hi Peter,
> >
> >       Thanks for quick response. I understood some what from your mail.
> >
> >       I will explain, how my hardware is connected.
> >
> >
> >                         USB GSM chip -> McBSP3
> >
> >                                                     McBSP2 -> TWL4030
> >
> >       Here, playback functionality will not be there in the GSM path. I
> > need to take audio data from GSM. and redirect this to TWL4030 codec.
>
> I see. Sorry I have confused things a bit,
> In this case you need to do what Mark has suggested:
> dummy dai for the codec, connect it to McBSP3 as it were a normal codec.
> Than you will have two PCM on the sound card:
> 0.0: TWL digital audio
> 0.1: Your codec
>
> arecord -Dplughw:0.1 | aplay -Dplughw:0.0
> or
> arecord -Dhw:0.1 | aplay -Dhw:0.0
>
>
> >
> >       The thing is, How and where to implement this GSM path without
> > playback? as I am new to this ASoC framework.
> >
> >       What I understood from ur mail is.  Audio is being redirected from
> > the application space i.e arecord will record and store in buffer and
> this
> > buffer is
> >
> >       being played using aplay to other hardware (twl4030).
> >
> >       Can we handle the same thing in kernel space ( i.e in driver
> itself).
>
> You anyway have to copy from one buffer to another to be in the safe side
> (in
> theory you could use the same buffer for recording and playback, but it
> should
> be avoided).
> So you have to copy the samples from the capture buffer to the playback
> buffer. It really does not matter if it is done inside of the kernel or in
> user space.
> This kind of 'routing' clearly belongs to the user space.
>
> >
> > Regards,
> > Shariff
>
>
>
> --
> Péter
>