Dear Osmocom community,
I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements.
Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback.
One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support.
Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet.
Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects.
Brief list of changes were made:
- Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist
- Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file
- Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check
All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;)
With best regards, Vadim Yanitskiy.
Hi Vadim,
On Fri, Sep 08, 2017 at 03:30:05PM +0300, Vadim Yanitskiy wrote:
Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects.
I like this very much. Actually, this could even be used by something like the new osmo-mgw to have more or less generic transcoding capabilities for gsm-related codecs as well as PCM / G.711.
comments: * the new introduced memory allocation could have been done via talloc, but since it's just for the non-standard benchmarking case, calloc is ok. * it would be nice to convert all allocations to talloc, like in other osmo-* code. This facilitates memory leak debugging. * rather than listing all symbols individually, you can also simply export osmo_gapk_* with a wilcard. All non-exported symbols then have to avoid that prefix. I prefer this to long lists of symbols that you often forget to update when adding new functions * assuming you have multiple processing queues in a program in the future, each queue should have a user-settable identifier which is then used as a prefix in all the logging.
Finally, as a personal wishlist item, I would love to see some unit tests that create a couple of processing queues, destroy them, check if the resulting encode/decodes is what was expected, and [if possible?] even check if allocated memory has been properly cleaned up during destruction of the processing queue.
Let's see what Sylvain has to say about all of this, it's his creation after all :)
Regards, Harald
Hi Harald,
I like this very much. Actually, this could even be used by something like the new osmo-mgw to have more or less generic transcoding capabilities for gsm-related codecs as well as PCM / G.711.
Thanks for your response! Hope my recent commits would help to move this forward.
- it would be nice to convert all allocations to talloc, like in other osmo-* code. This facilitates memory leak debugging.
- rather than listing all symbols individually, you can also simply export osmo_gapk_* with a wilcard. All non-exported symbols then have to avoid that prefix. I prefer this to long lists of symbols that you often forget to update when adding new functions
- assuming you have multiple processing queues in a program in the future, each queue should have a user-settable identifier which is then used as a prefix in all the logging.
Done.
Only libgsmhr do use generic malloc / free calls. And I think there is no reason to link this library against talloc as there is only one allocation / deallocation cycle.
BTW: what about the 'laforge/mmx' branch? Does anything prevents us from merging it to the master?
Finally, as a personal wishlist item, I would love to see some unit tests that create a couple of processing queues, destroy them, check if the resulting encode/decodes is what was expected, and [if possible?] even check if allocated memory has been properly cleaned up during destruction of the processing queue.
Yeah, I have this idea too. But I don't have enough time right now. Will do it as soon as it will be possible. What do you think about adding GAPK to Gerrit?
Regarding to the proper memory deallocation check, I think it should be possible via the talloc debugging API.
With best regards, Vadim Yanitskiy.
Hi Vadim,
[as you requested a response on IRC, sorry for dropping the ball]
On Sun, Sep 10, 2017 at 04:52:55PM +0300, Vadim Yanitskiy wrote:
Only libgsmhr do use generic malloc / free calls. And I think there is no reason to link this library against talloc as there is only one allocation / deallocation cycle.
correct.
BTW: what about the 'laforge/mmx' branch? Does anything prevents us from merging it to the master?
I think it wasn't fully validated yet, so I think unless somebody hacks up a test suite or some other means that make us confident that the MMX optimized version produces the same results as the standard one, we shouldn't merge it.
Finally, as a personal wishlist item, I would love to see some unit tests that create a couple of processing queues, destroy them, check if the resulting encode/decodes is what was expected, and [if possible?] even check if allocated memory has been properly cleaned up during destruction of the processing queue.
Yeah, I have this idea too. But I don't have enough time right now. Will do it as soon as it will be possible.
Thanks, this would indeed be very useful (also to validate the MMX code as mentioned above)
What do you think about adding GAPK to Gerrit?
Fine with me. But then, it's Sylvain's project and I wouldn't want to do anything to it that he isn't asking for / approving of.
Regards, Harald
Hi Vadim,
On Sun, Dec 03, 2017 at 08:11:58PM +0100, Harald Welte wrote:
What do you think about adding GAPK to Gerrit?
Fine with me. But then, it's Sylvain's project and I wouldn't want to do anything to it that he isn't asking for / approving of.
As Sylvain agreed on IRC, I've migrated gapk to gerrit:
-
Harald Welte -
Vadim Yanitskiy