Re: [LAD] 9 soundcards ?

From: Manuel Haible <lacuna_@email-addr-hidden>
Date: Mon Feb 24 2020 - 17:38:31 EET
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.
 

>> 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?

 >> 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?
 
 
 
Gesendet: Donnerstag, 14. November 2019 um 07:34 Uhr
Von: "Len Ovens" <len@email-addr-hidden>
An: linux-audio-dev@email-addr-hidden
Betreff: Re: [LAD] 9 soundcards ?
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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
https://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Feb 25 04:15:02 2020

This archive was generated by hypermail 2.1.8 : Tue Feb 25 2020 - 04:15:02 EET