Until now, the osmux_out_handle was allocated by the client, and passed
to the API to initialize it. This makes it really hard to improve the
implementation without breaking the ABI.
Let's break the ABI now one last time (hopefully) by allocating the
struct through an API. With only this change, the already built users
(osmo-mgw, openbsc) can still work fine, since there's no change on the
struct osmux_out_handle. However, they will somehow break next time the
struct is changed until they are ported to the same API (easy to do).
Related: OS#5987
Change-Id: Ie8df581f375c9a183a7af60b431561bda82f6e34
osmux implementation randomizes those values. It seems build in OBS
sometimes provide different values than the ones expected in the test
result. Let's hardcode them to make sure we always have the same values
regarless of the random() implementation.
Values chosen are the one matching the current expected test output so
it doesn't need any change.
Change-Id: Icc553c83ddff41900ae3d5990a655c29c9073e01
Currently osmux related code uses both gettimeofday on some parts and
clock_gettime(CLOCK_MONOTONIC) on others (for different purposes).
Let's fake both clocks and not only the one used by gettimeofday API.
Change-Id: I4e1a0eb4f8c4ea1bc0f963afa18b116d3af9978c
Previously payload_type was always hardcoded to 98 for generated rtp
packets from incoming osmux frame.
Change-Id: I5cbeb494a8932953d9fd2dc24dacf8cd97fd84e4
Until this patch, we didn't notify in any way to the RTP reader when an
Osmux frame was lost. Instead, we updated the seq×tamp as if there
was no lost, and as a result the RTP reader would only see a steady
increase of delay every time an osmux frame was lost.
As the batch_factor for the lost packet is unknown, we cannot assume any
number of amr payloads lost, and thus we cannot simply increment seq and
timestamp for a specific amount. Instead, the only viable solution seems
to set the M marker bit in the first rtp packet generated after a
non-consecutive osmux frame is received.
The implementation may act differently with the first generated RTP
packet based on the first osmux seq number used for the stream. In case
0 it's used as first osmux seq number, M will be set depending on
request from original RTP packet having the M bit set. If it's not 0,
the first RTP packer will unconditionally have the M bit. That's not an
issue because it's anyway expect for receiver to sync on the first
packet.
Related: OS#3185
Change-Id: I2efed6d726a1b8e77e686c7a5fe1940d3f4901a7
SNPRINTF_BUFFER_SIZE() looks too complex, previous version maintains two
different variables to account for the remaining space in the buffer,
one of them is always decremented based on what snprintf() returns,
which may result in underflow. These variables are swapped - not used
consistently - all over this code.
Replace this macro by a simplified version, with one single parameter to
account for remaining space. This macro also deals with two corner
cases:
1) snprintf() fails, actually never happens in practise, but
documentation indicates it may return -1, so let's catch this case
from here to stick to specs.
2) There is not enough space in the buffer, in that case, keep
increasing offset, so we know how much would have been printed, just
like snprintf() does.
Thanks to Pau Espin for reporting, and Holger for clues on this.
I have run osmux_test and, at quick glance, it looks good.
Change-Id: I5b5d6ec57a02f57c23b1ae86dbd894bad28ea797
The buffer for osmux_test is increased as the former doesn't seem to be
able to cope with the whole output.
Change-Id: Ic838dd9d7ad89b4510ccfa58c0390c69a075b616
According to RFC4867 (RTP payload format for AMR):
"The RTP header marker bit (M) SHALL be set to 1 if the first frameblock
carried in the packet contains a speech frame which is the first in a
talkspurt. For all other packets the marker bit SHALL be set to zero (M=0)."
This information bit provides a way for the receiver to better
synchronize the delay with ther sender.
This is specially useful if AMR DTX features are supported and
enabled on the sender.
Change-Id: I0315658159429603f1d80a168718b026015060e9
Introduce a local #define to disable the real-time constraint from osmux-test.
It would make sense to remove this completely, but in case anyone may be
interested in the timing on a specific platform, I've just #defined it away.
The real-time constraint to pass or fail the test is a bad idea in terms of our
build server. Whenever the server is loaded, the tests will fail for no reason,
like here: https://gerrit.osmocom.org/474
The real time to calculate is highly dependent also on the hardware platform.
The arbitrarity of the time constraint is sort of proven by dd24cdd95f
which simply doubles the time to pass the test.
Change-Id: Ic1da4bd22411652334f73195b2e37853e0738906
With the fan-out approach to test multi-batch added int (078d532 tests:
osmux: test multi-batch support), this doesn't need the explicit
skip as there are already gaps to be filled.
This patch adds the testsuite infrastructure and it populates it
with one test for osmux.
The osmux tests makes sure that:
* We get the same number of RTP messages in the input and the output path.
* The payload of the RTP message is reconstructed correctly.
* The reconstructed timing is correct.
Pau Espin
Neels Hofmeyr
Neels Hofmeyr