On Wed, 2007-11-28 at 16:52 +0100, David Olofson wrote:
> On Wednesday 28 November 2007, Krzysztof Foltman wrote:
> [...]
> > I don't think it's a serious problem. Huge processing buffers are
> > not very useful in practice.
> [...]
>
> Actually, they're directly harmful most of the time!
>
> For any graph with more than one plugin, and with plugins that use
> internal buffers of the I/O buffer size, large buffers means you'll
> get a gigantic cache footprint. It gets worse in "high" latency real
> time situations (games, media players etc), where you have other
> threads fighting for the cache as well.
>
> Obviously, this effect is less visible with non-trivial plugins - but
> even how many plugins in a "normal" graph are actually CPU bound? In
> my experience, the effect is very pronounced (several times higher
> CPU load with 512 samples/buffer than with 32) when using a bunch of
> sampleplayer voices (cubic interpolation + oversampling) and some
> simple effects. You have to do some pretty serious processing to go
> CPU bound on a modern PC...
Not really true for linear scans through memory, which reading plugin
buffers usually is. This is the ideal cache situation, and you can
definitely get full utilization sweeping through things much larger than
the cache this way (this is exactly what the cache is designed to do,
and it does it well; try it).
When you're jumping all over the place things do go to hell fast, but
luckily we're not.
-DR-
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 29 00:15:03 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 00:15:03 EET