JackAudio December 2018

jackaudio@lists.linuxaudio.org

20 participants
11 discussions

by Stefan Hellkvist

Hi list, (Sorry this question has already been discussed but the search function in the archive of the list does not work) Is anyone working on the problem of getting Jack up and running on MacOS again? I installed Jack with brew but I get these “could not handle external client request” errors which seems to be old problems from looking at search results and GitHub discussions - problems introduced when MacOS audio architecture was changed a while back. Is there any progress on these matters? Is someone working on it? I need Jack as it is a dependency to another library I would like to use but I realize that I might have to abandon MacOS as a platform in the process. Kindest regards, Stefan

5 years, 8 months

Re: [Jack-Devel] Jack and thunderbolt

by Ralf Mardorf

On Fri, 07 Dec 2018, liebrecht(a)grossmann-venter.com wrote: >On 2018-12-07 00:54, Ralf Mardorf wrote: >> However, hardware monitoring when using Class Compliant USB devices >> usually can't be done by the audio device's internal routing, a >> mixing console is needed for latency free monitoring, while cards >> that need an individual ALSA driver, such as the HDSPe AIO might be >> able to use the internal hardware routing (e.g. by hdspmixer). >Thanks all for the insightful responses. > >The last part of your answer is something I dont see often. >Do you have any point of departure where I can read up about which >devices can access the onboard DSP of audio interfaces such as those >you mention eg 1818vsl or other. It is the first time I see hints of >someone or programs able to access the onboard DSP for low latency >monitoring. Didnt see this ever mentioned but it is desperately >needed. After receiving your post I tried to find similar on the web, >but it is all very unclear what is possible and for which devices. Please reply to the mailing list and don't top-post. That is probably a misunderstanding. The Presonus and the Focusrite 2nd gen USB devices don't provide access to the device's internal routing when using it with a Linux machine. They are class compliant and don't need individual drivers. Sound devices that aren't class compliant need an individual driver and there might be access to the device's internal routing, as there is for some RME audio devices, when using the Linux's hdspmixer wich is similar to RME's totalmix, http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php. Monitoring without latency means, that you could route the input channels, directly to the output channels. IOW if you connect a microphone, you could listen to the unprocessed signal without latency, it's not the signal processed by your Linux machine.

5 years, 8 months

[Jack-Devel] Multiple latency across jack

by liebrecht＠grossmann-venter.com

Is it possible to have different signal sources handled differently by jack ? As an example, Mixbus uses jack directly and runs at 44100 buffer 128/2 I have other applications running under emulator that needs deeper buffers and longer latency is not an issue. These other applications all use pulseaudio and I dont know if pulseaudio causes the overruns and resultant rickety sound. I am really not familiar how pulseaudio works with jack. At the moment both pulseaudio and mixbus/jack outputs sound simultaneously to the same output device without problem At the moment I cannot find a way to increase the latency for all other sources than Mixbus. The other sources needs larger buffers not to work intermittently as it is now seemingly forced to use the same buffer size as mixbus which works flawless at 128. How should I go about it to run different sources at different buffer settings ? This is a bit above what I could find online in the Faq. Or should I find a way to send all these applications directly to jack for better buffer handling and somehow cut out pulseaudio ??

5 years, 11 months

Re: [Jack-Devel] AVB

by liebrecht＠grossmann-venter.com

Thank you Christoph. Stellar summary that can be of use to many and most importantly arguments concisely expressed. Exactly as I see it, but did not formulate it as well as you did. This post has been a great help to me and definitely settles the choice I will make thanks. Christoph Kuhr wrote: > 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: > > Correction to my mail: > I think I meant Ultramac not ultranet was the Sony invention > licensed > out, anyway, I quoted from memory so it might not be right, but I > gave > up on those protocols over AVB. > > ------------------------------------------------------------------------ > Jack-Devel mailing list > Jack-Devel(a)lists.jackaudio.org > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org > > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

5 years, 11 months

[Jack-Devel] Some observations re Jack and systemd

by Jörn Nettingsmeier

Hi everyone, after scratching my head for a long time to make systemd behave when running jack as a service, I thought I'd share my findings: Example service file: [Unit] Description=JACK Audio Connection Kit After=sound.target After=ntp.service After=time-sync.target Before=jackd.target Requires=jackd.target [Service] EnvironmentFile=-/your/config/file/containing/JACKD_OPTIONS LimitRTPRIO=85 LimitMEMLOCK=700000000 User=nettings Environment="DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket" ExecStartPre=/bin/sleep 10 ExecStart=/usr/bin/jackd $JACKD_OPTIONS RestartSec=5 Restart=on-failure [Install] WantedBy=multi-user.target So it's easy to start a service as a user, but that user's environment is not automatically pulled in. That means even though user nettings does have the necessary permissions in /etc/security/limits.conf, you still need to spell them out for systemd. Another thing to note is that at least on current raspbian, the time-sync.target is broken. Its promise is to only be triggered after ntp has worked its magic and the system time is monotonous. However, I've seen time jumps which combined with cheap USB hardware or the builtin Raspi sound will hang jack. Hence the ugly sleep. Final goodness: systemd might try to clean up after you. So when you have a jackd service started in your name, all is well, until you have logged in somehow and then closed the last shell, at which point the janitor from hell will happily clear /dev/shm and with it all your jack semaphores, leading to instant dumpster fire and silence. This magic can be avoided by setting RemoveIPC=no in /etc/systemd/logind.conf After clearing these hurdles, I've been quite happy with how systemd handles jack clients. The usecase here is a number of clients running in an embedded appliance, and systemd takes care of restoring them when I cause them to crash, which is good. Not that they crash, but it's good to have defense in depth. Figuring out how to order services is hard because you cannot assume a service is really ready when systemd has fired it off. So I've used a ExecStartPre script that blocks until a downstream jack port has appeared in those cases where I want to start clients in a particular order (matters most for the one job that needs to connect all the ports, so I let it wait on a test port for each client it needs to connect). Old-time SysV user here, and granted, systemd has given me many a WTF moment, but it does its job. Unfortunately, it does too many other jobs as well, but hey... -- 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

5 years, 12 months

Re: [Jack-Devel] Some observations re Jack and systemd

by Jörn Nettingsmeier

[replying on the list] Hi, On 12/22/18 5:15 PM, jack(a)microfx.de wrote: > Hey Jörn! > > Thanks a lot for sharing this! I will try this tomorrow since I tried to do something similar but always had audible “xruns” / popping (even with setting buffersize to 256). > > One question: -/your/config/file/containing/JACKD_OPTIONS <— what’s the content of this file? It's a file where I keep all changes that are specific to a particular Raspi box, so that my service files are generic. If you're only interested in your one studio machine, you might as well not use it and hardcode the necessary jack options below. Caveat: while you might think systemd can parse shell syntax, it really doesn't, its parser is very simple. So you have to make to with simple KEY=value pairs, even multiline variables will make it choke. -- 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

5 years, 12 months

[Jack-Devel] Can pulseaudio-module-jack "auto-start" jackd1?

by Jaime T

Hi all. I'm running jackd1 (0.125.0) on debian 9 (stretch) and its "auto-starting" facility works perfectly whenever I use jack-play. I now want to use pulseaudio-module-jack, but "pactl load-module module-jack-sink channels=2" fails (the command returns "Failure: Module initialization failed" and I see "jack_client_open() failed" in the journal). Is this a bug, or is it "intended/expected behaviour"? (I don't understand how jack-play starts jackd1. Is it dbus magic, or something else?) Many thanks, Jaime

6 years

[Jack-Devel] Jack_Capture not starting anymore after having Jackd running as systemd service

by jack＠microfx.de

Hey! Using the jack audio toolkit with my pisound DAC on a Raspberry Pi 3 which was a hassle - but I got it running with some hacks. Now for convenience I added jackd and jack_connect (to route input to output) as a service inside systemd - which works as expected. Before I could easily start jack_capture to record the input. But now it’s not starting anymore unfortunately. I get this error: jack_capture -c 5 -mb -tm -f flac 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 -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock >>> jack_client_open() failed, status = 0x11 I copied jack_capture also to /usr/locale/bin My systemd service files: jack-connect.service —> starts also jackd.service [Unit] Description=jack-connect Wants=jackd.service After=jackd.service [Service] Type=oneshot ExecStartPre=/bin/sleep 1s ExecStartPre=/usr/local/bin/jack_connect system:capture_2 system:playback_2 ExecStart=/usr/local/bin/jack_connect system:capture_1 system:playback_1 jackd.service [Unit] Description=jackd Unit [Service] ExecStart=/usr/local/bin/jackd -t 2000 -P 75 -d alsa -d hw:pisound -r 48000 -p 128 -n 2 -X seq -s ExecStop=/usr/bin/killall jackd Can anyone help me with this? Kind regards Jan

6 years

[Jack-Devel] Jack and thunderbolt

by liebrecht＠grossmann-venter.com

I really battle to find the optimum solution for ultra low latency monitoring using Linux. Since I am using Jack I have a few compatibility questions. 1) Is jack known to be able to work with thunderbolt 3 on Linux ? 2) Thunderbolt included, what is the lowest latency sound transport format that jack can work within your opinion on Linux e.g. thunderbolt / AES50 / Ultranet / Madi / etc

6 years

[Jack-Devel] Two Jack daemons running

by liebrecht＠grossmann-venter.com

This is probably more a MixBus question, but why doesnt MixBus use the Jack buffersize and sample rate I configure. The two are completely different. Since MixBus uses jack how can it have different buffersizes and sampling rates. I ask this question here because I noticed that there are two jack daemons running jackd and jackbus and that certainly doesnt look right. This is a clean installation of AVLinux and all I did was to install qjackctl

6 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

JackAudio December 2018