Hi, some users shared experiences at the Linux Audio User mailing list, see https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB+AVB. Consider to read those threads and if you should still have questions after reading, to subscribe to the Linux Audio User mailing list and to send a request to this list, https://lists.linuxaudio.org/listinfo/linux-audio-user. Regards, Ralf

On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend. On 12/08/2018 02:35 PM, Christoph Kuhr wrote:

I thought it was the last of my questions but I have two more, of this is the first mail. My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you configure it to 96000Hz with the windows mixer. It seems as soon as you close down the windows based presonus audiobox software it defaults back to 44100Hz and soesnt keep it in memory when you use it on Linux. Questions: 1) I need to confirm the above. Is there any way jack can report the bitrate of the data it receives from usb driver and therefore the bitrate by which the presonus 1818vsl send the data. 2) If the 1818vsl does revert back after a windows config at a higher rate, is there any current facility in jack to configure the presonus to work with 96000Hz ?

On Fri, December 14, 2018 1:47 am, liebrecht(a)grossmann-venter.com wrote: Most USB devices will use whatever the driver requests if possible. The driver will request whatever the application which opens the ALSA driver requests if the driver accepts the request as supported by the card (USB devices return a parameter list which shows what rates are supported). Check the /proc/asound/ entry for your card. See below, in my case it was card0/pcm0p/info, depending on your card configuration it may be something other than card0 and pcm0. The script that Robin mentioned will dump that info for you. Sure, just specify what sample rate you want to use when you start jackd and it will send that request to the ALSA driver, which should send that request to the hardware. Startup with 48k requested: $ jackd -dalsa -dhw:Lambda -r48000 jackdmp 1.9.12 ...startup messages, copyright, blah blah... Acquire audio card Audio0 creating alsa driver ... hw:Lambda|hw:Lambda|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: 24bit little-endian in 3bytes format Startup with 44.1k requested: $ jackd -dalsa -dhw:Lambda -r44100 ...startup messages, copyright, blah blah... Acquire audio card Audio0 creating alsa driver ... hw:Lambda|hw:Lambda|1024|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format Startup with 96k requested (note this is not supported, so defaults to closest supported value, which in this case is 48k): $ jackd -dalsa -dhw:Lambda -r96000 ...startup messages, copyright, blah blah... Acquire audio card Audio0 creating alsa driver ... hw:Lambda|hw:Lambda|1024|2|96000|0|0|nomon|swmeter|-|32bit configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format Note that jackd does not warn the rates do not match, which is not what I expected. $ cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_3LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 2048 I thought that the ALSA driver would return the value of the actual sample rate used, and jackd would check that and display if the rate in use did not match the requested rate. Apparently not, at least not for all cards, maybe driver dependent. -- Chris Caudle

On Fri, December 14, 2018 2:11 am, liebrecht(a)grossmann-venter.com wrote: Correct, it is a userspace application that needs to be started under your user account. Applications using jackd for routing have to be able to share a memory buffer, so you cannot for example run jackd as a system service that any or multiple users could use. If you start from a command line you can use control-c key combination. Often users start from the qjackcontrol application, the application has a "stop" button which can be used to stop jackd. I also have my qjackcontrol set to run "killall jackd" on exiting just in case the jackd process hung for some reason and did not respond to control commands, but I have not actually seen that happen, it is just a precaution. Look in your applications directory, probably /usr/bin on most distributions, might be in /bin on some. There should be several apps with jack in the name. These could be useful to you: /usr/bin/jack_connect /usr/bin/jack_control /usr/bin/jack_disconnect /usr/bin/jack_lsp /usr/bin/jack_samplerate /usr/bin/jack_server_control There are two variants of what is called version 2 of jackd, stand alone jackd and jackdbus, which is jackd which exposes dbus controls. For various historical reasons what I called version 2 of jackd is not really a continuation of version 1, it is another implementation of the same userspace API with a completely different engine. It started as an experiment to try out some different features, but jackd 1 and jackd 2 ended up continuing in parallel, with slightly different internal features, but same API presented to applications. Since you have jackdbus on your system that indicates your distribution ships jackd 2. The jackdbus application is started using dbus, if you attempt to start it manually it gives a warning: jackdbus should be auto-executed by D-Bus message bus daemon. If you want to run it manually anyway, specify "auto" as only parameter Probably some application automatically started jackdbus when you started the application. Hard to know which one that would have been. More probably jackd detects that there is already a process providing jack API services, in your case jackdbus. Use jack_control to query the parameters, stop, etc. You do not really have to reboot, if your system is configured to use jackdbus then just start an application which needs jackd and it will be automatically started, or use jack_control start to start it manually. Which distribution are you using? You should be able to configure your system to use jackd instead of jackdbus. If you manually start jackd from a terminal before starting any audio applications then jackdbus should detect that another jackd server is running and not start, but you can probably configure the audio applications to start jackd instead of jackdbus if you would prefer. Can you check what is in the ~/.jackdrc file? (by the way, not sure how familiar you are with linux terminal use, just reply if something is unclear, e.g. "~" means your user home directory). Possibly either that file, or a system file in /etc/jackdrc is configured to use jackdbus as the default jack server. My drc file has this for example: /usr/bin/jackd -P70 -t2000 -dalsa -dhw:Lambda -r48000 -p1024 -n3 -zt -I376 -O376 That indicates to applications that want to automatically start a jack server that my preference is jackd (instead of jackdbus), 2000 millisecond timeout for applications to respond, ALSA driver backend, my Lambda audio interface, 48k sample rate, 1024 samples per period, 3 periods buffering latency, use triangular PDF dither, and report 376 samples of input and output latency. You do not have to set all of those backend parameters, you may be able to get away with defaults for some. I doubt you will care about the differences between jackd and jackdbus though after finding jack_control, it sounds like you just have not experimented enough to find all the various jack application yet. Admittedly they are not documented very well. I'm not sure jackdbus is documented anywhere in an easy to find form, the jack website just has man pages for jackd, which has probably contributed to your confusion: https://github.com/jackaudio/jackaudio.github.com/wiki/jackd(1) https://github.com/jackaudio/jackaudio.github.com/wiki/jackdrc%285%29 The jack_control wiki page is probably the only place that mentions jackdbus: https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_jac… -- Chris Caudle

On 2018-12-22 15:40, Jörn Nettingsmeier wrote: That is in fact the exact way I am going after long information gathering. Motu is the way to go, separate stage mixer with user config monitoring, independent from web based <1ms web based mixer, and the USB compliant io you can use to record with mixbus etc (arrives at your USB interface on PC at about 1ms latency. I am getting a B16 stagemixer and the AVB/USB interface. Pricey, but it solves about every problem I had and then some. I am selling off my Presonus and Steinberg gear. I really loved Steinberg, but the outright disregard for Linux that in my opinion exists at these companies makes it not palatable to own anymore. Presonus hardware in my opinion are great, but it is severely limited with little help when you ask to address the limitations which it was advertised as differently. Just wish there were a mixbus mixer in one of these stagemixers. I have gone through all the options and Motu it is the only one standing. the responses I got from other manufacturers ranged from the comical to outright ignorance of what users need. I have a feeling that AVB/IEEE will win over the ultranet stuff from Sony that is now licvensed out to someone handling it. that looks like a disaster to me. I am not going to invest in an interface that Sony the inventor did not want to pursue, it means that the profit margin must be about zero. We have unfortunaltely a bit of VHS vs Betamax again with AVB vs Ultranet, but I sure find AVB the better horse to bet on.

Hey all, until now, I have to admit, I never heard of Sonys solution. And I don't think it will become relevant. The following is my opinion, fuled by some presentations and discussions from the last AES convention. AES67 + ST2110 vs. AVB are Beta vs VHS in my opinion. Dante will be overcome as soon as people realize, that point to point connections are obsolete and open standards are better suited for such endevours. A transformation of the mindset is required and slowly coming. However, Meyersound, L'Acoustics and d&b Audio have set AVB as the standard for sound reinforcement systems. done. AVB has become the standard for automotive networking as well. done. AES67 is not specified for IPv6. With the stupidest of all explanations: we don't need it. AVB is agnostic to it, because it is layer 2. Yes, you would need an IPv6 gateway... AVB takes so long to get to the market, because it is trying to provide the best solution for packet based networks. That requires hardware support, which is not that trivial. AES67 is just some solution among others, this is a relabeled set of VoIP standards with some extensions (without proper standardized discovery mechanisms (SAP, ZeroConf, or whatever...) - why specifying AES67, when interoperability is not the goal???). AVB provides deterministic networking! you know what will happen! But this results in long development of reliable equipment, that conforms to the standards. Interoperability was also a big issue for AVB, but the MILAN protocol handles this now. But for educational purposes, AES67 is the best way to learn about Audio over IP. You can actually use VLC. My 50 cents... BR, Ck Am 23. Dezember 2018 01:40:17 MEZ schrieb liebrecht(a)grossmann-venter.com: -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

On Sun, December 23, 2018 2:27 am, liebrecht(a)grossmann-venter.com wrote: Do you need jackd and jack-sink module running at that point? I am not sure I understand from your question if you want the jack-sink feature running automatically when you start, or if you only want PulseAudio to not crash. If the latter then there should be a configuration file setting that is causing the jack-sink module to be loaded, you should able to remove that setting. In the fedora default configuration file for pulse, it checks to see if jackd is present before loading the module: ### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect channels=2 .fail .endif I cannot tell from the error messages whether the problem is jackd is not running when expected, or if jackd is running but for some reason Pulse cannot make a connection. -- Chris Caudle

The history of calling both jackd and jackdbus jack servers "jackd" did not make things clearer. Naming of module-jackdbus-detect.so already suggests that PulseAudio uses shared library to communicate with jackdbus (not jackd) and detect something (whether jack server in jackdbus is running). Whether suggestion is a fact or not is best checked in the source code, when documentation is not available. IIRC the information used to be in the jackaudio.org trac wiki. Maybe someone else on this list knows if the trac wiki is still accessible somehow. To my knowledge PulseAudio works better with jackdbus over D-Bus than with jackd. I'm even surprised it works at all with jackd. After all jackdbus is "jack server" that can be autolaunched, controlled and monitored over D-Bus :) When D-Bus was introduced to jackd, it was only for reservation protocol used for coordination (with PulseAudio) of audio device ownership/use. The purpose of this reservation protocol is/was to allow jack server take audio device ownership from PulseAudio. In contrast, jackdbus exposes jack server control API over D-Bus and also uses the audio device reservation protocol (which also works over D-Bus). PulseAudio (still?) uses the jackdbus control API. Also, systems with both jackdbus and jackd executables, while possible, are more complex to setup than ones with jackd or jackdbus only and at least some of linux distros keep proving this for years. Another common issue with such complex setups comes from the fact that libjack.so that is used by JACK applications, can autostart the jack server. libjack.so (source) code can autostart jack server in jackd or in jackdbus but which one is proper depends on particular system setup.

On Thu, December 27, 2018 5:00 pm, Nedko Arnaudov wrote: I am not sure if Fedora modifies the pulse configuration from the upstream defaults, but for quite a few releases now the pulse installed by fedora will give up access to the ALSA device without complaint when I start jackd. I looked in the system config file, and it does have some kind of jackdbus detection module, but that must only take effect of jackdbus is actually running, I have never seen it start jackdbus unprompted. That does leave pulse in the original state, which is with no jack-sink module loaded, but that is easy enough to load by hand when wanted. It seems from the configuration file that if jackdbus is already running when pulse starts that it should detect that and load jack-sink and jack-source modules. I'm not sure which configuration starts pulse at login, so I'm not really confident of the place to modify if for example you wanted to add a "jack_control start; jack_wait" command in the startup sequence before pulse was started. -- Chris Caudle

[sorry for the late reply to this one, I missed it the first time...] On 12/31/18 1:04 AM, Fernando Lopez-Lezcano wrote: Thanks for that hint. I'm about to get a MOTU for myself, so that's gonna be useful. Owwww. That sounds _very_ bad. I'm currently experiencing a similar problem on a Raspberry Pi when trying to cram 8 channels through a stereo I²S line, but I wouldn't have expected such things to come up in professional equipment. Well, as long as there is a known-good firmware version... Long as it feels truthy :-D Do you know whether the different AVB MOTU boxes are all the same in the way they handle AVB (as in, identical subsystem/firmware/drivers)? I'm eyeing the one with eight mic preamps (MOTU 8 Pre-es)... That's very good to know. Does it have a sane documented interface, or are you basically reverse-engineering the mixer website? I've been lurking on the open-AVB list for a long time, nothing much happened. Then I talked to an AVB guy with Meyer Sound at the last Tonmeistertagung, they just renamed everything "Milan" and are seriously getting off their asses now (probably panicking about the Dante camp just having announced basic video capability). Loads of new products, finally talk about cross-vendor interoperability and interesting plugfests (they showed Meyer AVB gear talking to Shure wireless units and some professional power amps by another brand). Let's hope some crumbs fall into the land of free software. All best, Jörn -- Jörn Nettingsmeier Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net

On 2/24/19 4:00 AM, Jörn Nettingsmeier wrote: Yup, not the best. Weird. Unrelated, right? How are you doing this, I presume you are not going through an alsa driver? (I would be interested to know more, I'm always interested in tiny computers that can drive many speakers or sample many microphone capsules :-) I imagine that would not happen if you were to use their proprietary driver instead of the class compliant driver. In this case I did not investigate much, I just downgraded and it seems to work (I have not reported the bug). Probably our use case never gets tested. There is. My latest _latest_ thinking says that what I said before is most likely wrong (like so many times before, ha :-). I think the whole thing happens on the Linux side, and is related to the USB interface. For example, I had forgotten I was running jackd with "-s" (long story about why that was there in the first place), once I removed that, things started behaving better. I just finished stabilizing our new setup in our renovated Listening Room (you know the space :-), still 22 main speakers but now all Adams, and 8 Dynaudio subs instead of the old 4 - much much better sound quality. New (fanless) control computer redone from scratch, and an all Motu setup for driving everything. Looks like it is running stable, 24x7, days on end with no glitches. Finally. The last problem was some kernel locking problem that apparently was happening between Supernova (the multi-core aware SuperCollider sound server) and aconnect of all things. I was calling aconnect from SC to detect changes in connected midi peripherals and sometimes this would (apparently) do bad things and the whole thing would grind to a halt. I switched to monitoring midi through /proc/ and that apparently did the trick. They all talk to each other as long as they are AVB (so far...). We do have one MOTU 8M (the one w/8 mic preamps) in the Listening Room and it is happy (we use its usb2 interface as the gateway into the system for external laptops). It is connected through AVB to one 24Ai, one 24Ao and a 16A which is where the control computer connects through USB). In the Stage we have 8 MOTU cards talking to each other (+ 3 MOTU AVB switches). It is documented... For OSC there is this (I have not tried osc): https://cdn-data.motu.com/downloads/audio/AVB/docs/OSC%20Quick%20Reference.… For http+JSON: https://cdn-data.motu.com/downloads/audio/AVB/docs/MOTU%20AVB%20Web%20API.p… Carlos (sysadmin here) sort of reverse engineered how to get a full preset from the data stream so we could capture those and resend them on demand. We are using http+JSON (form SuperCollider) to both read internal status (for example querying the master clock audio interface to see if its clock has locked[*]) and to change stuff (for example change the connection status of a crosspoint in the internal switching matrix of an audio interface) ... Same here, a few posts here and there that seem interesting but nothing that solves the whole problem (which is complex). Crossing fingers here... I'm itching to compile and start testing, no time yet. The MOTU is a reasonable option _now_ if you are aware of the caveats, but I have not much faith in the future given my experience with their firmware. At some point (hopefully very very far in the future) the internal _hardware_ will change - probably sporting the very same model number - and then we will not be able to downgrade firmware in really new boxes (I have seen that in the UltraLite AVB I have, the really old firmware versions for the card in their web site do not load in my UltraLite). If what is lost is the 64 channel mode that I need then: dead end again. The best would be to talk AVB from Linux. Or maybe reverse engineer their proprietary USB endpoints and adapt the Linux USB driver to be able to handle those? Or clean-room reverse-engineer Dante itself? Or be really _really_ smart and make music that only needs one speaker! (or one microphone capsule). Mono and Omni! YES! :-P -- Fernando [*] nasty things happen otherwise, the MOTU takes 5 or 6 seconds to stabilize its internal clock when switching sampling rates or when _first_ using the interface after a reboot. ALSA sees the interface all the time, and Jackd also sees it. But if you try to start Jackd while the MOTU is not yet locked... Jackd starts but then fails when it (maybe) realizes the card is not yet ready. If you are patient and wait a few more seconds and then try again jackd starts just fine. For fun: have pulseaudio running and set to 44.1KHz, try to start Jack at 48KHz (and repeat if not successful).... 0: jackd starts, gets the card from pulseaudio 1: jackd switches the card to 48KHz (while starting) 2: jackd fails to start because the card is not yet ready (unlocked) 3: jackd gives the card back to pulseaudio as it quits 4: pulseaudio switches the card back to 44.1KHz GOTO 0 Infinite loop! Infinite fun! More fun: have a MOTU card in 64 channel mode in a modern pulseaudio environment (Fedora 28, for example). Pulseaudio does not like the card as it has > 32 channels. It does NOT ignore the card. It thinks the card will be better behaved magically in the very near future as it tries again and again to use it (lots of messages in the logs). Jackd cannot "borrow" the card from pulseaudio. Jackd cannot start on that card (tip: I run out of patience so I just told pulse to ignore that card).

On 2/24/19 3:15 PM, Chris Caudle wrote: Motu provides downloads of proprietary drivers for both Mac and Windows. I have not used either of those two "exotic" platforms, but I'm pretty sure that when using their proprietary driver on a Mac you would have access to 64 channels over USB2 if the sample rate is limited to 44.1 and 48 KHz. Again, on a Mac you would also be able to use thunderbolt for machines that have that, and Motu interfaces that have that, and that will give you 128 channels (proprietary driver again). If using the class compliant drivers, you would be limited to 24 channels (with the newest firmware). Don't know about the channel shifting. In any case, I don't know what a Mac would do without the proprietary driver, maybe its own class compliant drivers would be just fine with the class compliant USB endpoints of the Motu interfaces. Maybe not. -- Fernando

On Tue, Feb 26, 2019 at 01:06:46PM +0800, happy musicmaker wrote: I realise the form factor probably doesn't suit your use case, but the Yamaha TF series mixers seem to work well as a recording source under Linux. Sample rate is fixed at 48 kHz. 32 inputs (plus, I think, from memory, a selectable stereo bus) are accessible via USB using the standard kernel snd-usb class compliant driver. The TF1 (16 pres and faders) and TF3 (24 pres and faders) would require the use of at least one Dante remote stagebox to get a total of 32 pres. Regards jonathan

On a pretty long thread on the Ardour forums someone recently wrote this: "The ALSA driver (based on the intel igb driver) can use any buffersize down to a single interval. "The lowest round trip latencies (analog to analog) on my 16A therefore are 1.5ms at 6/48kHz to 0.75 ms at 24/192kHz measured with jack2 in synchronous mode." No response after several days to my request for a link to a repository containing that ALSA driver. -- Chris Caudle

I really have perpetual problems with jack. It just stops fro no reason I am aware of causing and go awol All of my applications reports it cannot be started sudeeeeenly. qjackctl reports the following. Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock I realy wan to use jack, but it goes awol periodically. Mixbus used to work great, but now mixbus cant start jack anymore. Isnt there at least some for of user debug frontend for jack that can point to the errors. Jack is greast but hyper unfriendly and I am willing to learn, but it is just a dustball of irrelevant information and nothing really sticks that I can use. If someone can help with a procedure so users can help themselves it would be really nice to make jack a bit more user friendly.

The jack community must start doing something not to endorse qjackctl. It creates way more trouble than it solves. I just completely removed qjackctl and reinstalled jackd. I still have problems but at least now without qjackctl, Mixbus at leat starts jack, but there is no sound from my 181vsl detected. The 1818VSL flawlessly works at least within its specs. I can use it on linux to play through it with pulseaudio, but NOT with jack. Mixbus starts Jack successfully it reports, and sees the 1818vsl. I know mixbus really sees the 1818vsl since if I powercycle the 1818, then I get a popup from mixbus that it lost the device. The 1818vsl is connected to a keyboard through spdif and works with windows and Presonus's flakey software (until the wincrap crashes or hangs) so I know that the keyboard/spdif/19818vsl,USB all work. No hardware problems. However JACK absolutely refuses to send or recieve data for Mixbus. However choosing ALSA as driver in Mixbus gives the same result, 1818vsl is recognized, but absolutely NO so0und to or from 181 to mixbus. Since there is no way to find out how mixbus routes things, it is not and probably never will be made clear to joe user like me, but since both jack and alsa cannot work with mixbus and 1818vsl, I must guess that Jack uses Alsa, and if alsa wont work with the 181vsl then jack wont in principle either. Before I completely uninstall alsa and reinstall I first want to find out if jack is in error. This setup worked great for a month on Linux before it borked itself. I have sour suspicion that somehow systemd is at the source of these problems, how I dont know, but systemd has been the culprit with several of my other applications that turned awol the last month. There must be a better way to manage the entire alsa/jack thing. It is a real royal pain to figure out. Jack is great software with enormous potential and get people maintaining it, but there must be a more transparent way for joe user dealing with it. On 2019-03-22 02:40, Filipe Coelho wrote:

Thanks a lot Ralf, I am moving to Motu which will really6 ease things up. The Presonus gear is not very well thought through, but it is not the problem here. I am hesitant to use jack as it almost never work consistently, pulseaudio at least works. If I uninstall pulseaudio I will lose all my bluetooth enabled ipads and galaxys etc. That works just great. Pulse has other problems being a systemd applicat5ion there is a lot of built in garbage I agree, but wihout it I dont think anything can take its place currently. If jack would just be deterministic, I can work with it. I wrote some of the most complex software on this planet, but it is difficult for me to understand jack as it has no consistent specification. I have read all I could find on the web, and it is involved and well done, but with no consistent specification a uesr can actually get a handle on how to use it creatively. I used pulse and jack together for about a month with no problems, then jacki just went awol for no apparent reason with no updates or software installed in that period. I dont know what triggered it. Since you say pulse does it, what is the exact mechanism by which pulse interfere with jack. I f there were a rigorous specification for jack, it would be easy to understand and work through these problems. I would love for jack to work, but it keeps biting me, and i am willing to understand it but it seems to be etherware, which works very well just outside userspace. As I understand it jack should be an either/or/add switch for audio streams but that functionality is not properly declared. I found that jack seemingly does not really do direct hardware access, which further complicates things. If it in principle rely on alsa then those interfaces needs to be very well documented how it communicates with alsa, what the exceptions and conditions are etc. Without Jack Linuxaudio becomes rigid and an everyone competes for the same port type of situation, that is why I stick to it, but if there was e.g. just a hard patchbay application that would replace jack I would use it in an instant. It would not be elegant but would clearly route signals by hand. That is maybe what is needed until jack becomes user friendly. On 2019-03-22 03:46, Ralf Mardorf wrote:

Thank you Holger I will work through this, I see what you mean. If I can just get jack to have repeatable problems, then I can work with it, but at the moment it all seems random. Re Motu, it cuts my dependency on a specific OS and has a great web based mixer, while it is usb complaiant with linux, Heaven! That way at least I can cut my problems in half. I will still have the jack usb/midi problems, but at least I have a rock solid os independent mixer option. The 1818vsl is Do$e only and is a horrible flakey piece of software. Huge upgrade. At least Motu is Linux friendly compared to most of the other manufacturers, so I go that way. On 2019-03-22 04:27, Holger Marzen wrote:

Here are some: I know several people who use the ultralite in studio and on linux and they have much less trouble. The ultralite is the key to the entire Motu/Linux path. You use the Ultralite as your usb interface with everything else motu/AVB. then from the ultralite by avb to everything Motu has to offer, stagemixers etc. If the ultralite works with Linux, then all other functionality through AVB works if Linux drivers/software is up to the faster rate of the Motu compared to Presonus. I have confirmed several times that the ultralite is a way way better option on Linux from several users actually using it in studio. I take my advice from actual studio use producing commercial results and listen to what those people say rather than just heresay. 1) a) MOTU Can do stage mixing independent from OS, with Web based Mixer. I dont have to work on buggy Do$e with a usb connection at all. b) Presonus 1818VSL on Windows crashed several times with me on windows while recording ! 2) a) Motu No Mixer startup issues reported on Motu browser based mixer. You connect with a browser and thats it. b) With 1818VSL, if you start studio one/stagemixer then 1818vsl doesnt work -period. Procedure: You have to cycle power on 1818VSL , then go to setup, then go to 96kHZ, it still doesnt work, then go to 44.1kHz, then it works. Absolutely blatantly stupid working with it on windows. The Studio software cannot even initialize its own hardware on windows on several windows distros I had. How about is that? 3) Motu: I verified that browser based Motu works at whatever rate you want as the rate setting and routing is obviously inside the Motu device. Presonus seemingly is USB and connection dependent and everything seemingly tries to route over USB to studio one. Thats what it looks like, giving the consequences I experienced. On Linux the 1818 VSL can work at most higher rates. Alsa reports 48kHz. On windows 1818VSL with its own software cannot work at higher rate than 44.1kHz on any distro of windows I tried. - go figure. This has been so since onset tested over several Windows distros. I can work on Linux at a higher rate than on windows which I always found curious. 4) OS independent performers level mixes by wifi or network. Presonus, never to my knowledge even came close attempting this. 5) USB compliance seems to be way better than Presonus. Since you will be using the Stagemixer through an Ultralite with USB, and several people confirmed the Ultralite works great with Linux on USB, at least better than the Presonus 1818VSL, using the stagemixer becomes trivially the same as issues with the Ultralite. 6) Up to 100ft AVB connection between Stagemixer and Ultralite, then ultralite USB. Most rugged system we currently can have for Linux. I couldnt find something remotely similar with presonus that can work with linux. 7) With 6) I have still the ethernet/Browser mixer on Motu I can use also, thus redundancy. No such redundancy with the 1818vsl, or any presonus I dont own that I read up on in my opinion. 8) Way better preamps on Motu in my opinion. 9) I dont care if the effects plugin on the Motu browser mixer sucks. Anyone who uses plugins live looks for trouble. I use hardware echo/reverb. Rugged as hell. All you need is that the preamps are the best it can be from the mixer and that you can route to external hardware. No problem with Motu. 10) I use USB for recording only on Linux at the same time I use the network/browser based mixer for live mixing through ethernet.. I couldnt find this possible with presonus. There is no way with presonus to run the Studio mixer and have USB connection concurrently to linux. Absolutely no contest. 11) From what I find, if users have sudden problems with Motu like buffer overruns etc they did not have with presonus, it is because you now suddenly have the ability to do 96kHz on Linux where with the presonus I could never get to work above 48kHZ. If I could, I would have had a lot of trouble at 96kHz due to the higher data rate. So the xrun errors and stuff they report with motu should be put in contect that the presonus in my opinion doesnt do 96kHZ so there is no comparison of the level of problems as rates are not equal. So in short there is no contest.. even close. If you want to discuss Linux issues with Motu, then it all boils down to Linux issues with Ultralite as that is your interface to the entire Motu system and products. As I mentioned I get way more positive feedback from Motu studio users with Linux compared to Presonus. Above all I will rather use Motu as I will always be able to work regardless of Linux issues. There is always another option and redundancy with Motu. My experience with 1818vsl on windows is way more troublesome in the long run than any jack issues I can have. Most importantly. Motu is always willing to help you get something that will work with Linux and at least acknowledges Linux. Not so with Presonus. So why even bother. AFAIK no contest. On 2019-03-22 11:57, Holger Marzen wrote:

There are the FAQ pages at the main jackaudio web site: http://jackaudio.org/faq/pulseaudio_and_jack.html https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_Pul… -- Chris Caudle

On Fri, March 22, 2019 2:43 pm, liebrecht(a)grossmann-venter.com wrote: That is why the official Ardour recommendation is now use the built in ALSA backend, jackd is for expert use only. Seems to complain that there is no jack server available. Likely pulseaudio was started before jackd, so the pulse-jack modules have no jack server to make the connection. -- Chris Caudle

On 2019-03-22 23:30, liebrecht(a)grossmann-venter.com wrote: That would be the experts on Jack. Anyway. A couple of month ago you asked about advice to chose a Linux distribution for audio purposes. I believe you chose AVLinux. It might be a good idea to check out some other distros and preferably one you can boot and run from USB/DVD (live). I've been using Slackware, RedHat, Gentoo, Jacklab, Opensuse and now Ubuntustudio for audio. All having their pros and cons during the years. Ubuntustudio, while it's not a perfect distro it suits my need at the moment, and does boot it's iso in live-mode. And for what it's worth it was the first distro that I've been able to install and just run without a hassle in regards to audio distro. https://ubuntustudio.org/download Another suggestion would be to ask advice on the AVLinux forum. It seems to me that your problem is more a distro specific problem than a jackd one. I might be wrong though. Cheers, -- /bengan

On Sat, 23 Mar 2019 08:52:57 +0100, Ralf Mardorf wrote: My apologies, I'm still half asleep :D, it's early in the morning. To make it executable run chmod a+x luamd64_1610.sh

Thank you, this is helpful I will adapt the script to work for me.

Sorry to barge in - I don’t really have anything to add as such but I wanted to say that on the one hand I can understand the frustration about pulse, alsa and jack - it took me a very long time to get to grips with Linux audio. On the other hand now that I have waded through an expansive marsh of online documentation, mail list and forum posts and done a lot of trial and error, I very much prefer the vastly superior configurability of linux audio to the mysteries within Windows. Windows works fine for web browsing, Skype calls etc, but is horrible for any advanced audio routing unless it is directly hardware supported (RME has their nice mixer/router system eg). I suppose it’s all down to a combination of learning curve and personal taste... That is a brilliant script that I may just implement straight off the shelf!! Thanks!! Regards, Anders

On Sat, 23 Mar 2019 20:28:47 +0000, John Rigg wrote: That's true for some of us, you and me. OTOH you could edit a radio interview using a remote control and bluetooth headphones sitting in your garden, instead of sitting in your studio. A workaround could be to use USB audio with bluetooth instead of just using bluetooth, see https://linuxmusicians.com/viewtopic.php?f=18&t=19721#p1038003800. -- pacman -Q linux{,-rt{-pussytoes,-cornflower,,-securityink}}|cut -d\ -f2 5.0.3.arch1-1 5.0.3_rt1-0 4.19.25_rt16-0 4.19.23_rt13-0.1 4.19.15_rt12-0

On 2019-03-23 16:28, John Rigg wrote: Completely purged pulseaudio from my system. Reinstalled jack. Made sure only jack and alsa is installed jack still wont start - go figure. I guess now it will be alsa's fault since pulseaudio is not around anymore -- just following the logic. < I've used jack since 2005 in my work as an audio engineer, I totally agree with you. Jack is indispensable. Since you get it running with such impunity, why dont you write it up in a document from scratch how you get it up reliably and help us all understand what is needed. I for one will REALLY appreciate it. Nope and not true, see next answer below. There is an expert user and there is no other "expert" except the program developer. The programmer is the only expert on the other side. You cannot ask users to become program developers. We are talking on expert users here right ? Excuse me.. The API is not even remotely a user specification. It is more of the definition of an interface for the programmer and has nothing to do with the user. There is no specification as it stands A specification in Layman's terms will describe the proposed software to be released as a "Black Box" and that is long after the API. The specification is for issuing to the the operator if it is consistent and is NOT an operation manual. It is the testbed conditions to evaluate the software, clearly repeatably and consistently, by anyone wanting to use it. In modern days, simulators of a piece of equipment running software can be viewed as a dynamic form of specification as it can only operate within a specification to be valid. The simulator is written on the basis of the blackbox behavior. Obviously not the API as it involves the programmer. A specification evaluates the software independent from its creators equally valid for anyone, no bias. 1) Therefore you need to define inputs outputs. This has several subsections. 2) Points of instability. 3) Operational Dependencies on other software. ...and the list goes on. There is no formal /specification which would force the software into a usuable object by testing it against specification or junk and rewrite if it doesnt conform. I understand that specification is not really a commercial/casual thing, as linux is, and rather for mission critical situations, but it would not hurt to adopt it as it will be usable to general users if it conforms to a general black box specification and save everyone a lot of time. If I wrote the software I would do it, but I understand that it is unfortunately not the norm in civilian software development which is a pity.

Thanks for your kind help Ralph, I appreciate it. I reinstalled qjackctl, Configured it in the setup to use VSL (the 1818VSL) Run start and it starts. Here is the output. 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 JACK server starting in realtime mode with priority 10 self-connect-mode is "Don't restrict self connect requests" 01:44:00.249 JACK was started with PID=18192. audio_reservation_init Acquire audio card Audio1 creating alsa driver ... hw:VSL|hw:VSL|256|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 256 frames (5.8 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback port created: Midi-Through:midi/playback_1 port created: Midi-Through:midi/capture_1 port created: AudioBox-1818-VSL:midi/playback_1 port created: AudioBox-1818-VSL:midi/capture_1 port created: USB-Uno-MIDI-Interface:midi/playback_1 port created: USB-Uno-MIDI-Interface:midi/capture_1 port created: MidiSport-1x1:midi/playback_1 port created: MidiSport-1x1:midi/capture_1 port created: rosegarden:midi/capture_1 port created: rosegarden:midi/playback_2 port created: rosegarden:midi/playback_3 port created: rosegarden:midi/capture_3 port created: rosegarden:midi/playback_4 01:44:00.349 ALSA connection graph change. 01:44:02.472 JACK connection change. 01:44:02.475 Server configuration saved to "/home/johhnycrash/.jackdrc". 01:44:02.476 Statistics reset. 01:44:02.485 Client activated. 01:44:02.486 Patchbay deactivated. 01:44:02.487 Post-startup script... 01:44:02.488 /usr/bin/pajackconnect start && a2jmidid -e & 01:44:02.574 JACK connection graph change. sh: 1: /usr/bin/pajackconnect: not found 01:44:02.893 Post-startup script terminated successfully. With jack started with qjackctl, Mixbus fails unfortunately the same way as before. [ERROR]: JACK: Cannot callback the server in notification thread! [ERROR]: JACK: Cannot callback the server in notification thread! [ERROR]: JACK: Cannot callback the server in notification thread! [ERROR]: JACK: Cannot callback the server in notification thread! [ERROR]: JACK: Cannot callback the server in notification thread! [ERROR]: JACK: Cannot callback the server in notification thread! [ERROR]: JACK: Cannot callback the server in notification thread! Mixbus sends its own start string with jack, so I expect it will fail since if jack works correctly, then mixbus always starts it without any help from qjackctl as I found. On 2019-03-26 01:40, Holger Marzen wrote:

Mixbus was the only reliable use I could get out of jack in the past, but lets give up on that for now. I have to killall -KILL jack and especially qjackctl a couple of times until I get jack to start with qjackctl. It seems jack starts as I see it as a process but qjackctl falsely reports it as not being started. After a few kills it eventually sees it. I will just start jack with a string as I did in the past and drop the qjack thing, but for now I will try and use it. I can confirm that I get sound out to the 1818VSL by using a Synthesizer organ app. SetBfree. I can play keys and it is passed to the 1818vsl, however I have no functional global volume controls as my keyboard mappings are not recognized by jack or whatever now handles the mappings. Its all raw maximum volume. The output from qjackctl seems to indicate that setbfree uses jack. 02:47:49.435 JACK connection change. 02:47:49.752 JACK connection graph change. Destination port in attempted (dis)connection of setBfree DSP Tonewheel Organ:control and system:midi_capture_1 is not an input port So does jack even have a mixer of some sort so I dont have to blow the walls down with the default settings as it is now.?

Thank you holger. The remaining problem I now have is for jack to see the 1818vsl inputs. It looks to me if mixbus will work if jack can just successfully route the 1818vsl inputs to mixbus. The inputs is seemingly reported as some system device inputs in the patchage diagram. Would you mind to take a look. We know now that the outputs to the 1818vsl works as it should, but inputs seems missing. I start jack now by command line and skip the qjackctl abomination. I installed patchage and my setup is as follows. Mixbus runs and is connected properly, and should output sound as its output is connected to the same output as setbfree which works as clear from patchage. The problem with mixbus is the inputs. I have a known to be working and tested spdif keyboard connection that mixbus dont see any input for. It is correctly configured in mixbus, it is just that it now cannot get any signal from jack. See the patchage output. Unfortunately patchage doesnt have a horizontal configuration so text might be blurry as it is all portrait and thus small. "http://grossmann-venter.com/issues/jack/patchage_status-01.png" On 2019-03-26 03:29, Holger Marzen wrote: Ok, I see and get the hang of it rather quickly now. Just a VERY SERIOUS request. Insist that any newcomer completely PURGE pulseaudio before they get help here. It will save everyone a lot of time. Even the taskbar applet which interfered and I had to uninstall it to get jack to work. Once jack works then tell them try to get pulse back in a responsible way. This should be stressed in bold letters on top of the manual and the first response to someone asking for help rather to say that pulse can work but is troublesome. Pulse wasted months of my time and we can avoid it by just removing it as it is written in a ramrod way with no regard to other applications, almost as bad as systemd.

On Tue, 26 Mar 2019 08:29:15 +0100 (CET), Holger Marzen wrote: Hi, I doubt that alsamixer provides a volume control for any class compliant usb audio interface. On Tue, 26 Mar 2019 02:13:05 -0400, liebrecht(a)grossmann-venter.com wrote: If jack runs on a "normal" configured system, then only jack has access to the audio interface. IOW only jack clients can use the audio interface. If jack does not run on a "normal" configured system, all software compiled to work with plain ALSA could use it, but only one app can use the device at a time. A system configured with dmix might be able to provide the audio interface to more than just one app, but I'm not using it. On my system firefox is build with ac_add_options --enable-alsa ac_add_options --enable-jack alternatively I've got https://github.com/i-rinat/apulse installed. Since a while apulse doesn't work anymore, at least not for me with Firefox. Assuming your distro or you compiled Firefox with the mentioned options, then it still works with ALSA or jack. At least Falkon, Pale Moon, Vivaldi, Opera and for audio and video the best off all Google Chrome can be used with plain ALSA, too. Regarding bluetooth I already provided the pointer to https://linuxmusicians.com/viewtopic.php?f=18&t=19721#p103800 which leads to https://www.amazon.ca/gp/product/B01G3J1I5M/ref=ppx_yo_dt_b_asin_title_o03_… , probably something like this could be ordered somewhere else instead of Amazon. Regards, Ralf -- pacman -Q linux{,-rt{-pussytoes,-cornflower,,-securityink}}|cut -d\ -f2 5.0.4.arch1-1 5.0.3_rt1-1 4.19.25_rt16-0 4.19.23_rt13-0.1 4.19.15_rt12-0

That's true since some interfaces don't have a software-controllable hardware mixer. The routing everything over jack-mixer is an option (and maybe ALSA's software mixer, but don't try this at home, kids). Bluetooth is another endboss. I could use it with ALSA-clients but not with jackd. I don't know if it's due to the lossy codec that's common with Bluetooth devices.

On Tue, Mar 26, 2019 at 1:56 PM John Rigg &lt;jd(a)jrigg.co.uk&gt; wrote: Which wouldn't work very well because it would have to double up the number of connections and constantly monitor the graph, which would mess up all sorts of things. It was discussed 15 years ago or so whetnhr the ports should have volume control. Unfortunately, I think someone argued against it, for some reason. A big mistake in my opinion. It shouldn't be hard to add though... Another fun project for jack would be to add a pulseaudio driver. It's just so messy to keep these two systems working together, so a nice solution would be for jack to simply output to pulseaudio.

On Tue, Mar 26, 2019 at 3:08 PM Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: I think of jack mixer programs. If you want to create a mixer that wants to change the volume between a jack port connection, you need to change the graph by inserting a clients between the existing ports. Well, Jack is not an analog audio studio. Why should we artificially limit the opportunities of the system? Sorry, but that's not a valid argument. This is a very small feature. Only one function is needed: "jack_port_set_volume" or something like that, and the modifications to jack would be very small and straight forward, and the advantages could be enormous. A general jack mixer program would be so useful in all sorts of situations.

On Tue, Mar 26, 2019 at 05:30:46PM +0000, John Rigg wrote: This is indeed the reason why I wrote zita-mu1, it provides monitoring controls (including volume) independent of whatever set of applications you are running. Re: using Jack - today I had to demo some of the things I've been working on to my boss^3 (i.e. the boss of my boss of my boss). That meant three complex systems, in principle all independent of each other but sharing some sources and each of them had to be available instantly, and so everything was running at the same time. One outputting via a Babyface Pro (4 chan), one via an USBStreamer (8 chan), and one sending 32 channels via zita-j2n to a Windows machine. In total something like 20 Jack applications, and more than 500 ports and connections. All controlled by Python scripts of course, this would take an hour to set up manually. The VERY LAST thing I'd want in such a system is a gain control on each Jack connection. One very big advantage of digital connections, be they MADI, ADAT, Jack, or Dante, is that signal levels at all inputs and outputs are exactly defined and can't change. Setting up a a similar system using analog connections with variable gains would be a real nightmare. Just my 0.02 Euro of course, -- FA

On Tue, Mar 26, 2019 at 10:12:32PM +0100, Kjetil Matheussen wrote: You never 'need' it. You may need level/volume controls, but mixing those up with connection management doesn't make any sense from an operational point of view. I'm old enough to have worked in environments (like a broadcast center) with thousands of analog audio connections (between studios, transmitters, OB-vans,...). Extreme care was taken to ensure that every connection was absolute completely transparent and level-neutral. It's the only way to remain sane if you are doing anything above trivial level. Thank $(GOD) all of this is digital today. Caio, -- FA

On Tue, March 26, 2019 4:42 pm, Kjetil Matheussen wrote: That sounds like endless amounts of frustration to me. It is already bad enough that some audio interfaces change gain without the change being obvious, and you have to verify that the input and output levels are what you expect. Apparently that very behavior unfairly engendered much ill-will toward jack by the original poster of this thread. Or you could connect up non-mixer in 10 minutes. Not sure what problem you are attempting to solve here. And as Robin pointed out it would completely break the design of jackd. I think you are attributing what you think you want to "most" people, but I do not see any evidence given for that. It sounds like a terrible idea to me, and I am sure that "most" of the people who understand how jackd works and how to take advantage of that would also think it is a terrible idea. And I am very sure that "most" of the people who understand how jackd works and have the ability to modify the design think it is a bad idea, or someone would have done it already. The source code is available, if it is such a good idea code up a prototype and see how it works out. -- Chris Caudle

On Tue, March 26, 2019 6:04 pm, Thomas Brand wrote: Yes, I apologize if my response sounded too harsh. And on a hopefully more constructive note, perhaps in several months the pipewire server may be able to provide some of the alternative use cases. The desire is that pipewire can replace both pulseaudio and jackd in a system, as well as provide a similar service for video. https://pipewire.org/ I do not know how much is implemented currently. The jack API would probably not have any gain controls, but the pulse API would have to implement something like the current pulseaudio mixer to be usable as the main desktop audio server, so it may be usable for something like what was requested. -- Chris Caudle

On 3/26/19 8:02 PM, Tim wrote: I just thought of something. That right there IS a form of scaling. Normalization of integer values to floating point values is just like scaling. If said gain control proposal was to be implemented, would it not be right here, around the normalization stage, where the gain factor could be introduced, and why would this cause any further speed problems as mentioned? Or is the problem communicating the actual controlling values - the gain controls - to the hardware, causing a delay? Thanks. Tim.

On Tue, Mar 26, 2019 at 08:02:29PM -0400, Tim wrote: That is NOT what I said, there is nothing wrong with a gain control in the digital domain. My argument is that having a gain control in *every connection* makes it very difficult to ensure that any non-trival system will have a sane level structure. There is no benefit. The FP format Jack uses is at least as precise as 24-bit integer. And consider that even if you have a 24-bit (or more) converter, at most 20 or 21 bits are actually valid, the rest is noise. There is nothing 'pure' about the integer values. You can easily test this: use two channels to convert the same analog input signal, and compare the digitial values. You may be surprised. Ciao, -- FA

Hi, tomorrow is April Fools' Day, it's not today. Changing the subject within a thread is bizarre, at least consider to start a new thread with new References/Message-ID headers and a subject like "Full-featured mixers - Was: Jack Problems" next time. However, since audio device hardware mixers are not related to jack, there unlikely is large attendance on this jack related mailing list. Btw. GUIs for alsamixer gain nothing for USB compliant devices that don't have alsamixer volume controls. My opinion regarding QasMixer: Running the ncurses user interface alsamixer in ROXTerm, or your terminal emu GUI of choice, is nearly the same as using a GUI. I suspect for most of us it doesn't make a big difference. Anyway, usually class compliant USB devices don't have alsamixer volume controls and some cards sometimes don't work well when using alsamixer. I experienced issues (probably bugs) when using an Envy24 card with alsamixer and got rid of it, when using envy24control or mudita24. Regards, Ralf -- pacman -Q linux{,-rt{-cornflower,-pussytoes,-securityink,}}|cut -d\ -f2 5.0.5.arch1-1 5.0.5_rt3-0 5.0.3_rt1-0 4.19.31_rt18-0 4.19.23_rt13-0.1

On 3/31/19 3:46 PM, David Nielson wrote: Yes, you can :) There is a headless version of Ardour that can be remote-controlled (e.g. via OSC) and also an interactive commandline version that evaluates Lua. It'd probably be overkill though. That reminds me of https://discourse.ardour.org/t/route-all-system-inputs-to-all-system-output… An alternative (LV2 and OSC controllable jack-app) might be https://github.com/x42/matrixmixer.lv2 -- it's not a mixer in the classical sense with stereo-pairs and balance controls though. Cheers! robin

On 3/31/19 5:58 AM, Ralf Mardorf wrote: Sorry for the re-title. Faux pas. I should refrain from blurry-eyed from 4AM posts. I wasn't sure if I should start a new thread on LAU since it was kind of related. Yes there is the envy24 mixer and Mudita24 (which I helped with). QasMixer does a good job of showing everything except the meters that the other two mixers have. I seem to recall that the meters are actually ALSA components. Maybe they could be added to QasMixer. Tim.

On Sun, Mar 31, 2019 at 04:41:12AM -0400, Tim wrote: Have you tried non-mixer? It's been working well for me for the last five years or so. If I need hardware mixing I use envy24control or hdspmixer. A question: since Jack works with several audio backends, not just alsa, are alsa mixers like alsamixer, envy24control and hdspmixer actually relevant for discussion here? John

On Tue, Mar 26, 2019 at 11:46 PM Chris Caudle &lt;chris(a)chriscaudle.org&gt; wrote: You should not use it if you don't need it. Ah, good question. At least for me, the main problem is that it's often inconvenient to set the output volume of the clients. It's not a big problem, but it would be easily solved by a general mixer program. This mixer program would probably be used in other ways as well, I don't know. Thing is that it's a natural tool one expects to be there, but for some reason is not. It makes jack look bad. And, yes, as I, and many others afterwards, including you, have pointed out, you can hack this by inserting clients in between connections and so forth, but that very inconvenient and can lead to various problems such as breaking automatic patching and left-over clients. That's probably not correct. I don't think this is so important that I would spend time implementing it, I'm just pointing out that it's something jack is missing. It should be a fun project though for anyone who's got some time to spare.

On Tue, Mar 26, 2019 at 10:42 PM John Rigg &lt;jd(a)jrigg.co.uk&gt; wrote: That's not necessary. Unless port_set_gain is called, it wouldn't change anything.

On Tue, March 26, 2019 23:02, Robin Gareus wrote: I had doubts about *when* port gain would be applied, and what you say Robin makes it clear, basically all of how client ports are ordered for processing one cycle could potentially be affected, and the smart aspects therein would be in question. If ports would have that feature, the next desire would be to automate it, and it's easy to imagine more DSP that JACK could do, and then we'd move more and more client work into the server. Instead scaling the signal (or any other DSP) should clearly be something that only non-servers should perform IMO, that are clients (normal or internal). For a simple mixer: loading an example FAUST script and render a jack client (without ever touching a compiler, online) isn't too hard either :) Another note, we can imagine that a metadata property flags a port with a coefficient, and then client can scale it (as a first or last DSP step) accordingly. Any thoughts? Greetings Thomas

On Tue, Mar 26, 2019 at 11:03 PM Robin Gareus &lt;robin(a)gareus.org&gt; wrote: I don't think this is correct. First of all, you don't have to do anything differently than now unless gain volume has been set. Secondly, you would only need to apply volume to the sound block returned by jack_port_get_buffer in the client. If that sound block is used for other things as well, just make a temporary copy before applying the volume. Yes, true, but not a big thing to implement. Doesn't matter what it's supposed to do. Do what makes sense. Do what gives the biggest benefit for the least amount of work. Yes, as I wrote. But that's a hack.

On Wed, Mar 27, 2019 at 12:17 PM Filipe Coelho &lt;falktx(a)gmail.com&gt; wrote: I don't know how the jack client implemetns jack_port_get_buffer, but it does have to mix down all connections anyway if there are more than one port connected to the input port, right? So this problems doesn't sound like something to make a big deal out of. Do you think gain would break anything? How could it break anything when nothing have to change if gain is not set? I don't know what the meta-data API is (jack contains lots of thing that very few people would ever have use for, but basic things like setting connection volume should not be there? Esoteric stuff is fine though, but basic things should have higher priority). Anwyay, I meant that inserting an internal client (or a regular client) in strategic places is a hack. This sounds like something very few people would ever have any use for. Jack has two main functions: 1. Provide a nice realtime API for audio and MIDI so that several programs can output sound and MIDI to the hardware at the same time. 2. Occasionally send audio from one client to another. For instance record everything going to the loudspeakers. Other than that, it's special interest usage, such as what Fons is doing, which is great, but the main focus should be on the 2 points above.

On Wed, Mar 27, 2019 at 1:01 PM Fons Adriaensen &lt;fons(a)linuxaudio.org&gt; wrote: Hmm, I'm looking at your program right now. Maybe you are right. Maybe what we need is a way for clients to tell the server that we want to be the mix-master, the program that all clients connects to by default.

On Wed, Mar 27, 2019 at 12:04:41PM +0100, Kjetil Matheussen wrote: Not true. When there is only one output connected to a Jack inport port, the receiving client does not have its own input buffer, it just gets a pointer to the output buffer of the source client. So when you change the gain to anything non-unity, a new buffer needs to be allocated (since the output buffer can't be modified, it may be used by other clients as well). This needs to be done in a real-time context and without interrupting the signal. Possible, but not as simple as you imagine. Same problem in different words. A 'temporary copy' needs extra space which needs to be allocated. And doing the gain operation there means it is applied to the mix of all incoming signals, not to one particular connection. Not so trivial if you want to do it right. For example the ways a good mixer will smooth a fader gain change and a mute/unmute will be quite different. It does. Jack has one clearly defined goal: to interconnect audio processors. The processing itself is not part of that. Where would it end ? Add delays, EQ, plugins to every connection ? Which is the current situation. Ciao, -- FA

On Wed, Mar 27, 2019 at 12:45:47PM +0100, Kjetil Matheussen wrote: Yes, it would need an option to disable it. It's not unusual to have a few hundred ports in a complex setup. A single MADI interface uses 128 ports just for the hardware in/outs, for example. John

On Wed, Mar 27, 2019 at 2:10 PM Sunset Tech &lt;swansong.tech(a)gmail.com&gt; wrote: The point isn't that its' not that much trouble to do. The point is that it would be better if there was no trouble at all doing it. It would be better if there was a program running all the time, which didn't require work to start or set up, which was automatically started for instance by qjackctl, that you could switch to to adjust volume levels. Now you have to do all sorts of things, so instead you normally just reach for alsamixer or a physical volume control if you have that. If jack ports had had a gain function from the beginning, someone would have, by all these years, made an easy to use + no-setup-required jack mixer program (currently it's impossible to create a program like that), and there would have been one less jack frustration.

On Wed, Mar 27, 2019 at 3:08 PM Sunset Tech &lt;swansong.tech(a)gmail.com&gt; wrote: Clutterered or not, this functionality is something pulseaudio/windows/osx all provide, but not jack. Is jack better because it doesn't provide this? No, it's worse. Granted, a properly made mix-master client seems like a better solution, actually a much better solution, but a mix-master client requires that all clients autoconnect to the mix-master and not to the physical output ports. This can of course be hacked by monitoring the clients and so forth, but that would also be a hack that guaranteed would create frustrations, so first of all jack needs functionalities for providing default ports for the clients to connect to, and then all clients need to support connecting to the default ports. Probably not. You would need many many thousands of jack ports, or run some kind of tiny embedded device, for the memory usage to be of any size anyone would care about. Most people probably have no more than around 20 custom ports + sound card ports at any time. Well, you would normally use alsamixer instead of amixer.

On Wed, Mar 27, 2019 at 03:44:07PM +0100, Kjetil Matheussen wrote: No, it's decidedly better IMO. Complexity isn't always an improvement. Memory usage isn't the only concern. There's also the additional processing time involved. I already have occasional problems with jack clients unable to finish executing in time and getting kicked out of the graph, and that's with large buffers and port numbers only in the hundreds. CPU load doesn't have to be high for this to happen, so I'm assuming it's a scheduling problem, which can only get worse with an extra gain stage for every port. In 14 years of jack use I've hardly ever used such a small number of ports. I'm probably not 'most people', but I'd expect a pro audio application to cater for typical multichannel recording and mixing as encountered in a professional studio. If you want to make it easier for more casual use fine, but please don't hobble it for more serious use. John

On Wed, Mar 27, 2019 at 05:35:04PM +0100, Kjetil Matheussen wrote: It is NOT an improvement. It is an application which you can use if and when you need the functionality. It can (and probably will) be modified or extended as required without interfering with the work of the Jack developers, and without them interfering with mine. Even if you would move all the DSP operations in zita-mu1 into Jack (switching, gain ctl, crostalk filters, RMS, peak and correlation detectors), you'd still need a separate program to provide the GUI. So nothing would be gained by doing that, it would just complicate both maintenance and use. Ciao, -- FA

On Wed, Mar 27, 2019 at 05:54:31PM +0100, Kjetil Matheussen wrote: This is sophistry. Having zita-mu1 to use when required is an improvement over not having it. Adding its functionality to jack when zita-mu1 (along with other solutions) already exists is not an improvement, but a redundant increase in complexity. This is starting to sound like a systemd vs. traditional init argument. Not everyone wants multiple functions added to software when there's already a purpose-specific equivalent that works. John

On Wed, March 27, 2019 17:51, Fons Adriaensen wrote: Some success in compiling zita-mu1, it's a totally recommendable "master" switch/analyser/ for jack! Such tools do add value to the jack ecosystem in a non-linear way, it's creating freedom. Thanks Fons! Greetings Thomas

On Wed, Mar 27, 2019 at 5:54 PM Thomas Brand &lt;tom(a)trellis.ch&gt; wrote: Yes, that is the natural hacky solution to this problem. But it's not the best solution, the best solution would be if jack could provide default output ports to clients that requested them. Monitoring ports, like I do in jack_capture, is messy, doesn't update immediately, and doesn't always work. Thank you. :-)

On Wed, 27 Mar 2019 18:51:37 +0100 Felix Homann &lt;linuxaudio(a)showlabor.de&gt; wrote: ASIO is single client, so JACK is already an impressive improvement in functionality. IMO nowadays the most pragmatic solution nowadays is to run the distro PA for system audio, and JACK for your low latency audio needs. IIRC, the bridges are still proof of concept code, but seem to work. -- Joakim

On Tue, March 26, 2019 14:03, Kjetil Matheussen wrote: I've thought about the same a few months ago.. mainly just because it could help the initial startup, making pulse a backend like alsa and others. It has some merit iff the workflow must use pulse (be it for Bluetooth). My conclusion is that at least 50% of success depends on the standard configuration on a distro. So even if jack had a pulse backend, it won't magically solve all issues but would allow for potentially easier startup. Also IIUC this would work without DBus negotiation etc, one could start jack like jackd -dpulse (and everything just works). Greetings Thomas

On Tue, March 26, 2019 1:12 pm, liebrecht(a)grossmann-venter.com wrote: Just a note of mailing list tradition, replying on the top of the previous email text makes following the conversation of multiple people (and multiple mailing lists) very difficult. If you would edit your reply to include the author and specific comment to which you are replying it will be very helpful. I assume you are referring to this previous comment: That is a very bad idea for various reasons. If you think it is super useful then feel free to develop such a backend, or pay a contract developer to do it for you, but the people who originally developed jackd and the developers who currently maintain jackd as volunteers understand the architecture of jackd and pulseaudio, and pulseaudio is a high latency server which explicitly states that it will sometimes drop audio samples. That is in no way what you want in an audio production environment. The current jack-source and jack-sink modules are the appropriate way to handle this situation, jackd is the low latency server and controls the audio hardware, pulse becomes a client of jackd. That exists as jack-source and jack-sink modules for pulseaudio. I think specific examples of why you think it "doesn't really work" would be more useful, as that does not match my experience at all. To be fair, pulseaudio was much more difficult to deal with a few years ago, and as you have now pointed out that you are using Debian as your distribution, if you do not use an audio specific set of repositories you may experience problems because of the really slow update cadence of Debian (for example shipping a very old version of jackd). If Debian is as slow to update pulseaudio as they are to update jackd then I would not be surprised if you hit problems that have been fixed for years already in current versions. -- Chris Caudle

Am Dienstag, 26. März 2019 19:59 CET, "Chris Caudle" &lt;chris(a)chriscaudle.org&gt; schrieb: Jsut to be fair to Debian: in my humble experience it's trivial to get a rock-solid audio setup with jackd, pulseaudio and (lib)alsa applications. I running Debian testing (the rough equvalent of a non-LTS Ubuntu release) without audio problems since almost 20 years now. While I did use QJackCtl to manage jackd and jackd connections (never had a problem with it) I'm currently (appr. last 2 years) using Cadence for the same task. With Cadence (rewuires a dbus-enabled jackd) it's litterally _two_ moseclicks to enable a pulseaudio<->jackd bridge and another 2 clicks to so the same for libalsa<->jackd. I've used (and use) this settup on dedicated audio workstations with pro class interfaces (mostly RME), mobile recording laptops of all kinds (old hardware to highclass hardware to RasberryPi class boxes, using anything from Arturia AudioFuse to the cheapest usb "soundcards"). Never ever did I encounter problems with jackd. Let me take the opportunity to thank the jack developers for this great piece of software. Just my 0.2$, RalfD

Thanks John, that is something I will look into. good info. On 2019-03-26 09:48, John Rigg wrote:

Since pulseaudio is now uninstalled. What do you recommend should replace it in order that I can direct browser/system audio to the interface of my choice that will now most likely be jack as jack routes the interface. Is there any audio package like pulse that will play nice with jack and has e.g. panel applets etc. I dont want to willy nilly install and try everything as you must have an idea what is the best replacement. I will have to remap my entire audio keyboard too I guess to work with something else. It worked rather nicely with pulse. Also How do I connect my successfully configured bluetooth sound devices to jack ? that one I muiss from the manual. Pulse does that very well. Unfortunately the pulse jack-sync ro0ute in the manual doesnt work. I cannot reroute pulse to use jack, so I rather ask what the expert users use.

On Tue, Mar 26, 2019 at 10:19:49AM +0000, John Rigg wrote: There's a caveat here; I run a very minimalist system. I install Debian base system from the netinst.iso, turn off "Recommends" in apt, replace systemd with sysvinit, then install (or compile) required packages individually. No Gnome or KDE; I use cwm window manager. I recompile jack2 to get rid of dbus dependency. Apart from adding the user to audio group I don't have to do any special system configuration with this setup; it just works. John

Thanks John. Yes I have been using command line startup of jack as the preferred way for about a year now. It was always the only way that would work. Before I wiped the AV installation, mixbus did work, but UI had to completely remove qjackctl as they did not ant to work together properly.As soon as I start qjackctl mixbus wotn work. I let mixbus start jack, then the only reson to use qjackctl is just to monitor some output. So yur suggestion in my opinion is the correct one. The problem seems to persist, using qjackctl with mixbus, so the best is to remove it. Patchage + command line startup of jack seems a better way to create connections and jack at least runs and I already did that. The inputs of mixbus doesnt seem to get anything from the 1818VSL though and I will have to find a way to test them independently from mixbus. The big problem is to COMPLETELY remove pulseaudio, I dont mean uninstall, purge and make sure there is no panel apps running. I found the latter to have created an issue and jack started working after all that garbage was removed. Yes, I worked through the arch document. Thanks for the input. It is helpful.

On 2019-03-24 12:33, David Nielson wrote: Software is either deterministic and converge and it is non-deterministic and either have stable oscillations or divergence. It seems to me that jack is not deterministic as the manuals which I studied up as much as I could, does not seem to result =in a deterministic understanding of jack. I think the problem is that jack is sort of a stable oscillation, which makes it basically impossible to write a single manual for. The manuals are good but in my opinion does not describe jack in a deterministic way. Most of the trouble I get is not covered by the manual. Jack is MUCH needed software and we dont really have an alternative, so I remind myself not to beat up on it. If it was an alpha project, I would be happy to leave it till later, but it is apparently not. Since you found a solution it would be great if you could document it. but I understand it is a huge amount of work. If I can get a repeatable way to a) Run it b) add/remove any other sources and targets without compromise c) Have deterministic behavior I would sure write up my findings and help the project. The time it takes just to get jack working starts to equal that of studying the source code, see where the gremlins lie, fix it, and probably fork it if changes are resisted. I have no interest though to start another software development problem. I have enough of my own in other fields. The problem just is that Jack is unique and one of the most needed pieces of Linux software, which sadly isnt made available to the user, even educated-user in a digestible form. It is a real pity.

Jörn, thank you for your response. Both direct criticism and help is helpful. I dont mind either as long as it solves the problem. On 2019-03-26 09:34, Jörn Nettingsmeier wrote: Amazing. Why dont you write a manual ? It will sure help anyone else to get up and running. There must be a deterministic method in what you do, so it could really help to end all the negatives about jack. I am willing to learn as long as something is deterministic. I reinstall as I want to start from scratch. That is the only time I do it. To get a well determined starting point. If you want to buy a ticket to go abroad, you must first be sure where you are before you buy. My interface.g. 1818vsl, works flawlessly with mixbus and jack ( did once with debian stretch), but clearly jack has configuration problems from system to system as mixbus is set up the same, jack setup the same, alsa finds all the IO of 181vsl, but jack seemingly has trouble routing it. $ aplay -L null Discard all samples (playback) or generate zero samples (capture) default plugequal preamp duplex hdmi:CARD=HDMI,DEV=0 HDA ATI HDMI, HDMI 0 HDMI Audio Output hdmi:CARD=HDMI,DEV=1 HDA ATI HDMI, HDMI 1 HDMI Audio Output hdmi:CARD=HDMI,DEV=2 HDA ATI HDMI, HDMI 2 HDMI Audio Output hdmi:CARD=HDMI,DEV=3 HDA ATI HDMI, HDMI 3 HDMI Audio Output hdmi:CARD=HDMI,DEV=4 HDA ATI HDMI, HDMI 4 HDMI Audio Output dmix:CARD=HDMI,DEV=3 HDA ATI HDMI, HDMI 0 Direct sample mixing device dmix:CARD=HDMI,DEV=7 HDA ATI HDMI, HDMI 1 Direct sample mixing device dmix:CARD=HDMI,DEV=8 HDA ATI HDMI, HDMI 2 Direct sample mixing device dmix:CARD=HDMI,DEV=9 HDA ATI HDMI, HDMI 3 Direct sample mixing device dmix:CARD=HDMI,DEV=10 HDA ATI HDMI, HDMI 4 Direct sample mixing device dsnoop:CARD=HDMI,DEV=3 HDA ATI HDMI, HDMI 0 Direct sample snooping device dsnoop:CARD=HDMI,DEV=7 HDA ATI HDMI, HDMI 1 Direct sample snooping device dsnoop:CARD=HDMI,DEV=8 HDA ATI HDMI, HDMI 2 Direct sample snooping device dsnoop:CARD=HDMI,DEV=9 HDA ATI HDMI, HDMI 3 Direct sample snooping device dsnoop:CARD=HDMI,DEV=10 HDA ATI HDMI, HDMI 4 Direct sample snooping device hw:CARD=HDMI,DEV=3 HDA ATI HDMI, HDMI 0 Direct hardware device without any conversions hw:CARD=HDMI,DEV=7 HDA ATI HDMI, HDMI 1 Direct hardware device without any conversions hw:CARD=HDMI,DEV=8 HDA ATI HDMI, HDMI 2 Direct hardware device without any conversions hw:CARD=HDMI,DEV=9 HDA ATI HDMI, HDMI 3 Direct hardware device without any conversions hw:CARD=HDMI,DEV=10 HDA ATI HDMI, HDMI 4 Direct hardware device without any conversions plughw:CARD=HDMI,DEV=3 HDA ATI HDMI, HDMI 0 Hardware device with all software conversions plughw:CARD=HDMI,DEV=7 HDA ATI HDMI, HDMI 1 Hardware device with all software conversions plughw:CARD=HDMI,DEV=8 HDA ATI HDMI, HDMI 2 Hardware device with all software conversions plughw:CARD=HDMI,DEV=9 HDA ATI HDMI, HDMI 3 Hardware device with all software conversions plughw:CARD=HDMI,DEV=10 HDA ATI HDMI, HDMI 4 Hardware device with all software conversions sysdefault:CARD=Interface Default Audio Device sysdefault:CARD=VSL AudioBox 1818 VSL, USB Audio Default Audio Device front:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio Front speakers surround21:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio 2.1 Surround output to Front and Subwoofer speakers surround40:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio 4.0 Surround output to Front and Rear speakers surround41:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio IEC958 (S/PDIF) Digital Audio Output dmix:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio Direct sample mixing device dsnoop:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio Direct sample snooping device hw:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio Direct hardware device without any conversions plughw:CARD=VSL,DEV=0 AudioBox 1818 VSL, USB Audio Hardware device with all software conversions sysdefault:CARD=M1x1 Default Audio Device Yes I do that, naturally. It is found see posted earlier. $ amixer Simple mixer control 'Mic',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ? - ? - ? - ? Limits: Capture 0 - 255 Front Left: Capture 0 [0%] [-127.50dB] [on] Front Right: Capture 0 [0%] [-127.50dB] [on] Rear Left: Capture 0 [0%] [-127.50dB] [on] Rear Right: Capture 0 [0%] [-127.50dB] [on] Front Center: Capture 0 [0%] [-127.50dB] [on] Woofer: Capture 0 [0%] [-127.50dB] [on] Side Left: Capture 0 [0%] [-127.50dB] [on] Side Right: Capture 0 [0%] [-127.50dB] [on] Rear Center: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] ?: Capture 0 [0%] [-127.50dB] [on] Simple mixer control 'Mic',1 Capabilities: cvolume cvolume-joined cswitch cswitch-joined Capture channels: Mono Limits: Capture 0 - 255 Mono: Capture 255 [100%] [0.00dB] [on] Simple mixer control 'AudioBox 1818 VSL Audio 2.0 Output Playback',0 Capabilities: pswitch Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ? - ? - ? - ? Mono: Front Left: Playback [on] Front Right: Playback [on] Rear Left: Playback [on] Rear Right: Playback [on] Front Center: Playback [on] Woofer: Playback [on] Side Left: Playback [on] Side Right: Playback [on] Rear Center: Playback [on] ?: Playback [on] ?: Playback [on] ?: Playback [on] ?: Playback [on] ?: Playback [on] ?: Playback [on] ?: Playback [on] Simple mixer control 'AudioBox 1818 VSL Audio 2.0 Output Playback',1 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'AudioBox 1818 VSL Audio 2.0 Output Playback',2 Capabilities: volume Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ? - ? - ? - ? Capture channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ? - ? - ? - ? Limits: 0 - 255 Front Left: 255 [100%] Front Right: 255 [100%] Rear Left: 255 [100%] Rear Right: 255 [100%] Front Center: 255 [100%] Woofer: 255 [100%] Side Left: 255 [100%] Side Right: 255 [100%] Rear Center: 255 [100%] ?: 255 [100%] ?: 255 [100%] ?: 255 [100%] ?: 255 [100%] ?: 255 [100%] ?: 255 [100%] ?: 255 [100%] Simple mixer control 'AudioBox 1818 VSL Audio 2.0 Output Playback',3 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 255 Mono: 255 [100%] Simple mixer control 'AudioBox 1818 VSL Clock Selector Clock Sour',0 Capabilities: enum Items: 'AudioBox 1818 VSL Internal Clock' 'AudioBox 1818 VSL S/PDIF Clock' 'AudioBox 1818 VSL ADAT Clock' Item0: 'AudioBox 1818 VSL Internal Clock' Agreed, but it always seems to find everything looking at what alsa reports. So it seems like a routing problem to me. I only buy class compliant usb devices. Yes i do it with a custom startup string. Here I disagree. It is a huge part of the problem. If I start with my own string, things work to a large extent. If I use qjackctl the sound bricks never mind how I configure it. Really doesnt work in my opinion. They cannot all be wrong especially if they are in the upper 90s percentile right? If the response against something is so overwhelming negative, it doesnt help to stick head in sand. Wherever I look I find negatives about jack. E.g. I look for pulseaudio solutions w.r.t jack "https://freedompenguin.com/articles/how-to/pulseaudio-toilet-full-roses/" which places a positive spin on jack, but then see the comment by Elgar at the bottom. That is about the consensus the community reached about jack independently. I feel the same, but try to make it work against the stream. "https://freedompenguin.com/articles/how-to/pulseaudio-toilet-full-roses/" We cannot all be wrong coming to about the same conclusion. I want jack to work, but just arrives at the conclusion it cannot do what is required. No real ability to control sound levels is not very professional in my opinion. That absolutely make jack reliant on pulseaudio. Pulseaudio and jack doesnt really work together never mind how you try to divert pulse through sync. So jack must either follow pulseaudio or become a daemon for the few users with requirements satisfying it exactly. I keep trying to make it work, but perpetually end up seeing what the other users say about jack seems to be the end result I experience. So It is an observation based on what I read. The negative comments against jack is overwhelming. Whether it is justified is another matter. But if users do not have a clear instruction about what jack will and will not do false expectation can result. I mean, I just today found that there is almost no way to have a mixer for jack - this is a huge disappointment. That is basically tanking the usability for a lot of users. Jack without volume control is like airplane with throttle always at maximum. You would be right to remark that criticism is not helping in this case, but we both have different probably valid opinions.

On 2019-03-26 14:22, John Rigg wrote: To the 95% that complain's defense, they are just trying to use it for what it is advertised as and fail. I understand their frustration. I am glad, but then please make jack available for professional users only. else you drag us Joe Soaps in all the time to make your life miserable when they just state things as it is from our perspective. Thank you this it is helpful, I am connecting it now and will see if it works once it shows up in patchage. I just want this connected to my sound device output so that I at least have a software control over the master out as many devices use it and you need some way to just lower the volume on everything. This will do the trick it seems. I appreciate this, it is the first time you posted something constructive and it really helped me out. thanks. I rather think it is advertised to the wrong audience. More like trying to Ram a VCR casette into a tape deck and expecting the user to be happy with it. Not always. I say it as it is. Sometimes I am wrong and apologize some time I am right.... and then ruffle feathers it seems. Thats why I am here right? If you actually read my posts you will realize that that was exactly what I realized. The jack developers are good people I have no interest to fight, but jack is in my opinion not very well presented and if it is targeted only to the few people actually using it then state it so. Then we will all know to move on to something else. I am glad there are five or so people as you say that use it successfully. I was hoping to become number 6 so that the 95+ negative statistic could come down, but apparently not. I am just trying to make it work thats all.

On 3/26/19 5:28 AM, liebrecht(a)grossmann-venter.com wrote: That remark is bullshit and shows that you really need to change the way you're thinking about problem solving. Simplify the problem. First, look at aplay -L to see if hw:VSL,0 is alive and well. Now, start jack on the command line, starting with the paramters mixbux helpfully suggests: jackd -t 200 -p 2048 -R -T -d alsa -n 2 -r 48000 -p 128 -d hw:VSL,0 It should fail in the same way you described above. If not, there is something fishy in the way mixbus starts jackd. -n2 p128 looks like a pretty aggressive timing for a multichannel interface. Try -n3 for a start, and -p1024, then gradually lower the latency, but only if you really need it. -- Jörn Nettingsmeier Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net

On Fri, 22 Mar 2019, liebrecht(a)grossmann-venter.com wrote: ALSA has "2 levels": The low level stuff, "the driver", and high level stuff "the API for clients". If you have an USB interface then jackd uses the ALSA driver, iow "backend": jackd -dalsa ... Without Pulseaudio you can redirect ALSA clients to jackd via ~./asoundrc or system wide files: -- snip --- pcm.!default { type plug slave { pcm "rawjack" } } pcm.rawjack { type jack playback_ports { 0 system:playback_1 1 system:playback_2 } capture_ports { 0 system:capture_1 1 system:capture_2 } } pcm.jack { type plug slave { pcm "rawjack" } hint { description "JACK Audio Connection Kit" } } -- snap -- So jackd can "own" the card and ALSA-clients can use the ALSA-API. When Pulseaudio is installed there will be a similar redirection installed, systemwide. All ALSA-clients are redirected to Pulseaudio. If Pulseaudio outputs to jackd then all clients can output their sound. jack-client -> jackd -> audio interface pulseaudio-client -> Pulseaudio -> jackd -> audio interface ALSA-client -> Pulseaudio -> jackd -> audio interface You have all the benefits and you can record the sound of Youtube videos or SoundClout with Audacity if you choose the correct jackd-port. You can even have several jack_thru instances to have "fixpoints" where you can tap the signal. I run a jack_thru named "main" (1st arg) as central point where I can tap the signal. Here an example with a running Qtractor: http://marzen.de/tmp/jack_flow_simple.png This way I have ALWAYS that central point regardless if and how many audio applications are running. To maintain the connections of started applications I have jack-plumbing active with the following ruleset ~/.jack-plumbing As you can see in the last lines: Whenever I start ebumeter it gets automagically connection to "main" (a jack_thru instance) and processes every client's audio since every client will be redirected to "main". If you have more questions that might not be of interest for the whole mailing list you can email me directly. My other PC in the home studio has a more complicated setup since I use 2 jackd instances: one with a big latency for Qtractor sessions and one with a small latency for Guitarix, which sends its analog output to the first. -- snip -- (connect "main:output_1" "system:playback_1") (connect "main:output_2" "system:playback_2") (disconnect "system:capture_.*" "main:input_.*") (connect "alsa-jack\..*jackP\..*:out_000" "main:input_1") (connect "alsa-jack\..*jackP\..*:out_001" "main:input_2") (disconnect "alsa-jack\..*jackP\..*:out_.*" "system:playback_.*") (connect "Clementine:out_jackaudiosink-.*_1" "main:input_1") (connect "Clementine:out_jackaudiosink-.*_2" "main:input_2") (disconnect "Clementine:out_jackaudiosink-.*" "system:playback_.*") (connect "Qtractor:Master/out_1" "main:input_1") (connect "Qtractor:Master/out_2" "main:input_2") (disconnect "Qtractor:Master/out_.*" "system:playback_.*") (connect "ardour:Master/audio_out 1" "main:input_1") (connect "ardour:Master/audio_out 2" "main:input_2") (disconnect "ardour:Master/audio_out.*" "system:playback_.*") (connect "MPlayer.*:out_0" "main:input_1") (connect "MPlayer.*:out_1" "main:input_2") (disconnect "MPlayer.*:out_.*" "system:playback_.*") (connect "PortAudio:out_.*[13579]" "main:input_2") (connect "PortAudio:out_.*[02468]" "main:input_1") (disconnect "PortAudio:out_.*" "system:playback_.*") (connect "PulseAudio.*:front-left" "main:input_1") (connect "PulseAudio.*:front-right" "main:input_2") (disconnect "PulseAudio.*:.*" "system:playback_.*") (connect "netjack:capture_1" "main:input_1") (connect "netjack:capture_2" "main:input_2") (connect "main:output_1" "ebumeter:in.L") (connect "main:output_2" "ebumeter:in.R") -- snap --

On Tue, December 11, 2018 10:05 am, David Kastrup wrote: There are some interfaces which have an analog mixer on an output so that you can mix the input signal and the returned signal from the computer interface directly in the analog domain. The only latency on the input side is analog propagation delay, which is usually not worth discussing in an audio context. That style of interface can be really convenient for portable setups where you don't want to carry a mixer or monitor controller with you. -- Chris Caudle