This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Ethan Brown evandersh at gmail.comI 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111208/33493b7c/attachment.htm>