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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
