On 07/08/2018 02:55 PM, Steven Kruyswijk wrote: zita-ajbridge = zita-a2j + zita=-j2a These standalone tools were later built-into jack1 (jack 0.124 or later) for convenience. I have to admit, Apple's aggregate device UI is brilliant as is Coreaudio's design. Also Mac Mini are awesome machines for A/V live performances, mainly because the do come with a robust case but also because they're more powerful than an average RPi, besides GNU/Linux runs fine on Mini Mac. That being said. Don't give up on the RPi, it may seem complicated if you have not done this before, but it's really not. Cheers! robin

Alright I've decided to give the RPi/Linux/Jack route another try... I have to say my progress is pretty slow though... the Mac Mini route still looks very enticing. Right now, I'm trying to understand this suggested line: jackd -I alsa-playback:zalsa_in/-dhw:CODEC_1 -dalsa -dhw:PCH -r48000 -p1024 -n2 When I look up the man page for jackd at https://manpages.debian.org/testing/jackd1/jackd.1.en.html, this is the explanation for the -I parameter: /-I, --internal-client client-spec Load client-name as an internal client. May be used multiple times. The form of client-spec can be any of the following: client-path client-name:client-path client-name:client-path/init-string client-path/init-string The first form will cause jackd to attempt to load the client from a shared object named "client-path" with appropriate suffixes appended. If "client-path" is absolute, jackd will use that (adding a platform appropriate suffix for a shared object). If it is not absolute, jackd will look for "client-path" (with an appropriate suffix) in the same location that drivers and other JACK add-ons are located. The second form provides "client-name" as the desired name for the client once loaded, in addition to the "client-path". The third form provides an "init-string" in addition to a client name and path, which will be passed to the client's initialization function. The final form does not specify the client name, but does include the path to the client's shared object file and an initializations string. When invoking JACK from the shell, remember to quote the argument to -I if it includes spaces. / which I find really hard to relate to /alsa-playback:zalsa_in/-dhw:CODEC_1/ Also, I have been unsuccesful in instantiating zita-j2a by running a script from qjackctl, even when executing that script manually does work. Can anyone please point me to a page where I can learn more about how to make a setup where Pure Data runs automatically after boot, connecting to more than one audio interface? -- Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html

Thanks Paul, and thanks in general for your work in developing Jack, much appreciated. Your comments will be very useful I'm sure if or when I get to working with jack from the command line. For now I've been able to sort out my challenge with the following: It turns out that the script that I used to invoke zita-j2a, needed the aforementioned (but in a slightly different context) ampersand; this script now works, from within the qjackctl preferences: #!/bin/bash zita-j2a -d hw:CODEC_1 & Also, I've figured out how to instantiate pure data (or purr data, actually) with the right audio output settings from this same script. And I've figured out how to make the connections in qjackctl persistent, and how to execute qjackctl each time the OS starts - which satisfies my request for a 'Pd at boot system'. I guess you may have interpreted that last goal as a completely minimal Pd-only setup, which makes me think of Geert Bevin's Erpiam project, which I would like to check out some time eventually. Thanks again! -- Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html

Hi all, A little over a year later I'm revisiting this project, where the core challenge was to connect a second USB audio device and have PD (actually pd-l2ork) utilize it, with all of this running automatically at boot. The system has run quite well, but once every while (maybe 15% of the time) PD fails to start up, with the qjackctl message window saying "Killed". I haven't been able to find out what's going wrong, perhaps somebody can help me. Otherwise I am thinking of making a jackd approach, so completely non-GUI, and perhaps utilizing zalsa_out instead of zita-j2a. Right now the system works like this: - in /home/.config/lxsession/LXDE-pi/autostart, @qjackctl is added to autostart it when the system (Raspbian) boots; - in qjackctl's Setup page, a script is executed after startup, - in that script these commands are run: zita-j2a -d hw:Device_1 & sleep 2 # to set the system volume: amixer -c 1 cset numid=6 30 amixer -c 2 cset numid=6 30 sleep 2 pd-l2ork -rt -audiobuf 20 -inchannels 2 -outchannels 4 /home/pi/Documents/patch.pd & Also in qjackctl's Setup page, Activate Patchbay persistence is checked to make sure the 4 PD outputs are connected to the 4 out-channels in jack. I wonder how this would be done on the command line. I'm having difficulty in experimenting with zalsa_out; the example commands that Robin Gareus suggested earlier don't seem to be valid on my system... also I can't find any documentation on either zalsa or the -I option that he mentioned: Robin Gareus wrote If anyone has any suggestions and/or pointers for me what to try or where to find more info, that would be great. Thanks in advance. -- Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html

On Tue, Oct 1, 2019 at 1:08 PM Steven Kruyswijk <stevenkruyswijk(a)gmail.com> wrote: jack1 can't do anything that jack2 can't do (with respect to this problem). it's just that the zalsa_{in,out} functionality is implemented as an internal client in jack1, which makes it easier to invoke directly from the command given to start the JACK server. you can do the same thing using the separate zalsa_{inlout} clients with jack2.

On Tue, 1 Oct 2019 12:13:15 -0700 (MST) Steven Kruyswijk <stevenkruyswijk(a)gmail.com> wrote: IIRC jack2 can do this too, but it doesn't use the same command line parms, rather you'd have to run "jack_load audioadapter". I'm pretty sure this can be automated but don't remember the details. -- Joakim

On Mon, 14 Oct 2019 11:22:14 -0600 Paul Davis <paul(a)linuxaudiosystems.com> wrote: What I meant is that JACK2 also has functionality to connect to several sound cards, but it's enabled differently than the JACK1 builtin client. Of course zita_ajbridge can alternatively be used with both versions of JACK. -- Joakim

On Tue, Oct 15, 2019 at 11:47 AM Brent Busby <brent(a)keycorner.org> wrote: My email explains how to do that. Also, AFAIK, zita's resampling code is much better than the equivalent in jack2's "audioadapter". Re-read it, and if it is still not clear, let me know.

Joakim Hernberg <jhernberg(a)alchemy.lu> writes: Yes, I was planning on connecting the clock ports and recording with both at 96kHz. The Multiface sounds very dark/murky if you don't run it at 96kHz (filter optimized for that rate?), and the Babyface can do that rate but it sounds good at any setting, so it looks like we need 96kHz to make them both happy. This is just to get drum tracks recorded. No realtime processing or plugins during recording will be needed. Record into the analog ins of the Babyface, and route it to the digital ports? I presume I'd be doing this through Jack, since there sadly isn't anything like hdspmixer for USB devices like the Babyface to let you control routing in hardware right on the device. (Sometimes eight channels just isn't enough...) :( -- - Brent Busby + =============================================== + "The introduction of a new kind of music must -- Studio -- + be shunned as imperiling the whole state, for -- Amadeus/ -- + styles of music are never disturbed without -- Keycorner -- + without affecting the most important political -- Recording -- + institutions." --Plato, "Republic" ----------------+ ===============================================