11 Nov
11 Nov
9:36 p.m.
On Mon, Nov 11, 2019 at 12:26 PM <lacuna_(a)gmx.net> wrote:
Hello,
* I'd like to run up to nine soundcards with Jack. *
Eight times Expert Sleepers ES-8 via USB
and one RME Madi HDSPe card on a PCIe slot.
In Linux at 96 kilobauds.
I read here
https://jackaudio.org/faq/multiple_devices.html
about clocking issues as each card is run by it's own clock.
*Will the asynchronously clocked streams be handled and merged by Jack or
is this an ongoing issue? *
JACK2 (the one most commonly installed on Linux systems) can't do this by
itself (for now)
You would use an instance of zita_a2j to connect each "secondary" card to
the JACK server which is using the "master" card. zita_a2j will resample as
needed to keep things in sync.
JACK1 can do this by itself because it has zita_a2j built in. However, it
is a slightly older version of zita_a2j and I discovered recently that it
doesn't handle xruns as well as the current zita_a2j.
I imagine, if I'd feed analog outputs of one card into the analog inputs
of another, this wouldn't be ideal.
But I am wondering if Jack is handling the asynchronous streams in the
software-domain without glitches ect. ?
*With a powerful computer is the latency going to rise absurdly high? Any
experience with this? *
Number of cards has nothing to do with latency directly. "Servicing" each
card will consume some of the time available for audio processing. How much
is hard to say, but with mid-size buffer sizes, I would not guess that it
will be too large. Since you are not sharing word clock, they will drift
and zita_a2j will have to do resampling, which will also consume some CPU
cycles.
9:43 p.m.
On Mon, 11 Nov 2019, lacuna_(a)gmx.net wrote:
I'd like to run up to nine soundcards with Jack.
nope, won't happen.
Eight times Expert Sleepers ES-8 via USB
USB in particular will not be in sync.
To use them together and see the i/o on jack will require an extrenal
client or two per usb device. You could use zita-ajbridge to do that which
inserts an SRC stage between the device and jack to make syncing possible.
However, you say you want to use 8 of them. This will also be a problem at
any low latency because you will be using USB hubs which have been known
to cause trouble with audio devices. so be prepared for xruns at any
buffer size less than 1024 (maybe even there).
and one RME Madi HDSPe card on a PCIe slot.
Use that as your jack master.
In Linux at 96 kilobauds.
kilobauds? you mean sample rate maybe? Use 48000 and be happy, 96000 is
only good for recording bats
Really, I don't know how many i/o you RME Madi has (should be 64-ish?) Add
what is needed to max that out. USB mics are for the most part toys,
better to use one of the many 18 i/o USB devices out there instead most of
which do have the ability to sync with your RME.
I would not waste my time with USB mics.
--
Len Ovens
www.ovenwerks.net
9:53 p.m.
Hi Manuel,
It looks like those ES-8's have ADAT I/O. Could you sync their internal
clocks by daisy chaining them via ADAT I/O off of the RME's ADAT output?
- Mike
On Mon, Nov 11, 2019 at 2:43 PM Len Ovens <len(a)ovenwerks.net> wrote:
On Mon, 11 Nov 2019, lacuna_(a)gmx.net wrote:
I'd like to run up to nine soundcards with
Jack.
nope, won't happen.
Eight times Expert Sleepers ES-8 via USB
USB in particular will not be in sync.
To use them together and see the i/o on jack will require an extrenal
client or two per usb device. You could use zita-ajbridge to do that which
inserts an SRC stage between the device and jack to make syncing possible.
However, you say you want to use 8 of them. This will also be a problem at
any low latency because you will be using USB hubs which have been known
to cause trouble with audio devices. so be prepared for xruns at any
buffer size less than 1024 (maybe even there).
and one RME Madi HDSPe card on a PCIe slot.
Use that as your jack master.
In Linux at 96 kilobauds.
kilobauds? you mean sample rate maybe? Use 48000 and be happy, 96000 is
only good for recording bats
Really, I don't know how many i/o you RME Madi has (should be 64-ish?) Add
what is needed to max that out. USB mics are for the most part toys,
better to use one of the many 18 i/o USB devices out there instead most of
which do have the ability to sync with your RME.
I would not waste my time with USB mics.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
11:41 p.m.
I'd like to run up to nine soundcards with Jack.
Ha, I'll raise you two. I'd like to run 11 sounds cards with Jack. At 192 mega
bored.
Raise me if you dare, I have a good hand, it's prime.
"at the end of the day its nil nil at half time???.
Trevor Brooking
________________________________
From: Linux-audio-dev <linux-audio-dev-bounces(a)lists.linuxaudio.org> on behalf of
lacuna_(a)gmx.net <lacuna_(a)gmx.net>
Sent: Monday, November 11, 2019 8:26 PM
To: linux-audio-dev(a)lists.linuxaudio.org <linux-audio-dev(a)lists.linuxaudio.org>
Subject: [LAD] 9 soundcards ?
Hello,
I'd like to run up to nine soundcards with Jack.
Eight times Expert Sleepers ES-8 via USB
and one RME Madi HDSPe card on a PCIe slot.
In Linux at 96 kilobauds.
I read here
https://jackaudio.org/faq/multiple_devices.html
about clocking issues as each card is run by it's own clock.
Will the asynchronously clocked streams be handled and merged by Jack or is this an
ongoing issue?
I imagine, if I'd feed analog outputs of one card into the analog inputs of another,
this wouldn't be ideal.
But I am wondering if Jack is handling the asynchronous streams in the software-domain
without glitches ect. ?
With a powerful computer is the latency going to rise absurdly high? Any experience with
this?
As Jack-Devel-List is dead, I'm asking here.
With best regards,
Manuel
12 Nov
12 Nov
12:33 a.m.
What is the use case for many sound cards ?
Is it channel count or the need for networking or both ?
Matt
On 12/11/19 8:41 am, Nick Copeland wrote:
* I'd like to run up to nine soundcards with Jack.
*
Ha, I'll raise you two. I'd like to run 11 sounds cards with Jack. At
192 mega bored.
Raise me if you dare, I have a good hand, it's prime.
"at the end of the day its nil nil at half time???.
Trevor Brooking
------------------------------------------------------------------------
*From:* Linux-audio-dev <linux-audio-dev-bounces(a)lists.linuxaudio.org>
on behalf of lacuna_(a)gmx.net <lacuna_(a)gmx.net>
*Sent:* Monday, November 11, 2019 8:26 PM
*To:* linux-audio-dev(a)lists.linuxaudio.org
<linux-audio-dev(a)lists.linuxaudio.org>
*Subject:* [LAD] 9 soundcards ?
Hello,
* I'd like to run up to nine soundcards with Jack. *
Eight times Expert Sleepers ES-8 via USB
and one RME Madi HDSPe card on a PCIe slot.
In Linux at 96 kilobauds.
I read here
https://jackaudio.org/faq/multiple_devices.html
about clocking issues as each card is run by it's own clock.
*Will the asynchronously clocked streams be handled and merged by Jack
or is this an ongoing issue? *
I imagine, if I'd feed analog outputs of one card into the analog
inputs of another, this wouldn't be ideal.
But I am wondering if Jack is handling the asynchronous streams in the
software-domain without glitches ect. ?
*With a powerful computer is the latency going to rise absurdly high?
Any experience with this? *
As Jack-Devel-List is dead, I'm asking here.
With best regards,
Manuel
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
5:41 p.m.
Le Mon, 11 Nov 2019 20:26:47 +0100,
lacuna_(a)gmx.net a écrit :
Hello,
I'd like to run up to nine soundcards with Jack.
Eight times Expert Sleepers ES-8 via USB
and one RME Madi HDSPe card on a PCIe slot.
In Linux at 96 kilobauds.
I read here
https://jackaudio.org/faq/multiple_devices.html
about clocking issues as each card is run by it's own clock.
Will the asynchronously clocked streams be handled and merged by Jack
or is this an ongoing issue?
It is an hardware issue. Each card have its own hardware clock, they
are some kind of quartz oscillators often associated with PLL
circuitry. They are implemented into the silicon of the cards and it is
nothing JACK can do about this.
The only solution would be to use a Master clock, which is to use the
clock of one card as clock for all the cards. That can only be done at
the hardware level. In your case, that imply to modify the hardware of
the cards, which, with 8 USB of one brand and 1 PCI card of another
brand would be rather complicated, if possible. Even if we consider
only the 8 USB cards of the same brand, it is more than doubtful the
clock of one of these cards would be powerful enough to be able to
drive the 8 cards. Which imply this would not be a trivial modification.
Dominique
--
If you have a problem and you are not doing anything to fix it, you are
at the heart of the problem.
8:55 p.m.
On Wed, Nov 13, 2019 at 11:23 AM Manuel Haible <lacuna_(a)gmx.net> wrote:
I am in a love-hate relation with digital audio processing,
never experienced a converter in person that is comparable to an
all-analog chain.
Speacially the very highs and 3Dness.
I suspect you've never double-blind tested this. If you have, good for you.
And I guess there is no mastering-studio running 48k in 2020, no offence
intended.
This proves absolutely nothing. Audio engineers are no more immune to
marketing BS than anyone else.
It seems like this is taking care of the drifting
clocks with a buffer and
alignment?
zita_a2j will resample the stream from hardware it uses to make it match
the apparent difference in speed between the hardware it is using, and the
hardware that the JACK server is using. There will be no drift and no
alignment issues.
*The RME as master? Does that mean the hardware-clock of the RME would
define the whole DSP-chain? Somewhere I read that
RME-cards can only run as
slave in Linux, but maybe this is outdated?*
This is false., and was never true.
There might be some other down-sides? Phase issues ect? ... I will read
more ...
All the downsides come from your desire to build a digital audio system
with 9 clocks in it. This is absolutely the wrong thing to do. The fact
that you can use software (like zita_aj2) to hide or gloss over the fact
that this is wrong doesn't stop it being wrong, and doesn't get rid of the
downsides of having 9 clocks. Rule #1 for digital audio: 1 clock.
14 Nov
14 Nov
1:34 a.m.
On Wed, 13 Nov 2019, Manuel Haible wrote:
- The Expert Sleepers converters will interface with
an Eurorack
modular-synthesizer.
They are the only ones who have DC-coupled i/o with 20 Vpp,
for control-voltages and audio.
So low latency is important but sample accuracy not so much.
And I guess there is no mastering-studio running 48k
in 2020, no offence
intended.
None taken. I am also pretty sure that the 96k is an advertizing feature
rather than technical. More to do with not having customers walk down the
street to someone who charges the same but uses 96k. If you are doing
mastering as a living, using 96k is fine. Doesn't sound any better, has
more losses than gains but it does keep the dollars rolling in so it is
worth while.
but if I would use more than one USB 3.2 - PCIe slots
in a desktop-computer,
the bandwith would be more than sufficient!???
My experience with USB 3 plugs on my desktop is that no matter where I
plug in the motherboard silently routes any of them through the same USB
bus anyway. Remember that they are USB 2.0 interfaces even if plugged into
a USB 3.0 plug. (even if the interface says USB 3 compatable it is likely
USB2.0 audio via USB 3) So adding dedicated USB PCIe cards may help, using
a USB 3 hub may (or not) help.
- 96k for the Madi-Chain and 48k for the ADAT Expert
Sleepers chain.
Maybe this could be achieved
- with zita-ajbridge by re-sampling?
Yes this would work. As you are usng the USB devices for voltage control
there is no need for sample accuracy or other sonic artifacts introduced
by SRC.
- Or with zita-njbridge in a network with one
Rasperry-Pi for each
USB-connection and re-sampling?
With this I might get rid of USB-conflicts, too. Running into more possible
failures?
R-pi 4 would be ok, R-pi 1-3 (so far as I know use USB internally for the
network IF as well and there is only one. Rpi4 fixes this. However,
network style bridging normally adds latency, so test first with one unit
to see how much this is (normally one or two buffer sizes of latency).
Just a quick note on 96k vs 48k for reduction of latency. While this seems
like a possibility as 1024 buffer size goes through twice as fast at 96k
for example. The determining factor in latency is normally not the sound
card but rather USB itself (1 ms access cycle) or the amount of CPU power
available for DSP. So running at 64 buffer size at 48k generally means
needing to run at 128 buffer size to get the same reliability (maybe
higher)
Is running different samplerates a good idea?
Once you are using SRC anyway, it makes very little difference. Running
them all from the same clock would be ideal.
--
Len Ovens
www.ovenwerks.net
8:14 p.m.
On Mon, 24 Feb 2020, Manuel Haible wrote:
Yes, It depends on how long it takes the bridge to start up and when it
gets started. If the setup is started by a script, it depends on system
load pretty much.
The Zita SRC code is very good and so it is not so much anything you would
hear if listening just to the resampled output. However, I would not set
up a stereo pair with one resampled and the other not. Anything using
close mics should be fine as is.
Now i am proceeding with project that we talked some
time ago:
Now I am planning to use several RME Madi HDSPe cards and Madi/Adat converters.
Running one at 96k (for audio) as master and two at 48k (for control voltages and
some basic audio) resampled with zita.
3 Madi cards = 32 i/o @ 96k + 128 i/o @ 48k
Can this amount of audio streams be handled by modern multicore systems?
Plus DAW, plugins, ect ?
With a pleasant latency?
I guess yes, as there exists the RME MadiFX, too - which provides ~196 i/o @ 48k.
Multicore? yes. Multithread per core? Not so much in my experience. I have
not exerimented with any of this since I bought the i5 (4 cores, 4
threads) a few years ago. However, in my my experimentation leading up to
that purchase, I found that 64/2 was about as low as I could go with multi
thread cores, but turning the multithread(hyperthreading?) feature off in
bios allowed very stable operation even down to 16/2. (using a ice1712
based PCI audio card). Be aware that the sound card itself will end up all
on one thread/core. You can see this by looking at /proc/interrupts where
almost all of the interrupts for the audio card wioll be on one core. So
probably each of your cards will be on a different core. As you are using
zita-ajbridge that is probably not a concern.
> So low
latency is important but sample accuracy not so much.
The time-shift of
sample-streams would be different on each start up, right? Even if a jack-client is "hanging" or x-runs
occure, after re-syncing the
time-shift changes, right?
How much of a time-shift is about to be expected?
within one buffer size worth of samples.
> there is
no need for sample accuracy or other sonic artifacts introduced
> by SRC
What kind of sonic artefacts in the resampled audio are expected? Would it be a good idea to apply an aliasing-filter
before feeding the
zita-resampler?
No.
--
Len Ovens
www.ovenwerks.net
10:26 p.m.
On Mon, Feb 24, 2020 at 10:14:01AM -0800, Len Ovens wrote:
Yes, It depends on how long it takes the bridge to start up and when it gets
started. If the setup is started by a script, it depends on system load
pretty much.
(Assuming this is about zita-ajbridge)
No, zita-j2a and a2j measures the relative timing of Jack and Alsa periods
when starting up. With the -S option (no resampling, assuming word clock
sync), this is a single observation and there may be some remaining error.
With resampling (no -S) the added latency will converge to a defined value,
with only some jitter around this remaining.
Indeed no, the anti-aliasing filter is part of the resampling process.
To the OP: please, no HTML on this list !
Ciao,
--
FA
On Mon, 24 Feb 2020, Manuel Haible wrote:
> So low latency is important but sample accuracy
not so much.
The time-shift of sample-streams would be different on each start
up, right? Would it be a
good idea to apply an aliasing-filter before feeding the
zita-resampler?
No. 
14 Nov
14 Nov
4:39 p.m.
On Wed, Nov 13, 2019 at 07:22:52PM +0100, Manuel Haible wrote:
Now I decided for a no-compromise chain
(that's why I choose Linux)<br/>
- and I am aware that there are different scientific statements about 48 vs
96k.<br/>
You needn't go above 48kHz/16 bit. In double-blind tests I've yet to
find anyone that can tell that apart from 192kHz/24 bit. In practical
terms you're going to be listening to it with 32kHz/12 bit ears anyway
;-)
--
Gordonjcp
1729
days inactive
1834
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
10 participants
participants (10)
-
Dominique Michel -
Dr. Claw -
Fons Adriaensen -
Gordonjcp -
lacuna_＠gmx.net -
Len Ovens -
Manuel Haible
-
Matt Flax -
Nick Copeland -
Paul Davis