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.
> So, does the dsp_api.ndb->a_du_0 member hold the audio data to be send toMmm, I'm not sure you can do that. You can 'peek' at the audio, but by
> 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?
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 :)
Those are used to RX and TX frames from the host (rather than the
> 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)?
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