[LAU] Proper signal flow when tracking + processing microphone input

[Andrew A. Grathwohl]

Hello folks,

If I am recording a live microphone input, while also routing that
signal to be processed in SuperCollider, which of these two signal flows
would provide the least latency between the live microphone signal and
the output from SuperCollider?

1. Route microphone into both Ardour5 and SuperCollider at the same time
(my current setup)

2. Route microphone into Ardour5, then feed that track's monitor signal
into SuperCollider

I am using Jack2 on Arch Linux, with linux-rt-lts kernel. My Jack2
settings are 48kHz, 96 bufsize, 3 periods. Despite the fact that I am
multi-track recording 18 channels (2 from mics, 16 from SuperCollider),
I get hardly any xruns on this setup.

My problem is that, under this configuration, I've noticed that the live
microphone input seems to get recorded to its Ardour5 track *after* the
SuperCollider output. This can't be correct since the SuperCollider
signal relies on the microphone input to make any sound at all, so
somewhere in the chain the microphone signal is getting delayed on its
way into Ardour5. Expected behavior would be for the mic signal to be
written to Ardour5 followed by the output from SuperCollider's
processing of that input. I can't tell if the current predicament is due
to a sub-optimal signal flow strategy or if I need to explore
software/hardware bugs.

Many thanks in advance for any help!

-Andrew

I have been using Ardour5 to multi-track record 18 channels of audio. 16
of the channels come from SuperCollider 3.10, running on the same Linux
workstation as Ardour5. The other two channels are live microphone
feeds, which correspond to audio inputs 1 and 2 on my RME Babyface Pro.
Jack2 is used to route this live mic audio as well as the SC3 audio
outputs into Ardour5. Additionally noteworthy is that these two live
microphone feeds are also plugged into SuperCollider. The 16
SuperCollider outputs are the result of realtime processing being
applied to those two microphone inputs.

As crazy as this all sounds, this setup has generally worked splendidly,
especially after building the linux-rt-lts kernel and tuning Jack2 for
low-latency operation. (I run Jack2 at )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20191009/57f2182e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3216 bytes
Desc: not available
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20191009/57f2182e/attachment.key>