posted 02 January 2006 17:18            

I just noticed that when the Flame interface was plugged in the computer, the process kernel_task automatically started to use about 16% of CPU activity, even when no CoreAudio-related application is launched.

Do others noticed this behaviour ?
Is this a thing that is going to be fixed or is it inherent to the Flame?

posted 03 January 2006 01:23            

quote:

---

Originally posted by SSC:
This is the overhead associated with Apple's AV/C code. (Nothing to do with the Flame code)

---

I hope they will do improvements in that area! Because on my PowerBook, it is impossible to use Logic and Kyma together, unfortunately. I've tried hard many times but in the end I lack processing power.

Oh, by the way, in Logic 7, there is a handy plugin called I/O which is perfectly fitted for using the Capybara for effect processing. You use the plugin on the track you want to process, choose the input/output (actually virtual send/return with Kyma), and that's it.
I've tried and it shows it can work (well, sort of). When the AV/C driver will be more streamlined, I guess it will work better.

posted 03 January 2006 07:24            

To answer your question, I think it is fairly easy if you have a DAW that supports AU plugins. In Logic 7 for example, you can use an AUX track with inputs from and outputs to the Kyma. Instead of an AUX track you can also merely use an AUDIO track, but you'll have to record enable the track.

You can use a stereo track to process a stereo signal or as may mono tracks as you may need. I don't know if Logic 7 support 5.1 tracks, though.

This is the inverse logic of the I/O plugin which allow to use Kyma effect in a Logic track.

A last thing : there are plugin latency issues to consider when using host based plugins. I have not tested anything here, but I guess that running parallel input/outputs in different AUX tracks may not be without problems ... or perhaps the CoreAudio subsystem manages all that and keep in sync both Logic and Kyma?

posted 03 January 2006 08:37            

Just had an idea. If you activate Logic's full PDC (plugin delay compensation) and send the Kyma sounds you want to process to say aux 1, and you send any parallel Kyma sounds (that you don't want to process) to aux 2, I'm pretty sure they would return to Kyma with the same PDC applied as the processed sounds, so they would return perfectly in sync right? I'll have to test it out... : )

posted 03 January 2006 09:08            

I guess that most of the algorithms can use the same value whereas FFT based calculations must take in account the window size, isn't it?

posted 03 January 2006 22:41            

Using the the IO plugin, I take audio from a channel send it to Kyma, do a basic invert process (multiple by negative one) and send it back. I have the same audio running on a parallel track and try to get the sounds to cancel out.

The problem is the IO plugin stops becoming sample accurate after a buffer of 2048 samples and then moves to a hundredth of a second, anyhow, roundtrip latency was somewhere around 2000 milliseconds (I don't have Logic front of me but it was somewhere near that). It was stable from instance to instance.

My system is a powerbook 1.25, 1G ram, Logic Audio Pro 7.1.1 at 512 buffers.

posted 04 January 2006 03:10            

I did some (rough) testing yesterday, and I can tell the roundtrip latency via the I/O plugin is really not that bad. However my tests where cluttered as my computer was very slow, because of all the FireWire streams, Logic and Kyma running together ...
I will try 3 configurations (audio track latency, I/O plugin latency and aux track latency) and measure them all. I'll keep everyone informed. Obviouly, it is good to share our results in the Tweaky.

posted 04 January 2006 12:01            

DelayTest.zip

The Kyma Sound sends a signal out external out 1 and compares it to a signal coming back in on external in 1. The signal is delayed inside Kyma by the amount given by the !Delay fader and that delayed signal is displayed along with the external input signal in 2 oscilloscope displays.

Rax had its buffer size set to 64 samples. We found that the delay through Rax is three times the buffer size: changing the Rax buffer size from 64 samples to 256 samples increased the delay to 46.5 milliseconds (an increase of 13.1 milliseconds or 576 samples).

posted 11 January 2006 16:54            

I also have a rise in Kernel Tasks CPU usage up from 10% to :

19% When running Kyma
17% running Ableton Live
21% running Logic Pro