Age | Commit message (Collapse) | Author | Files | Lines |
|
We used the wrong length constant during encoding of RTP-HR IETF style.
|
|
While EFR has a canonical format of 31 bytes, the codec_efr.c *does not*
use that canonical format as input. Rather, it uses the format of .amr
files with a 0x3C header as first byte. So the resulting encode/decode
functions should not assume 31 bytes, but 32 bytes.
|
|
This will permit for a more graceful error than the next element in the
processing chain complaining that there's a 0-length input.
|
|
|
|
|
|
The tool has the capability to be used in a pipe, so stdout should
recevie nothing else but actual codec/pcm data.
|
|
I noticed that ti-hr format doesn't pass an encode-decode-playback test,
and discussion with tnt resulted in the following conclusion:
19:29 <@tnt> looking at fr and efr, it's always msb_xxx
19:30 <@tnt> and if I ever used it, then most likely it was for decoding
meaning ti_hr_to_canon would have been used and not the
other way around.
|
|
|
|
This is incompatible with the ETSI TS 101 318 format!
|
|
|
|
The RTP EFR payload is a bit like the FR payload: one nibble magic
marker, then followed by the actual codec bits. So we need to
add/remove that magic marker and shift the remainder by one nibble.
|
|
The ETSI reference codec actually uses an array of 20/22 16bit values
rather than a "canonical" format. The conversion is what fmt_hr_ref.c
is doing. However, codec_hr.c must then subsequently not check for the
canonical input/output sizes, but those specific to it.
|
|
|
|
|
|
After merging this change, there is support for the AMR codec (by means
of libopencore-amr, which is already used for EFR).
In terms of gapk formats, we introdude
* the "amr-opencore" format, which serves both as the canonical format,
and as the input format to opencore-amrnb itself.
* the "rtp-amr" format, which is the payload of RFC4867 octet-aligned mode
You can use the following command for a real-time RTP playback for AMR
frames:
./gapk -I 0.0.0.0/30000 -f rtp-amr -A default -g rawpcm-s16le
|
|
|
|
The existing architecture was modelled around fixed-length codec frame
sizes, which of course fails with multi-rate codecs such as AMR.
|
|
|
|
The ALSA source/sink uses the pcm-s16le format.
|
|
In fact, it should probably be better to silently ignore all those
errors as opposed to aborting the entire processing queue? But that's
for another patch...
|
|
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Basically the reference code has a bunch of global state.
With some minimal patchihg (previous commit) we can ensure that all
that state is within .bss
So what we do it to save/restore the bss section between calls of the
reference code so we can process several in // and we don't have to
completely fix all reference to global state in the reference codec.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Mostly this will help witht the upcoming bss switcheroo patch
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Patches are without function-name and without context to minimize what
we have to include.
The current patchset does exactly what the previous 'sed' did, but this
will make it easier to add more.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
There shouldn't be any but somebody might be nasty :p
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
They won't be supported anyway when using the 'bss switcheroo' hack
for libgsmhr
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
stdout can be used for data output ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
|
|
|
|
This enables benchmarking of the codec. It will print
the amount of CPU cycles needed for encoding/decoding a single
20ms frame on average.
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Since automake 1.13 INCLUDES is depricates and causes a warning
Inspired from similar patches by Alexander Huemer for other osmocom
projects
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
This is useful particularly in case you are reading from RTP and writing
to a file, and don't want truncated codec frames in your file.
|
|
Instead of having only file-based I/O, this enables gapk to receive and
send RTP streams, e.g. from live GSM network equipment like
sysmoBTS/nanoBTS.
Support is currently simplistic. On transmit, there is hard-coded codec
type of full-rate GSM. On receive-side, we should auto-detect the
format based on frame size and/or payload type, but we don't do that yet
at all.
|
|
this is done in preparation to provide something else but file
input/output.
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Obvious typo ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
32 is the normal value
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|