Talking clock - timestamp problem?

[David Holroyd]

Hi,

On 24/08/14 00:35, David Holroyd wrote:
> On 20/08/14 23:11, Tim Müller wrote:
>> On 18/08/14 22:11, David Holroyd wrote:
>>> I am trying to build a pipeline something like a 'talking clock',
>>> continually announcing the current date and time as test input to
>>> another system.

>> Perhaps have two separate pipelines, connected via interaudiosink/src
>> elements:
>>
>>    interaudiosrc ! ... ! rtpL24pay ! udpsink
>>
>> and then
>>
>>    appsrc ! festival ! wavparse ! ... ! interaudiosink
>>

> I almost have interaudio* working, but with much audio popping.
>
> When I run the pipelines with GST_DEBUG=4, I see that interaudiosrc is
> inserting silence inbetween pieces of audio,
>
> 0:00:11.848882460  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:282:gst_inter_audio_src_create: flushing 800 samples
> 0:00:11.948906569  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:282:gst_inter_audio_src_create: flushing 800 samples
> 0:00:12.048877221  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:300:gst_inter_audio_src_create: creating 512 samples of silence
> 0:00:12.083871396  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:282:gst_inter_audio_src_create: flushing 800 samples
> 0:00:12.183945130  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:300:gst_inter_audio_src_create: creating 1056 samples of silence
> 0:00:12.213834049  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:282:gst_inter_audio_src_create: flushing 800 samples
> 0:00:12.313945515  8197  0x267d5e0 WARN   interaudiosrc gstinteraudiosrc.c:300:gst_inter_audio_src_create: creating 1056 samples of silence

I hacked-out the entire test that does gst_adapter_flush() in 
gst_inter_audio_src_create(), which seems to have improved things greatly:

    g_mutex_lock (&interaudiosrc->surface->mutex);
    n = gst_adapter_available (interaudiosrc->surface->audio_adapter) / 4;
+/*
    if (n > SIZE * 3) {
      GST_WARNING ("flushing %d samples", SIZE / 2);
      gst_adapter_flush (interaudiosrc->surface->audio_adapter, (SIZE / 
2) * 4);
      n -= (SIZE / 2);
    }
-  if (n > SIZE)
+*/
+  if (n > SIZE) {
+    GST_WARNING ("Only using %d of %d available samples", SIZE, n);
      n = SIZE;
+  }
    if (n > 0) {
      buffer = gst_adapter_take_buffer 
(interaudiosrc->surface->audio_adapter,
          n * 4);

I'm not confident I follow the interaudiosink/interaudiosrc code, but 
maybe there's an assumption that the number of samples delivered will 
always be 'small', which is invalid in this case?

There are still instances where silence is inserted, but they are much 
fewer now -- maybe when the last buffer from upstream has finished being 
consumed but the next has not yet arrived at the adapter.

Any way I could make the interaudiosrc-side pipeline wait a little 
longer for data to build up?

Or could I adjust the interaudiosink-side to send smaller buffers, more 
frequently?


ta,
dave