Do any of you know where can I find documentation about the DSP API used in Osmocom?
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? 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)?
On Fri, Dec 2, 2011 at 5:50 PM, Sylvain Munaut 246tnt@gmail.com wrote:
Do any of you know where can I find documentation about the DSP API used
in
Osmocom?
Nowhere. There is no doc. (Not that we have access to anyway ... I'm sure Texas Instruments has it ...)
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
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@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
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 guess the play ul both enables the tx from a_du_1 and also disables the audio compression stuff ... You can try to modify the content of a_du_0 at the time of the interrupt without leaving but I'm not sure it'll work or if the dsp will already have taken the data ...
Cheers,
Sylvain
I decided to test another route, writing on socket /tmp/ms_mncc_1 data with the gsm_data_frame structure. I see that this socket expects GSM FR data, and setting the audiomode to AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND. It seems that the peer receives this data, but I cannot hear the audio correctly. Am I missing something? Was this feature tested before?
On Tue, Dec 6, 2011 at 10:04 AM, Sylvain Munaut 246tnt@gmail.com wrote:
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 guess the play ul both enables the tx from a_du_1 and also disables the audio compression stuff ... You can try to modify the content of a_du_0 at the time of the interrupt without leaving but I'm not sure it'll work or if the dsp will already have taken the data ...
Cheers,
Sylvain
I decided to test another route, writing on socket /tmp/ms_mncc_1 data with the gsm_data_frame structure. I see that this socket expects GSM FR data, and setting the audiomode to AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND. It seems that the peer receives this data, but I cannot hear the audio correctly. Am I missing something? Was this feature tested before?
Yes, it's used in the LCR integration and works fine, so you must be doing something wrong.
Note that you must make sure to disable EFR support in the config or the network might assign you a EFR channel and you send FR data which is not going to work out ...
Cheers,
Sylvain
As you said, I was doing something wrong. Sorry, my mistake. It works perfectly now.
By the way, I wanted to include AMR support. What should I do to make this possible?
On Thu, Dec 8, 2011 at 3:27 PM, Sylvain Munaut 246tnt@gmail.com wrote:
I decided to test another route, writing on socket /tmp/ms_mncc_1 data
with
the gsm_data_frame structure. I see that this socket expects GSM FR
data,
and setting the audiomode to AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND. It seems that the peer receives this data, but I cannot hear the audio correctly. Am I missing something? Was this feature tested before?
Yes, it's used in the LCR integration and works fine, so you must be doing something wrong.
Note that you must make sure to disable EFR support in the config or the network might assign you a EFR channel and you send FR data which is not going to work out ...
Cheers,
Sylvain
By the way, I wanted to include AMR support. What should I do to make this possible?
No idea ... that's why it's not done, I have not yet analyzed how the DSP must be driven to handle AMR. I think it doesn't support it natively (or at least is bugged) and some DSP patches must be loaded.
Cheers,
Sylvain
Inside the socket client, I don't have access to the osmocom_ms instance, so I cannot make/answer calls. How did you do that in your LCR integration?
On Fri, Dec 9, 2011 at 9:01 AM, Ethan Brown evandersh@gmail.com wrote:
As you said, I was doing something wrong. Sorry, my mistake. It works perfectly now.
By the way, I wanted to include AMR support. What should I do to make this possible?
On Thu, Dec 8, 2011 at 3:27 PM, Sylvain Munaut 246tnt@gmail.com wrote:
I decided to test another route, writing on socket /tmp/ms_mncc_1 data
with
the gsm_data_frame structure. I see that this socket expects GSM FR
data,
and setting the audiomode to AUDIO_TX_TRAFFIC_REQ |
AUDIO_RX_TRAFFIC_IND.
It seems that the peer receives this data, but I cannot hear the audio correctly. Am I missing something? Was this feature tested before?
Yes, it's used in the LCR integration and works fine, so you must be doing something wrong.
Note that you must make sure to disable EFR support in the config or the network might assign you a EFR channel and you send FR data which is not going to work out ...
Cheers,
Sylvain
baseband-devel@lists.osmocom.org
-
Ethan Brown -
Sylvain Munaut