View Single Post
Old 10-23-2015, 09:15 PM   #4
Human being with feelings
NakajimaYusuke's Avatar
Join Date: Aug 2013
Location: Japan
Posts: 45

To confirm the delay caused by the use of direct monitoring, I tried an loopback experiment.
I connected an output to input by cable, across my audio interface.
In this way,"the output sound from the audio interface" returns to input.
This is a reproduction of the accurate playing using direct monitoring.

(If my rhythm is correct, I'd play with a metronome.
However, because my playing is unskilled, correct rhythm will not be obtained.
So, this time I was reproduced direct monitoring play in a mechanical way, to reduce an error. )

I entered a NINJAM server by this setting.
Metronome sound of ReaNINJAM is output from the audio interface, and it came back to the input.
This means "the sound of the metronome was sent from NINJAM client to NINJAM server".
I recorded multi-track recording data for this session in clipsort.log.

Then, I opened the clipsort.log in Reaper, and I confirmed the amount of delay.
This is the result.
Distance from the "tip of the item" to the "tip of the waveform" is the amount of delay.
If the delay is not present, tip of the item and the tip of the waveform is should overlap on the theory.

In my experiment, even tried in any buffer size,
the amount of this delay was almost the same amount as the amount of ASIO Input + Output Latency.
In this image, fully values match.
16 + 29 = 45

That is, when seeing from inside the NINJAM Client, the played sound using a direct monitoring is always delayed.
The amount of delay is the sum of the "ASIO input delay" and "ASIO output delay".

We are playing while listening to the "output sound from the audio interface".
And, "output sound from the audio interface" has been delayed by the amount of the ASIO output delay.
Because we're playing while listening to the sound(Index, mark, reference, clock) that was delayed, our performance has also been delayed.
In addition, the delay of the played sound is also generated when the input to the audio interface.

Thus it's certain that ASIO delay is included in the sound NINJAM Client sends to a NINJAM server, in case of direct monitoring use.
I hope the correction function for that to NINJAM Client.

I tried to specific experiments using readelay.
By entering the following delay time, I was able to correct the above-mentioned delay.

(60000*bpi/bpm)-(Asio Input Delay + Asio Output Delay)

But of course, it's troublesome to do this calculation each time during a session according to the change in BPM and BPI.
I want the function which calculates this automatically according to the change in BPM and BPI and applies it in NINJAM Client.
Attached Images
File Type: jpg directmonitoringdelay.jpg (48.4 KB, 576 views)
File Type: png loopback2.png (5.0 KB, 563 views)
Sorry about my poor English.
NakajimaYusuke is offline   Reply With Quote