JackAudio

jackaudio@lists.linuxaudio.org

601 discussions

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.

6 years, 3 months

[Jack-Devel] How to tell if server running from API

by Tim

This may have been answered recently but I can't find it. Is there a way, via the Jack API or Jack server API, to ask if Jack is already running? I see there is a DBus command for that in jack_control, but jack_control crashes for me. Maybe my Python's fault? Thanks. Tim.

6 years, 3 months

[Jack-Devel] Remaining problems

by liebrecht＠grossmann-venter.com

To consolidate remaining problems CONFIRMED: Jack routes output to 1818vsl properly. So outputs work. I verified that sound can be sent to 1818vsl, therefore since I cannot create any signal in mixbus, I asume that mixbus will be able to send sound to the 1818vsl successfully as it is connected to the same working port on jack that setbfree sent sound to the 1818vsl. So that test of mine confirmed that jack does route correctly to 1818vsl So in my case we do not have to discuss the output routing to the interface. Jack seems to do that well. 1) I have to figure out why with jack started and inputs and outputs of 1818vsl connected to mixbus, no sound is received. Any suggestion how I can test the routing of inputs on the 181vsl to what jack routed ? Here is my patchage setup as already reported "http://grossmann-venter.com/issues/jack/patchage_status-01.png" The 18 inputs of the 1818vsl is clearly made available and connedcted to mixbus. I want to connect some of them to something else I can monitor independent from mixbus. Anyone has a suggestion? Ardour is not a good option, as mixbus is basically ardour with a skin. I need to add something else to one of the 18 routes and send signal from the 1818vsl and capture it with something. Please suggest what you are using to attach to ports to test for data. Thanks. 2) After (1) is solved etc, I need to get pulseaudio to work through jack, but I will discuss that later. Without pulseaudio I will not have any control of desktop sound as there is no volume control. E.g. audacity blasts at full volume through jack as it by error starts with full volume at startup..annoying and not pleasant.. So I will have to route all those through pulseaudio at a later date once I have mixbus working

6 years, 3 months

[Jack-Devel] jackd and volume control

by Holger Marzen

As far as I understood there are 3 opinions: 1.) Don't change anything 2.) Add some API-calls to control the volume of every port 3.) Add an API-call to control the volume of system:playback_* I'd say that 2.) will introduce too much complexity. This is what jack clients should do. But some time ago I proposed 3.) - Not every audio adapter has a software controllable hardware mixer, e.g. Focusrite Scarlett Solo, 2i2, 2i4. So alsamixer can't do the job. - No need to break clients' connection to system:playback_* and make connections to a volume control application like jack_mixer. That's really nasty when the application connects only at playback with changing port names, like Audacity. Then you need tools like jack-plumbing. I can live without that but that's what new users would appreciate, especially when there are some apps for the system tray/dock/whatever.

6 years, 3 months

[Jack-Devel] JACK1: Promiscuous mode doesn't work

by Alex Ivanov

Jack1 is run as following export JACK_PROMISCUOUS_SERVER= umask 0 jackd -dalsa JACK_PROMISCUOUS_SERVER is exported in environment. Now programs using jack don't show any errors, but there is no sound and jackd gives the following errors: мар 24 17:25:41 nixos jackd[15035]: jackd 0.125.0 мар 24 17:25:41 nixos jackd[15035]: Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others. мар 24 17:25:41 nixos jackd[15035]: jackd comes with ABSOLUTELY NO WARRANTY мар 24 17:25:41 nixos jackd[15035]: This is free software, and you are welcome to redistribute it мар 24 17:25:41 nixos jackd[15035]: under certain conditions; see the file COPYING for details мар 24 17:25:41 nixos jackd[15035]: JACK compiled with System V SHM support. мар 24 17:25:41 nixos jackd[15035]: loading driver .. мар 24 17:25:41 nixos jackd[15035]: creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit мар 24 17:25:41 nixos jackd[15035]: configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods мар 24 17:25:41 nixos jackd[15035]: ALSA: final selected sample format for capture: 32bit integer little-endian мар 24 17:25:41 nixos jackd[15035]: ALSA: use 2 periods for capture мар 24 17:25:41 nixos jackd[15035]: ALSA: final selected sample format for playback: 32bit integer little-endian мар 24 17:25:41 nixos jackd[15035]: ALSA: use 2 periods for playback мар 24 17:26:23 nixos jackd[15035]: subgraph starting at ADLplug timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0) мар 24 17:26:23 nixos jackd[15035]: pp: cannot clean up byte from graph wait fd - no data present мар 24 17:26:23 nixos jackd[15035]: **** alsa_pcm: xrun of at least 42199.144 msecs мар 24 17:26:23 nixos jackd[15035]: subgraph starting at ADLplug timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0) мар 24 17:26:23 nixos jackd[15035]: pp: cannot clean up byte from graph wait fd - no data present

6 years, 3 months

Re: [Jack-Devel] Jack Problems

by liebrecht＠grossmann-venter.com

Holger Marzen wrote: > I don't know if and how SPDIF-input appears in jackd and if it has to > be > routed IN the interface by some magic platform-dependent software. > I'd test the analog inputs first since they are connected to mixbus. > I sorted everything out, there is nothing that do not work pulseaudio/jack/bluetooth/all desktop sound and I can now route as i wish with patchage. Very nice. I can now focus on spdif. My keyboard is connected to the 1818 via a direct spdif link. I can use the easy midi connections but I prefer spdif. Always had great results with it live. I know that spdif is always routed to the channels 9&10 on 1818vsl. Somehow though mixbus sees absolutely no signal on 9&10 and I made sure that all alsa capture volume settings are maximum. All other inputs are successfully routed to mixbus and I get a signal. I am just a bit baffled about why it suddenly does not work. All spdif sync signals are handled between 1818vsl and the keyboard, so that cannot be the problem unless alsa for some reason need them, but I cannot see why. It must be the case as mixbus seemingly have timing ports. My understanding is that I do not need mtc/ltc for any spdif signal to at least appear in mixbus as a precondition, neither does 1818vsl seemingly forward the clock through usb. If it is alsa seemingly do not recognize it. all I can think of is that there is an alsa error muting channels 9&10. They are clearly connected correctly by jack. See attached graphic http://grossmann-venter.com/issues/jack/routes.png

6 years, 3 months

Re: [Jack-Devel] JACK is a great deterministic audio server

by Thomas Brand

On Tue, March 26, 2019 19:11, liebrecht(a)grossmann-venter.com wrote: > Not my place to comment on this, but it will be very nice. With all due respect, you have spilled so much BS to this list that it's time to stop now, thank you. If you intend to get help from this list, provide useful information in a dense way, learn how to reply to a list thread and free yourself from wrong expectations and things you've picked up elsewhere. Best regards Thomas

6 years, 3 months

[Jack-Devel] Remaining problems

by liebrecht＠grossmann-venter.com

Regarding my previous post with the same topic. To consolidate remaining problems CONFIRMED: I can confirm that mixbus output reaches the 1818vsl. I switched on the internal metronome in mixbus and it was routed by jack to the 1818vsl. The problem now is... how to verify that jack actually routes the inputs of the 1818vsl properly. See my previous post regarding this where I ask if someone regularly tests inputs and outputs with a test program. I need something independent that will capture from the system capture data as routed by jack from the system outputs which are routing the 1818vsl inputs..

6 years, 3 months

Re: [Jack-Devel] Uninstalled Pulseaudio Jack/jackd2 Jack Reinstalled still wont start.

by liebrecht＠grossmann-venter.com

On 2019-03-26 09:44, Jörn Nettingsmeier wrote: > On 3/26/19 5:28 AM, liebrecht(a)grossmann-venter.com wrote: >> After jack is installed, I try to start it through mixbus which is >> about the only application I found that can actually start jack. I >> used mixbus for about 6 months with jack on another distro. qjacktcl >> does nothing but parse irrelevance and promisses so I dont use it >> anymore. > > That remark is bullshit and shows that you really need to change the > way you're thinking about problem solving. > Sorry I disagree, qjcakctl has given me nothing but trouble and still does. It goes much better without it. All it arguably does is to formulate a jack string....which the user should do on command line anyway, and then output mystery log errors which are substandard to reading the logs yourself. I have never found any constructive use for it other than "feelgood". Mixbus worked great once I removed qjackctl on my previous system. qjackctl was single most annoying interference problem. > Simplify the problem. > First, look at aplay -L to see if hw:VSL,0 is alive and well. As I reported already in another post it is recognised. > 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. > As already reported, mixbus starts jack and jack runs IFF I dont start jack with qjackctl. Once qjackctl started jack, mixbus wont work. Mixbus starts jack with a string they disclose in the terminal output and it works. According to patchage as I reported in a previous post, mixxbus is connected to jack, but I get no signals from jack for the 1818vsl inputs in mixbus. > -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. I know I am just trying my documented default settings that worked perfectly before.

6 years, 3 months

Re: [Jack-Devel] Jack Problems

by Chris Caudle

On Fri, March 22, 2019 5:30 pm, liebrecht(a)grossmann-venter.com wrote: > Who are the experts that will be using Jack. If you search through the linux audio users mail list archives you will find plenty of posts with help for new users of jack. But as you say: > [doesn't] deserve any criticism other than usability for newcombers That is a valid complaint. The problem is somewhat difficult to solve, partly because the problem being solved is complicated, partly because on most linux distributions the default audio configuration is set for playing back audio, not producing audio. > By large 95% of users complain about jack. Do you know why those users are using jack? Ardour has supported using ALSA directly for quite a while, I believe Qtractor and LMMS do as well. Do those users need the ability to route between applications which jack provides? > If I can find some of these experts it will go a long way to figure out > how to actually use it in reality. But I found none on the 10s of > usergroups related to audio that I subscribe to. 10's of usergroups? Did you start with linux-audio-users? That is the primary location for audio on linux information. > about jack. I myself have been using Linux since 97 and did a lot of > unix and assembler programming before 97. I am actually a little surprised to find you have been using linux for so long, there was a lot of basic information missing in your original email which I would expect an experienced user to provide out of habit. For example, your first email did not specify - which operating system you were using (jackd runs on 3). - later you indicated linux; which distribution? Which version? - which version of jackd and pulseaudio? You provided partial information from qjackctl: qjackctl reports the following. Cannot connect to server socket err = No such file or directory ... But did not provide the full output of the "Messages" window of qjackctl. For example, when qjackctl attempts to start jackd you should see the full command line which is used: 19:22:09.341 JACK is starting... 19:22:09.341 /usr/bin/jackd -P70 -t2000 -dalsa -dhw:Lambda -r48000 -p1024 -n3 -zt -I376 -O376 The output of jackd follows from there. "Cannot connect to server" type messages are common as jackd initially starts. You can also copy that command line and start jackd from a terminal so that you can see the startup messages being printed in real time. > I am hesitant to use jack as it almost never work consistently, > pulseaudio at least works. That is probably part of the problem. The way that pulseaudio ensures it works is starting early and locking exclusive access of the primary ALSA device. Recent versions give up control gracefully, for many years now on Fedora I have had no problems at all starting jackd with either qjackctl or from the command line, the version of pulseaudio shipped by fedora gives up control of the audio device when jackd requests, and when I stop jackd then pulseaudio takes control again. Knowing which distribution you use may make it easier for someone to help. Ubuntu typically breaks audio production software frequently, but there are optional repositories to help with that. > it is difficult for me to > understand jack as it has no consistent specification I am not sure I understand this complaint. Do you have an example of something in the man page or help output you find inconsistent? The different backends available and the way that there are arguments to the main jack server and separate arguments for the backend driver can be confusing. Is that what you are referring to? > what is the exact mechanism by which pulse > interfere with jack The pulseaudio server will open an ALSA device for exclusive access, but jackd also needs to open the ALSA device for exclusive access. Obviously only one server at a time can have exclusive access to a particular driver. Most modern versions of pulseaudio that I am familiar with using on Fedora Linux do not have that problem, but as you gave no indication of which linux distribution, which pulseaudio version, or which jackd version you are using it is difficult to say more than "works for me." jack-audio-connection-kit-1.9.12-6.fc29.x86_64 pulseaudio-12.2-1.fc29.x86_64 qjackctl-0.5.5-2.fc29.x86_64 > As I understand it jack should be an either/or/add > switch for audio streams I do not understand exactly what you are trying to convey. I think of jackd more like a patch bay for routing audio within the OS. Is that just a different way of saying the same thing you wrote there? > I found that jack seemingly does not really do direct hardware access Of course not, it has been a principle of general purpose operating systems for well over five decades that user space programs do not directly access hardware, the operating system kernel mediates access to the hardware. > which further complicates things On the contrary it simplifies things. It would be wasteful and error prone if the jack project had to duplicate the work done in the linux kernel audio drivers. It also gives a clear boundary to check basic audio functionality using ALSA utilities (such as aplay and arecord) separately from the routing and patch bay functionality of jackd. > 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. ALSA has an API, jackd also has an API, but I don't get the impression that is what you mean. The method that jackd uses to communicate with ALSA devices is the same as every audio software which supports ALSA, including pulseaudio, audacity, Ardour, etc. I am not really sure what you mean there, perhaps copying the actual output from jackd when it has an error will allow someone to help you by pointing out the messages which indicate why jackd could not start. > 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 basically what jackd is. Having multiple audio interfaces complicates the situation, having multiple sound servers (e.g. jack and pulseaudio) complicates the situation. If you have a machine with only one audio interface and no other audio servers running just start jackd and it will work. Once your machine setup gets more complicated than that then any sound server will require you to make some configuration choices. One thing which may in the future prove useful to you is the Red Hat pipewire project. The aim of that project is to make a single server which combines the features of pulseaudio and jackd, and also provides similar features for video, running as the default media server for Fedora. That final working solution is still some time in the future, but sounds like it should be what you are looking for in terms of default working setup with only minimal configuration required. > That is maybe what is needed until jack becomes user friendly I am reminded of a quip about Unix operating systems: "Unix is user friendly, it is just very picky about who it makes friends with." > Isnt there at least some for of user debug frontend for jack that can > point to the errors Start jackd from the command line, copy and paste the output messages to an email so that someone can have hope of helping you. So far you have a lot of complaints but not much information. Regarding the question you asked of Holger: > How is that going to influence my abilty to use audio interfaces as now > alsa wont be able to access the usb ports directly when I follow the > link advice you included in your message. If I understand it right No, you misunderstood what the instructions were doing. They were essentially making sure pulseaudio did not start automatically, setting up jackd as the main audio server, launching pulse with the jack interface module as the audio interface instead of ALSA, and also secondarily setting up an ALSA pseudo-device which exposed a jack port as an ALSA device for software which attempts to use ALSA directly. I find that almost all current software versions support pulse, so the ALSA setup is not needed. Note that in my opinion if you need those instructions, your chosen linux distribution has not done a good job configuring the audio software provided in the distribution repositories. I don't want to be too repetitive, but in Fedora none of that is necessary, just start jackd and it works. You will probably need to load the jack modules in pulseaudio, but that may work by default now. I am not sure, I have had a modified pulse configuration file in my user directory for so long I am not positive of some of the current default behavior. -- Chris Caudle

6 years, 3 months

← Newer
1
...
18
19
20
21
22
23
24
...
61
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

JackAudio