Re: Bug report: etm consumes too much CPU
Kai Vehmanen <[email protected]>
| Newsgroups | gmane.comp.audio.ecasound.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] https://lists.sourceforge.net/lists/listinfo/ecasound-list