I’m noticing quite a bit of lag in the sound data that I’m using to trigger animations (live audio, line in). I don’t know this is a CPU-based delay or to do with drivers. A bit of an issue, since audio sync is the structure of the whole project.
Have tried:
Different connection methods (via computer in/out, and monitor to the computer only through a mixer);
Limiting the size of the FFT spreads;
Boosting performance by using GPU targetmode (the machine has 3 cards, with a weaker one for monitoring), but this is only available on beta31.2, on which one of the patches doesn’t load tables properly, but gives no errors either – looking through the addons now).
The device drivers are the default ones, so, not much I can do there. Anybody experienced similar issues?
It’s tricky to post something that accurately illustrates what I’m doing, as it is a fairly complex patch (and there lies, I suspect, part of the problem). But I’ve recreated the essentials of the audio part. Also, this will probably have different results with every system (I don’t know, however, to accurately measure sound latency in vvvv).
Data flow description: computer 1 sends all data (audio, OSC control messages, and other spreads) to computer 2. It processes that information for its own animations as well.
Sound set-up: mp3 player is connected to a mixer; mixer outputs signal to LineIn/Microphone in of the PC1 audio card, and to external speakers. Alternative: MP3 player is connected to Line In and Mixer is gets audio signal from the speakers port of PC1 (same difference).
Now, while I was looking through the patch I noticed 2 things:
I am using AudioIn in more than one instance;
Some of the large spreads have a damper in them, although quite short response time (according to @vux this is not a good practice (forum:using-switch-with-directx11#comment-111558), but the suggested option (reducing spreads and putting S+H before them has had counterproductive results for me).
the audio latency could come from the audio system itself - this will not improve in a live environment for sure :( .
the buffer size of the audio input is the most important value. it defines the delay. have a loot at the fft4channels module, it contains an audio input node tweaked for low latency.
I can notice more “resolution” from the fft4channels node, but not so much improvement in latency. In any case, I’ll play around with the buffer setting some more, like you suggest. Reducing the sample rate could also relieve the load, perhaps…
