[gst-devel] const properties during buffer processing

[Thomas Vander Stichele]

Hi,


> during the weeksend I did a little cleanup on GstVolume [1]. It uses
> multiple processing functions (2) that are switched via function pointers.
> I wanted to add a third one for the volume=0.0 case that uses memset. Now
> the downside of this would be that when one sets volume to zero while a
> buffer is beeing processed the old function would still achie the right
> thing (but be slower). With the next buffer the memset variant becomes
> active and if then one changes the volume back (or unmute) the chenge would
> only become effective for the next buffer.

I think this was already discussed, and was agreed to not be such a big
problem.  Consider that a) you have no control over exactly when the
processing loop of volume is being executed and b) that it's being
executed very quickly anyway (not spread out over the time in between
two buffers) there's not a lot you can do in a live situation anyway.

However, it was also agreed that:
a) volume should probably be changed to use array multiplication, so
that this can be made very fast with liboil
b) volume should have a controllable volume, and it should obviously
respect changes on a smaller-than-buffer scale

So if you want to change volume, I would suggest going that way instead.
the memset() is an optimization that I'm not sure is even necessary
(volume doesn't seem to consume much CPU), and I'm also not sure if you
can interpret zero bytes as 0 in float, if we ever add float to volume.


> Has anyone an idea of average buffer sizes (e.g. when decoding mp3/ogg)?

mp3 normally has 1152 samples for each channel per frame, so for 44.1 Hz
that comes out to around 25 ms.  I don't remember how it works offhand
for Vorbis, but IIRC every stream can have two possible frame sizes
defined, with the largest being no more than 8192 samples.

Thomas