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/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)