[gst-devel] lost packets

[Tomasz Grobelny]

In short: is there any gst element that would make up packets that are missing 
from audio stream?

Now the long version:
I send audio data encoded with speex over rtp/udp and then on the other end I 
receive it, decode and send to alsasink. The problem is that the network has 
quite a considerable packet loss (let's say 5% introduced by netem kernel 
module). Every few seconds the audio playback stops and I get something like:

WARNING: from element /pipeline0/alsasink0: Compensating for audio 
synchronisation problems
Additional debug info:
gstbaseaudiosink.c(1190): gst_base_audio_sink_render (): /pipeline0/alsasink0:
Unexpected discontinuity in audio timestamps of more than half a second 
(0:00:00.500000000), resyncing

If I use fakesink instead of alsasink the output looks like this:
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes, 
timestamp: 0:00:02.900000000, duration: 0:00:00.020000000, offset: 43200, 
offset_end: 43520, flags: 0) 0x8151458"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes, 
timestamp: 0:00:02.920000000, duration: 0:00:00.020000000, offset: 43520, 
offset_end: 43840, flags: 0) 0x81514a8"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes, 
timestamp: 0:00:02.960000000, duration: 0:00:00.020000000, offset: 43840, 
offset_end: 44160, flags: 0) 0x81514f8"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes, 
timestamp: 0:00:02.980000000, duration: 0:00:00.020000000, offset: 44160, 
offset_end: 44480, flags: 0) 0x814aed0"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes, 
timestamp: 0:00:03.000000000, duration: 0:00:00.020000000, offset: 44480, 
offset_end: 44800, flags: 0) 0x814ae80"
/pipeline0/fakesink0: last-message = "chain   ******* < (  640 bytes, 
timestamp: 0:00:03.020000000, duration: 0:00:00.020000000, offset: 44800, 
offset_end: 45120, flags: 0) 0x8151548"

As you can see the packet with 0:00:02.940000000 timestamp has been lost. But 
it seems like alsasink cannot correctly handle such a case. Fixing alsasink 
is one way to go. The other would be to use an element that would recreate 
missing packets. They should contain either silence or somehow derive it from 
preceeding and succeeding packets (comfort noise?). Does such an element 
exist? Thanks in advance,
-- 
Regards,
Tomasz Grobelny