On Mon, 23 Jan 2017 09:14:16 -0600 "Chris Caudle" <chris(a)chriscaudle.org> wrote: Is there really SRC going on if the cards are synced externally? -- Joakim

On Mon, Jan 23, 2017 at 05:35:57PM +0000, Fons Adriaensen wrote: Good to know. John

On Tue, January 24, 2017 09:22, Ralf Mardorf wrote: yes i think that works pretty good (drawing from earlier experiments). Using S/PDIF just for sync is a cheap alternative to a "real" wordclock. One of both interfaces will be slaved to the other and then both should run the same cycle at the same time (so theoretically no phasing issues). You just have to manage to shove forth and back the sample data from/to interface at good enough rate which isn't a particular problem on localhost using UDP like zita does. If there is no resampling involved, this can work for many many channels without hitting the CPU too much. Greetings Thomas

Thanks for the information. The two MADI FX cards I'm using can be synced via word clock. However, the information needs to be unaltered, no resampling or any modification is allowed for our processing. What command line settings do I have to use to make sure of that? How can I use the official zita-ajbridge or is there some documentation about it? 2017-01-24 16:36 GMT+01:00 Thomas Brand <tom(a)trellis.ch>ch>:

Hi again, I'd like to throw in a possible alternative for non-resampled audio transfer via UDP. jack_audio_send and jack_audio_receive [1] These programs have several limitations however for a case with two externally synced interfaces both connected to the same host running JACK with the same settings it could be worth a try. The number of channels that can be transimitted depends on the period size. For two JACK running at -p64, this *should* work: jack_audio_send --in 196 localhost 1234 jack_audio_receive --out 196 1234 ... 196 channels are quite heavy and the send/receive aren't possibly robust enough so you'd need to see if it works four you or where it breaks. === period size: 64 samples (1.333 ms, 256 bytes) channels (capture): 196 bytes per sample: 4 (32 bit float) immediate send, no pause or shutdown: no multi-channel period size: 50176 bytes message rate: 750.0 messages/s message length: 51200 bytes transfer length: 52398 bytes (4.2 % overhead) /!\ receiver(s) must support message size > 32768 expected network data rate: 314388.0 kbit/s (39.30 MB/s) /!\ high data rate (OK on localhost), use GigE === -> almost 40 MB/s of data moving on localhost, just in one direction. That's a lot for "just" creating a common audio data domain for both devices. Good Luck Thomas [1] https://github.com/7890/jack_tools/tree/master/audio_rxtx On Tue, January 24, 2017 17:13, Jörg Müller wrote:

On Tue, Jan 24, 2017 at 05:13:53PM +0100, Jörg Müller wrote: Use the -h option or man zita-a2j or man zita-j2a. Without resampling the samples will not be modified, but the latency of the two cards will not be the same (but the difference will be repeatable). Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Wed, Jan 25, 2017 at 03:19:14PM +0100, Jörg Müller wrote: Let's assume that you configure Jack to use soundcard A, and then run zita-j2a using card B, word-cloclk synced to A, to have additional outputs. Zita-j2a is just a Jack client like any other. Even if cards A and B are configured to use the same period size (this is not required) the period timing of B w.r.t A is completely random. So this would introduce a random additional latency on the outputs of B. What zita-j2a does in this case is to remove the random part. Since the periods are not synced, there must be some buffering between Jack and B. Zita-j2a will adjust the amount of buffering so as to make the additional latency independent of the random relative period timing. When zita-j2a is resampling this compensation is very accurate, as the error of the additional delay compared to a fixed target value is what is driving the resampling ratio. When zita-j2a is configured to not resample, the delay adjustment is made once when the first measurement is available, and fixed thereafter. This single, first measurement will not have the same accuracy as the filtered value used when resampling. The result of this is that if you want a the additional latency to be very well defined (i.e. having the same value each time you run the system) the best option is to enable resampling. Zita-a2j/j2a do set the port latencies so that apps like Ardour can take them into account. The value may not be sample-accurate, (it depends on unknown hardware parameters as well) but any error on it will be repeatable, so you can measure it once and then rely on the measured value. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Tue, Jan 24, 2017 at 04:27:00PM +0100, Thomas Brand wrote: This is all as wrong as it can possibly be. First, even when resampling is disabled there is no defined relation between the period timing of Jack's main soundcard and the one added with zita-ajbridge. Zita-ajbridge will detect the relative period phases, and insert buffering so as to ensure that the difference in latency is always the same. Second, there is no UDP or anything network involved at all. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

So I've been trying to send the problem to the alsa mailing list. I successfully registered there and get their mails delivered. However, the mails I sent to their mailing list remain unanswered and they cannot be seen in the archive of January 2017. Something seems to block my mails. What could it be? Could someone of you maybe forward the initial mail to their list? 2017-01-23 14:31 GMT+01:00 Adrian Knoth <adi(a)drcomp.erfurt.thur.de>de>:

So the bug has been fixed on the alsa-side. However, when I start jack via: wfs@wfs16:~$ jackd -p 1024 -d alsa -C madifx_record_all -P madifx_playback_all jackdmp 1.9.10 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2014 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 self-connect-mode is "Don't restrict self connect requests" audio_reservation_init Acquire audio card Audio0 creating alsa driver ... madifx_playback_all|madifx_record_all|1024|2|48000|0|0|nomon|swmeter|-|32bit configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit float little-endian ALSA: use 8 periods for capture ALSA: final selected sample format for playback: 32bit float little-endian ALSA: use 8 periods for playback jackd: ../linux/alsa/JackAlsaDriver.cpp:122: virtual int Jack::JackAlsaDriver::Attach(): Assertion `fCaptureChannels < 256' failed. Aborted (core dumped) The corresponding cpp-file at that line compares against a variable called "DRIVER_PORT_NUM", which is a constant defined in "common/JackConstants.h" on line 53 on the github repo. Could that be the problem? 2017-01-23 14:31 GMT+01:00 Adrian Knoth &lt;adi(a)drcomp.erfurt.thur.de&gt;de>:

On 02/08/17 18:16, Jörg Müller wrote: That's absolutely the problem, but the limit is arbitrary. Feel free to recompile jackd2 with changed constants in JackConstants.h. I guess you need to tweak a bunch of other values as well. PORT_NUM, PORT_NUM_MAX, DRIVER_PORT_NUM (that's per direction), PORT_NUM_FOR_CLIENT That should be it. Play a bit so it matches your setup. Feel free to send a patch. HTH

On Sat, Feb 11, 2017 at 01:38:46PM +0100, Jörg Müller wrote: It may be easier just to install the new jack2 files over the existing jackd2 package files. On Debian I use the current git source code and configure as follows: ./waf configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu \ --alsa --firewire Note that I don't use dbus so you'll have to add the configure option for that if you want it. Then: ./waf su -c "./waf install" John

This is months old, but I have news to this topic. The suggested changes work and we have set up 11x16channel audio monitors. That is 176 speakers! However, running Jack is highly unstable, it crashes roughly every two minutes and causes a huge amount of XRuns even at buffer sizes like 16000. CPU is down at 5%, so that is not the issue. Jack runs without a problem when using just one card. However, we need to combine the three MADI-Cards via .asoundrc in order to eventually get to 768 channels. I have the jack logs here: https://pastebin.com/ke25cdXB Do you have any idea what could cause the issue? Best, Jörg Am 10.02.2017 um 14:15 schrieb Adrian Knoth:

Did you synchronnize the cards via WordClock? Because if you did not, you will inevitably run into issues due to clock drift. On 08/02/2017 05:56 PM, Jörg Müller wrote: