[gst-devel] How to decrease CPU consumation for audio recording?

[Marco Ballesio]

Hi,

On Thu, Oct 7, 2010 at 8:56 PM, Gruenke, Matt <mgruenke at tycoint.com> wrote:

>
>
> > Felipe's diagrams are clearly showing that the degradation is O(e^n)
>
>
>
> Actually, that’s not clear to me, as his plot was log(x), y.  That’s why I
> asked about plotting throughput vs number of elements or queues.  Even using
> a linear x axis would be more enlightening.
>

right, I should have checked the scales and your email as well before
highlighting an exponential growth. Still the point of the growing
complexity wrt the number of buffers keeps, and also the difference in the
curve between ARM and x86 is something which deserves more than one though.



>
>
>
>
> I also agree with Wim that the effects of the queue are exaggerated in a
> trivial pipeline on an idle system.  In higher-load situations, you would
> tend to have fewer context switches, which are probably the largest cost.
>

I'd like to check whether similar effects are present even with elements
like resamplers with the same caps on sink and source pads.


>
>
> I think a lockless queue wouldn’t help with this scenario, since you’d
> still want to wake up a consumer that’s waiting on an empty queue (which
> requires a lock + condition variable).  Where lockless helps is to scale
> throughput in higher load scenarios.
>

well, I was considering something more radical than removing locks only from
the queue. I have to search a simple patch were I removed all of the locks
from pad_push, getting measurable benefits (I'm not proposing it as a
solution, but something to reflect about). For sure, I'll be talking just
about fresh air until I'm able to provide a few diagrams, I know :P.


>
>
> If you could afford some latency, then perhaps batching could be
> implemented by having the consumer block until the queue either reaches some
> watermark or a timeout expires.  When either of these conditions is met, the
> consumer empties out the queue and goes back to waiting.
>
>
>

GStreamer VoIP latencies are already proven to be at the limit with many
standard and industrial requirements, at least on ARM (to be fair, it's also
because of pulse and its interfaces). I wouldn't suggest to go for solutions
which involve bigger latencies.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101007/3a6e8f82/attachment.htm>