Time delay in setting property & audio mixer element

[Pietro Battiston]

Il giorno sab, 28/05/2011 alle 20.07 +0300, Marco Ballesio ha scritto:
> Hi,
> 
> another late reply from my famous series, bte find my comment(s)
> below..


Being arrived when I had a bit lost my hope, it's even more
appreciated...


> 
> On Fri, May 20, 2011 at 7:21 PM, Pietro Battiston
> <me at pietrobattiston.it> wrote:
> ..snip..
> 
>         4) am I missing something else (in the end, it's been few days
>         since I
>         first programmed with gstreamer)?
>         
> 
> latencies can come fro various places... how are you measuring it?
> (e.g. you have an oscilloscope connected to the speakers).

First off, sorry, I did a clear error in the last mail: the latency I
observe is around 150 (not 30) ms.

To approximately measure it, that's what I do: I run my simple script on
a touchpad, start moving the finger up and down regularly until I'm able
to be perfectly out of sync (the highest pitch being reached when my
finger is lowest, and vice-versa), and then verify that I was moving up
& down ~ 3 times per second ==> the lag is ~1/6 of second.


That said, I realize not everyone has a touchscreen at hand, so if you
want to reproduce, I modified


git clone git://pietrobattiston.it/fingerpicking -b minimal
cd fingerpicking
python finger.py

so that now just clicking/releasing the mouse on the window changes
note. On my system, the delay is clearly noticeable.

> As a note, you should check the overall latency in the whole pipeline,
> but most probably, if you're using pulseaudio, it's in pulsesink that
> you should focus (try tweaking buffer-time and latency-time,
> defaulting to about 10ms multiples).

I'm using alsa directly...

> 
> Another influence factor is the size of the buffers wrt the sample
> rate you're using in the source element: obviously, the smaller
> buffers the lower latencies. audiotestsrc has default blocksize set to
> 4096, default sample rate set to 44100Hz, that is about 22 ms of
> latency. Combined with the default pulsesink latency of above, rounded
> up to the 10ms multiples, we've pretty much the 30ms you've been
> measuring.
> 

I tried to call set_property( 'blocksize', 1024 ) and lower values, but
apparently nothing changed... (do I misunderstand your point?)


> Btw I doubt you'll ever be able to get latencies lower than a few
> multiples of 1/HZ
> (http://www.unix.com/linux/48694-kernel-how-modify-read-tick-rate-hz.html), especially if dealing with the CFS..
> 
> 
>         Or more in general: do you suggest that gstreamer can do what
>         I want or
>         am I using the wrong tool?
> 
> it depends on your target latency (see above), for sub-millisecond
> values one might even argue about the opportunity to use any
> non-realtime approaches ;)


I would just like something that a user would generally not notice... I
guess that something like 30 ms. in fact would be perfectly fine.



>  
>         
>         While I'm at it, another question: I searched for some element
>         doing the
>         inverse of "tee" for audio. I found a discussion on the
>         argument:
>         http://gstreamer-devel.966125.n4.nabble.com/aggregator-element-td973247.html
>         which however was dropped. Dan:
>         http://gstreamer-devel.966125.n4.nabble.com/aggregator-element-td973247.html#a973254
>         proposed several "interpretations" of that request, and what I
>         need is
>         precisely the last: "For audio-only mix the inputs to one
>         output, like a
>         multi-track studio mixer? ". Is there such an element?
>         
> 
> here you go:
> 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-adder.html
> 


thanks a lot

Pietro