Improve RTPBuffer about ohmcomm

[Kaayy-J]

Improve the buffer:

• Write a super class for the buffer to make it replaceable
• Develop an alternative / improved buffer
• Measure the performance
• Test the behaviour of the buffers on crictical situations
• every second or third package gets lost on transmitting
• a big block of packages gets lost on on transmitting
• all packages gets lost (and then it receives again)
• less packages gets read (buffer overflow behavior)
• Stability test (test the buffers for a longer period) (Test for memory leak)

[Kaayy-J]

Problems to solve:

• Problem / Example 1: Buffer receives packages with sequence numbers 50, 51, 52, 53.
  Afterwards these packages are read. Now the buffer receives the packages with the sequence numbers 54, 48, 49, 55. Since the buffer is on the read position 54 now, the packages 48 and 49 should not be saved anymore.
• Problem / Example 2: How to safe a read position? Read position is the highest sequence number. Sequence number is a 16 bit unsigned int, which is being incremented (by the sender). When the maximum number is reached the sequence number will start at zero again. How to detect this?
• Problem / Example 3: A way to stop reading from the buffer in order to fill it with minimum count of packages (doe300 already has implemented this feature: "minimum number of buffered package before playing audio"). This action is required at the begin of the communication. It can also be required in the middle of the communication when a lot of packages gets lost. Then the playback/reading from the buffer should pause. After the buffer has reached a certain fill stage it can continue.

[doe300]

We need to write test-cases for the three examples from the post above.
Also @Kaayy-J, the new RTPBufferPackage leaks memory (doesn't destroy header-buffer)

[Kaayy-J]

The std::rand generator works terrible. It even should not have the name random number generator.

Anyway, I have tested both buffers (RTPBuffer and RTPBufferAlternative) with an another random generator with 50% percent package lost. The RTPBufferAlternative buffer works quite good compared to RTPBuffer.

[Kaayy-J]

AlternativeBuffer does not work on real enviroment (test with J0n8s).

[doe300]

@Kaayy-J , How did the original RTPBuffer-implementation do in your test?

[Kaayy-J]

It did quite well. We had a very good sound quality.

[doe300]

rewrite one of the two buffer-implementations to solve all the problems in this ticket, including:

• add minimum number of buffered package before playing audio (set playout point)
• make minimum playout point configurable
• make playout point dynamically adaptable
• Test the behavior of the buffers on marginal situations (playout point adaption, correctness of order)
  • every second or third package gets lost
  • a big block of packages gets lost. How does buffer react, if overflow gets lost?
  • less packages read then received (buffer overflow behavior)
  • DTX (see #65) is enabled and packages get lost. What if the marker-package gets lost?