Hi,
On Sat, 19 May 2012, S. Massy wrote:
> Within the context of investigating ways to perform latency compensation
> in nama, I ran the following test. I created a chain setup with a
> hundred chains with rtnull at either end and a delay op on each,
> either etd or etm. With etd, I only get a slight overhead (about 3% on
> my 2.26ghz dual-core processor), while etm goes right through the roof
> and has tonnes of xruns. I figure that can't be right. Please find the
I digged this a bit and this seems to be a downside of how "-etm" is
implemented. It iterates the channels separately, and with many/most
data sets, this makes it much (2x to 3x) slower than "-etd".
OTOH, I think both "-etd" and "-etm" are a bit too complicated and
special-purpose for simple delay compenstation use. I did a quick
benchmark of a few LADSPA delay lines, and many are much faster. I'd
suggest using e.g. "delay_n" (from swh-plugins) or "delay_5s" (from
ladspa-sdk). These are faster than any ecasound delay op, and are
installed on most people's machines.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sat May 26 16:15:03 2012
This archive was generated by hypermail 2.1.8 : Sat May 26 2012 - 16:15:03 EEST