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?<br>
<br><br><br><div class="gmail_quote">On Tue, Dec 6, 2011 at 10:04 AM, Sylvain Munaut <span dir="ltr"><<a href="mailto:246tnt@gmail.com">246tnt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> If I put the DSP in play mode (B_PLAY_UL) I can send some garbage on<br>
> dsp_api.ndb->a_du_1 and the peer will play it, but if I peek the data at<br>
> dsp_api.ndb->a_du_0, it's null filled.  If I revert the play mode, I can see<br>
> data on dsp_api.ndb->a_du_0.<br>
<br>
</div>I guess the play ul both enables the tx from a_du_1 and also disables<br>
the audio compression stuff ...<br>
You can try to modify the content of a_du_0 at the time of the<br>
interrupt without leaving but I'm not sure it'll work or if the dsp<br>
will already have taken the data ...<br>
<br>
Cheers,<br>
<font color="#888888"><br>
    Sylvain<br>
</font></blockquote></div><br>