About DSP API

[Ethan Brown]

Thank you, Sylvain
If I put the DSP in play mode (B_PLAY_UL) I can send some garbage on
dsp_api.ndb->a_du_1 and the peer will play it, but if I peek the data at
dsp_api.ndb->a_du_0, it's null filled.  If I revert the play mode, I can
see data on dsp_api.ndb->a_du_0.

I will keep trying to find out why DSP API works this way.  I just wanted
to ask if some of you know why this happens.



On Sat, Dec 3, 2011 at 11:31 AM, Sylvain Munaut <246tnt at gmail.com> wrote:

> > So, does the dsp_api.ndb->a_du_0 member hold the audio data to be send to
> > the other peer, or that's something else?  How can I capture the audio
> data
> > (after codec), make a slight modification to that data, and send it to
> the
> > other mobile?
>
> Mmm, I'm not sure you can do that. You can 'peek' at the audio, but by
> the time you see the data there it may have been processed into TCH
> frames already.
>
> When in 'PLAY_MODE', it will take data to send from a_du_1  (in
> TCH/F). So it's possible that the data from the microphone would still
> be in a_du_0 and so you could put it in play mode, do your
> modification by copying data from a_du_0 to a_du_1 ...
>
> As I said : No documentation so it's all been done by error / trial,
> you'd have to try :)
>
> > I can see that AUDIO_TX_TRAFFIC_REQ/AUDIO_RX_TRAFFIC_IND
> > audio mode were created for that purpose, but I'm not sure how to use
> that.
> > Do I need to make the modifications I need on gsm_recv_voice and
> > gsm_send_voice (voice.c)?
>
> Those are used to RX and TX frames from the host (rather than the
> phone directly). The only way to use them "as is" is to interface
> osmocom-bb with LCR (not sure if there is a howto ...).
> But as you saw in voice.c you could modify the code yourself to feed
> data if need be ...
>
> Cheers,
>
>    Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111206/a4e789aa/attachment.htm>