13 Nov
2019
13 Nov
'19
1:17 p.m.
Dear linux-multichannel-audio-users,
we are running a setup with two RME MADI cards to drive a system with
approx. 100 playback channels. We are using jack2 and zita-j2a to
achieve a sufficient number of playback channels. The sample clocks are
synchronized via word clock, therefor the resampling is deactivated in
zita-j2a.
On a similar setup (with two different card types) I noticed that the
latency between the cards is fixed as long as jack/zita-j2a is running,
however, the latency differs between starts of jack. This seems also be
the case in the setup with two MADI cards.
Is there a way on the software side to solve this problem? Or is there a
way to measure the latency without access to the analog I/O (knowing the
latency every time would be sufficient)? How are other people solving
synchronized playback of >64 channels?
Best,
Giso
13 Nov
13 Nov
10:59 p.m.
On Wed, 13 Nov 2019, Giso Grimm wrote:
Dear linux-multichannel-audio-users,
we are running a setup with two RME MADI cards to drive a system with
approx. 100 playback channels. We are using jack2 and zita-j2a to
achieve a sufficient number of playback channels. The sample clocks are
On a similar setup (with two different card types) I
noticed that the
latency between the cards is fixed as long as jack/zita-j2a is running,
however, the latency differs between starts of jack. This seems also be
the case in the setup with two MADI cards.
USB cards by chance? This is a known problem with USB Audio. Well actually
with USB in general. I am coming to the realization USB audio devices are
not desirable for profesional audio. They are sort of the best one can get
on a limited (reasonable?) budget. It is unfortunate that USB has become
the way periferals are added on modern computers when it comes to audio.
USB is great for many other things from printers to mice, but not really
critical audio.
--
Len Ovens
www.ovenwerks.net
14 Nov
14 Nov
12:12 a.m.
On 13.11.19 21:59, Len Ovens wrote:
On Wed, 13 Nov 2019, Giso Grimm wrote:
no, PCIe (and RME MADI hdspe cards are far from being budget - although
quite cheep compared to over 100 loudspeakers and corresponding
DA-converters :-) ). Sample clock sync works perfectly.
The only response I got from RME is "it works on Windows without any
latency differences" - however if I understand it correctly in this case
the interrupts of the two sound cards need to be somehow synchronized
with sub-sample precision.
Dear linux-multichannel-audio-users,
we are running a setup with two RME MADI cards to drive a system with
approx. 100 playback channels. We are using jack2 and zita-j2a to
achieve a sufficient number of playback channels. The sample clocks are
On a similar setup (with two different card
types) I noticed that the
latency between the cards is fixed as long as jack/zita-j2a is running,
however, the latency differs between starts of jack. This seems also be
the case in the setup with two MADI cards.
USB cards by chance? This is a known problem with USB Audio. Well
actually with USB in general. I am coming to the realization USB audio
devices are not desirable for profesional audio. They are sort of the
best one can get on a limited (reasonable?) budget. It is unfortunate
that USB has become the way periferals are added on modern computers
when it comes to audio. USB is great for many other things from printers
to mice, but not really critical audio.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
2:22 a.m.
On Wed, 13 Nov 2019, Giso Grimm wrote:
Sorry, I misread. I think that because there is an indeterminite amount of
time between jack opening one device and zita-ajbridge opening the second,
the interrupts can not happen at the same time. In this case creating a
multi device and opening the whole thing as jack's master device would be
the only way. See http://jrigg.co.uk/linuxaudio/ice1712multi.html for an
example.
--
Len Ovens
www.ovenwerks.net
> we are
running a setup with two RME MADI cards to drive a system with
> approx. 100 playback channels. We are using jack2 and zita-j2a to
> achieve a sufficient number of playback channels. The sample clocks are
no, PCIe (and RME MADI hdspe cards are far from being budget - although
quite cheep compared to over 100 loudspeakers and corresponding
DA-converters :-) ). Sample clock sync works perfectly. 
10:14 p.m.
On Wed, Nov 13, 2019 at 12:17:47PM +0100, Giso Grimm wrote:
we are running a setup with two RME MADI cards to
drive a system with
approx. 100 playback channels. We are using jack2 and zita-j2a to
achieve a sufficient number of playback channels. The sample clocks are
synchronized via word clock, therefor the resampling is deactivated in
zita-j2a.
On a similar setup (with two different card types) I noticed that the
latency between the cards is fixed as long as jack/zita-j2a is running,
however, the latency differs between starts of jack.
It will be different each time you (re)start zita-j2a, even if Jack
remains runnning.
This is a known problem. The quick solution ATM is to *not* disable
resampling.
When j2a or a2j is used *with* resampling, there is a control loop
that tries to set the average number of samples that is buffered
between the two clock domains to a preset value. It does this by
1. Making an initial guess based on the timing of the first
available ALSA period relative to Jack's start of period.
2. Continuously adjusting the resampling ratio based on the most
recent timing info as it becomes available. This is a very
slow control loop that after a few seconds will remove any
error made in the first step. The result is a constant and
defined latency.
When resampling is disabled, only (1) happens, which means that
the initial error is never corrected. This is why you get a
different latency each time.
The solution (without resampling) would be to run the control
loop anyway for 10 seconds or so, and then adjust the latency
again by either inserting or skipping a number of samples. This
would require significant changes to the code, and it would
result in a glitch some time after starting. The cleanest
solution to that would be to mute the ALSA device until the
loop has settled. So you'd only get signal 10 seconds or so
after starting a2j or j2a.
I've been planning to implement this, but there's always
something more urgent...
Ciao,
--
FA
1830
days inactive
1831
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Fons Adriaensen -
Giso Grimm -
Len Ovens