May 27 2019, Max has written: ... ... Have you tried alsa_in/alsa_out for one of your cards? It is designed to integrate another card into a JACK setup. If your cards have a way of synchronising (SP/DIF or wordclock) you could also try that and use the -C and -P options of JACK to set up different capture and playback devices (which I suppose you are already using). JACK tries to be VERY precise. I don't know the technical details, but I think they could be summed up as: even if you don't hear problems/discrepancies, it doesn't mean there aren't any. Best wishes and good luck, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * GitHub: https://github.com/jeanette-c * Twitter: https://twitter.com/jeanette_c_s You might think that I won't make it on my own, But now I'm Stronger <3 (Britney Spears)

On 27/05/2019 13.28, Max wrote: ALSA is the low-level interface to the hardware (which Jack also uses). Each sound card is a separate device, each sending/receiving own stream of data. ALSA doesn't care about syncing them together. As generally, when running at the same bitrate, all devices are supposed to be clocked with the same frequency it seems to 'work quite well', e.g. when you sent the same bit stream to two different devices. It may be hours or days, but eventually problems will be apparent – audio output or buffer position getting out of sync, as different devices would digest data in a bit different tempo. Jack is not just another API to send bytes to audio output or receive bytes from input. It merges all audio i/o and processing (done by Jack clients) in a single flow and that flow is driven by a single clock. If that would be a clock of one audio device, and other audio device would be a bit slower/or faster buffer over/underruns would eventually happen. The easiest for implementation is to assume everything uses the same clock, which is usually the case in a studio setup. Otherwise the signal would have to be resampled, which is out of scope of the Jack server (Jack does not process the audio, it just routes in around and adds together). Let the Jack server do its job the way it does, just attach you extra input/outputs via external Jack clients, like these: https://kokkinizita.linuxaudio.org/linuxaudio/zita-ajbridge-doc/quickguide.… And I think Jack 1 has similar function included, in such case using some Jack setting would work too. Jacek

On Mon, 27 May 2019, Max wrote: With Alsa? or with pulse? Most linux desktop audio uses pulse and looks like alsa to the application. pulse does SRC where needed. For just alsa such as audacity, recording and playback are separate. The application could also treat inputs and outputs with different callbacks. however, while this would work, the two streams would drift away from each other over time making things like mutitracking impossible... or at least two tracks would not line up from the beginning of a song to the end. Jack is made for a different prupose. SRC causes artifacts in the audio and so is not used. Jack expects the same audio may be routed as both in and out and mixed. In order for this to happen without throwing away some of the audio or changing is sample rate, everything has to be in sync. Jack can deal with inputs and outputs on separate devices that are synced using wordclock if they are combined into one psuedo device. Or one card can be used as jack master and another device can be added through an SRC jack client such as alsa_in/out or zita-ajbridge. -- Len Ovens www.ovenwerks.net