Hello,
thank you,
your answers made up my mind
and currently I am in the process of reading in depth about your suggestions.
your answers made up my mind
and currently I am in the process of reading in depth about your suggestions.
>> What is the use case for many sound cards ?
There are two use cases:
- The Madi-card should run HQ-mastering grade converters (around 16 i/o).
- 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.
- The Madi-card should run HQ-mastering grade converters (around 16 i/o).
- 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.
( Any DIY solution is out of question for now,
as they have a decade of experience and their gear is running smoothly )
>> Use 48000 and be happy, 96000 is
>> only good for recording bats
This could lead towards an endless debate, - which I am not up for in this place,
but some thoughts on-topic:
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.
Now I decided for a no-compromise chain (that's why I choose Linux)
- and I am aware that there are different scientific statements about 48 vs 96k.
( some:
hearing range, overhead, commercials, other factors for quality as jitter, whole chain, room ect. ...
vs.
latency, plugin-qualities and -precision, non-ideal niquist-filters, downsampling to 44.1/16, ... )
And I guess there is no mastering-studio running 48k in 2020, no offence intended.
I am a PD-programmer and do have a background in electronics and acoustics,
so I guess that I know what I am talking about (as everyone does ;)
I am a PD-programmer and do have a background in electronics and acoustics,
so I guess that I know what I am talking about (as everyone does ;)
But,
if I would use 48k only,
I could run the Expert-Sleepers converters via ADAT
and yes, ideed - things would be easier.
>> 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?
Not at 96k (and yes I know s/mux, but that's not possible here).
Now I'd like to elaborate the possiblities for running the Madi-chain at 96k, at least?
>> 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).
Yes, I have read about those troubles. But now I found positive experiences, too (including the Jack-website).
It is not resolved why there have been issues with multiple USB-devices
(might just be clonflicts in shedueling, clocks, bandwith?),
but if I would use more than one USB 3.2 - PCIe slots in a desktop-computer,
the bandwith would be more than sufficient!???
It is not resolved why there have been issues with multiple USB-devices
(might just be clonflicts in shedueling, clocks, bandwith?),
but if I would use more than one USB 3.2 - PCIe slots in a desktop-computer,
the bandwith would be more than sufficient!???
Of course, faster than 1024 buffer size would be cool.
>> Each card have its own hardware clock
>> 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.
>> Each card have its own hardware clock
>> 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.
https://kokkinizita.linuxaudio.org/linuxaudio/
Very cool!
I am having a close reading on this now.
It seems like this is taking care of the drifting clocks with a buffer and alignment?
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?
There might be some other down-sides? Phase issues ect? ... I will read more ...
Zita seems to make up many possibilities ...
For now I see the following routes:
- 96k for everything, RME-HDSPe-Madi and multiple USB-Expert Sleepers
via zita-ajbridge ?
via zita-ajbridge ?
https://www.expert-sleepers.co.uk/moduleoverview.html
https://www.rme-audio.de/de_hdspe-madi.html
https://www.rme-audio.de/de_hdspe-madi.html
- 48k for everything, run the Expert Sleepers i/o with Adat via RME-MadiFx (with Adrian Knoths Alsa-driver) <> RME-Adi648 or multiple RME-RayDat
https://www.expert-sleepers.co.uk/moduleoverview.html
https://www.rme-audio.de/de_hdspe-madi-fx.html
https://github.com/adiknoth/madifx
https://www.rme-audio.de/de_adi-648.html
https://www.expert-sleepers.co.uk/moduleoverview.html
https://www.rme-audio.de/de_hdspe-madi-fx.html
https://github.com/adiknoth/madifx
https://www.rme-audio.de/de_adi-648.html
https://www.rme-audio.de/de_hdspe-raydat.html
- 96k for the Madi-Chain and 48k for the ADAT Expert Sleepers chain.
Maybe this could be achieved
- with zita-ajbridge by re-sampling?
- 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?
Is running different samplerates a good idea?
Bests, Manuel
_______________________________________________ Linux-audio-dev mailing list [email protected] https://lists.linuxaudio.org/listinfo/linux-audio-dev
