8 Sep
2017
8 Sep
'17
2:30 p.m.
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.
8 Sep
8 Sep
3:16 p.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10 Sep
10 Sep
3:52 p.m.
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.
3 Dec
3 Dec
8:11 p.m.
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:
Thanks, this would indeed be very useful (also to validate the MMX code as
mentioned above)
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. 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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:22 p.m.
New subject: gapk now in gerrit (Re: GAPK status update)
Hi Vadim,
On Sun, Dec 03, 2017 at 08:11:58PM +0100, Harald Welte wrote:
As Sylvain agreed on IRC, I've migrated gapk to gerrit:
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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.
2342
days inactive
2428
days old
4 comments
2 participants
participants (2)
-
Harald Welte -
Vadim Yanitskiy