Am 28.07.19 um 04:05 schrieb liebrecht(a)grossmann-venter.com: What I found over the years is, there is no general rule for how to optimize your system. It depend deeply on your hardware. I could say what I need to do with my current machine, beside the usual tweaks. First I use a rt-kernel, then I add the following kernel parameters:  threadirqs intel_pstate=disable processor.max_cstate=1 intel_idle.max_cstate=0 idle=poll only with them I'm able to run smooth at low latency. This is with a Quad Core model: Intel Core i5-7400 CPU. Additional, when I need full power,  I increase the priority for my sound-card thread, therefor I run as root: chrt -f -p 95 $(ps -eLo pid,cmd | grep -i snd_hda] |sed q|  cut -d' ' -f3) were snd_hda is m sound-card. All this wasn't needed with my previous PC. regards hermann

On Sun, 28 Jul 2019 06:00:32 +0200, Hermann Meyer wrote: Hi, I agree on that. On one machine I had to unbind USB ports and to care about which USB ports and PCI slots I used and on another machine it doesn't matter what USB port or PCI/e slots I'm using. It could help using a PS/2 keyboard instead of an USB keyboard. It could help to get rid of all unneeded services. Keep in mind that the policies of some Linux distros force to autostart everything packages provide, that can be autostarted. Btw. you didn't mention the operating system you are using. It could help to not share IRQs. It could help to use CPU frequency scaling performance governour or at least a fixed frequency. Ensure that the best available timer is used. Use a real-time patched kernel, or at least boot a non-patched kernel with threadirqs. Use the rtirq script to handle priorities. I wouldn't boot with nopti and similar security related options, or tweak hardware latency by the BIOS or care about swappiness or disable watchdog etc., but you might need to disable hyper-threading or to remove irqbalance. Learn to take higher latency! 2.9 ms latency is ridiculous low. For example, stay closer to the monitors to reduce the latency that is caused by the speed of sound. Don't use digital stomp boxes in your audio chain, they usually have a latency of around 5 ms. Usually a round-trip latency of 5 ms or even 10 ms is no problem at all. Problems are usually caused by latency chains. IOW if you are using a digital effect chain, than assume around + 5 ms latency caused by each effect. However, you did not mention what you already did, what hardware you are using, if you are using audio and/or MIDI. Note, MIDI jitter could be a PITA, too. Regards, Ralf -- pacman -Q linux{,-rt{-cornflower,-pussytoes,,-securityink}}|cut -d\ -f2 5.2.3.arch1-1 5.2_rt1-0 5.0.21_rt16-1 5.0.19_rt11-1 4.19.59_rt24-0

On Sun, 28 Jul 2019, Ralf Mardorf wrote: Can I disable it on the kernel command line if it's compiled in the kernel? Got an error message in syslog, googled a bit, disabled it without deeper knowledge.

On Sun, 28 Jul 2019, Ralf Mardorf wrote: With audit=0 I can use a buffer size of 12 at 48000 Hz and 2 buffers to Play a mixcloud song with Firefox -> Pulseaudio -> jackd and get no xruns. Of course that is no real life scenario since a DAW and its plugins demand a much bigger buffer sizem depending on te number of tracks and plugins.

On Sun, 28 Jul 2019, Ralf Mardorf wrote: That's what happened. Of course this is no scientific examination. linux-image-4.16.12-rt5-avl1 on a notebook computer with an Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz and a MOTU Ultralite AVB interface. Since it's class compliant there shouldn't be any difference to other class compliant interfaces. I bought the Ultralite AVB because it has enough outputs for several different mixes and a mixer with equalizer that can be controlled with a web browser interactively or with curl and a JSON api. Important: The latest 333 firmwares are buggy and cause a channel hop. I made a bug report and the issue was known. I hope it will be fixed in the next firmware revision. At the moment firmware 1.3.2+520 ist the way to go for Linuxers.

Thanks to all who participated. (Ralf Holger, Hermann) Huge success! I havent even implemented all the changes that was suggested here, but I now run mixbus at 64 samples @ 44100Hz with 1.5ms latency. Awesome beyond belief ! No xruns I could find for an hour now pushing it hard, and mixbus little red indicator stays gray, I now have no sporadic pops and there is NO audible latency. I also run a couple of plugins in mixbus, no trouble at all. I still have a lot to read up to implement the remainder of what you suggested which should improve things further. Please let me know to which log xruns are logged, as I want to make sure I catch even inaudible ones if they exist. Latency free monitoring at last it seems and realtime playback sound. Thanks

On Sun, 2019-07-28 at 07:26 -0400, liebrecht(a)grossmann-venter.com wrote: Hi, what have you already done? You could run jackd from command line, with or without redirecting stdout and stderr to a log file jackd -dalsa -dhw:HDSPMx579bcc -r44100 -p256 -n2 > /tmp/jack.log 2>&1 or launch jackd{,bus} using QjackCtl. QjackCtl has got a message button, click it, select the status tab and expand 'XRUN count since last server startup'. Regards, Ralf

On 7/28/19 5:08 PM, liebrecht(a)grossmann-venter.com wrote: I'm actually surprised that Mixbus + jack started without jack rt permissions. Definitely not. Only the audio *treads* of the process should be elevated. The processes themselves (GUI etc) should be lower priority in order to not interfere with audio i/o. The USB IRQ (kernel with threadirq) of the audio-device should be elevated. On debian based systems install the "rtirq-init" package. JACK's process callback (jackd -P config option) should have a slightly lower priority than the IRQ. ciao, robin

On 7/28/19 5:26 PM, liebrecht(a)grossmann-venter.com wrote: That is indeed awesome. And yes, while loading sessions, Mixbus can skip a few cycles, until caches are warmed up, etc. Also keep in mind that some operations are inherently not realtime safe. e.g. adding/removing jack-ports (e.g. add/remove tracks in Mixbus). Changing connections or adding/removing plugins may also cause additional DSP spikes. But those are edge-cases. It's not something one does while recording or when mixing live with low-latency. I use the VSL1818 at 48kHz exclusively. I still have a 8+ year old original firmware (and I have to force USB3 ports to USB2 compat). I heard that some people have issues once the device as at least once connected to a Mac or Window box. Maybe a factory reset can help? doesnt work at 48kHz. That's jackd's fault. Jack's ALSA backend always silently falls back the "closest available" samplerate. -- IMHO it should rather fail instead, but it doesn't. You can check with the `jack_bufsize` commmandline tool. That prints the actual current buffesize and samplerate. HTH, robin

On Sun, 28 Jul 2019 12:07:52 -0400, wrote: I once tested it, before I bought a Focusrite Scarlett 18i20 2nd Gen. On Linux a 1818vsl works at 48KHz. IIRC I only connected it to a Linux machine and an iPad, both just worked class compliant, no vendor driver or vendor software involved. However, I experienced strange issues when using it with the iPad, at least one issues other iPad users didn't experience, so I bought the Scarlett instead. On my old Linux machine I could use the Focusrite with lower latency, than the Presonus. I couldn't compare them on my new machine. -- pacman -Q linux{,-rt{-cornflower,-pussytoes,,-securityink}}|cut -d\ -f2 5.2.3.arch1-1 5.2_rt1-0 5.0.21_rt16-1 5.0.19_rt11-1 4.19.59_rt24-0

In a "PreSonus AudioBox 1818VSL" thread from Dec 2016 on LAU, I mentioned that "ALSA mixer allows to set up the clock, available are "ADAT", "SPDIF" or "internal". I chose "internal" and sync the ADA8000 by wc."

On Sun, 28 Jul 2019, Ralf Mardorf wrote: Note that Focusrite support wrote me that the 3rd gen interfaces are shipped in "Mass Storage Device" (MSD) mode initially. I guess they want to make more customers registering themselves and their Focusrite devices. More data, more good. It's not clear to me if you need a Windows or Mac computer to switch them to Class Compliant mode and if this setting is permanently. It reminds me of that ugly "zeroconf" stuff with wifi sticks decades ago. It seems they turned from "we don't support Linux officially" to "we don't give a shit".

On Mon, 29 Jul 2019, Ralf Mattes wrote: I don't think so. Those drivers would be outdated soon. I think they provide fancy "downloaders/installers" that seduces the customers to register their devices althought that's not needed (and hardly any Windows user needs the 6478th EQ or compressor). It's probably a marketing department's "brilliant" idea. No-one needs installers for Windows systems. The operating system provides everything. It's always about getting data and control users. But I think this is no jack topic but more an ALSA topic.

It looks to me like it is and ALSA problem and for the record when I refer to jack problems it might be alsa problems. The alsa UG is dead so unfortunately I have no other option but to ask here. After I had to reboot, it now takes me about 3/4 hour to get jack and all my sound running. I always succeed but it is tedious and largely non-repeatable. It used to be easy just simply starting it with Cadence. I have no idea what went out o0f whacki and really dont know where to start looking. When Jack works right, the following string on CLI starts jack error free. /usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:VSL -r44100 -p512 -n8 However now I get the following: ========================================================= $ lsusb Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 05e3:0719 Genesys Logic, Inc. SATA adapter Bus 001 Device 010: ID 1d57:0001 Xenta Bus 001 Device 009: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 008: ID 0bda:8153 Realtek Semiconductor Corp. Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 006: ID 0763:0150 Midiman M-Audio Uno Bus 001 Device 015: ID 194f:0103 PreSonus Audio Electronics, Inc. AudioBox 1818 VSL Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Which shows my 1818vsl Then trying to start Jack ------------------------- $ /usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:VSL -r44100 -p512 -n8 jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2016 Grame. Copyright 2016-2018 Filipe Coelho. 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 80 self-connect-mode is "Don't restrict self connect requests" control open "hw:VSL" (No such device) control open "hw:VSL" (No such device) creating alsa driver ... hw:VSL|hw:VSL|512|8|44100|0|0|nomon|swmeter|-|32bit control open "hw:VSL" (No such device) ALSA lib pcm_hw.c:1713:(_snd_pcm_hw_open) Invalid value for card ALSA lib pcm_hw.c:1713:(_snd_pcm_hw_open) Invalid value for card ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode control open "hw:VSL" (No such device) control open "hw:VSL" (No such device) Cannot initialize driver JackServer::Open failed with -1 Failed to open server Which says invalid value for card. Pulseaudio usually gets it to run after a while by continuously cycling the 1818vsl o0n and off for about 5 mins. Continuously cycling the following error output as it seemingly fiddles with Alsa and usb. Therefore I do $ pulseaudio & [1] 24813 ~$ E: [pulseaudio] module-alsa-card.c: Failed to find a working profile. E: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="2" name="usb-M-Audio_USB_Uno_MIDI_Interface-00" card_name="alsa_card.usb-M-Audio_USB_Uno_MIDI_Interface-00" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed. This error then cycles continuously for 10 minutes (switching 1818vsl status light from blue to red and back) my and sometimes alsa get sorted out and Pulse loads the 1818VSL (without Jack) Jaxck always starts after pulseaudio found the 1818vsl. =============================================================================== If pulseaudio didnt get it to run and it failed hard, the following procedure then usually gets it going. (strangely I first have to allow the 10minute pulseaudio usb/alsa disco to complete before the following will work. What worked the last time I ad to reboot is: ============================================== Once system is fully up, cycle power on 1818vsl Replug 1818vsl usb plug Wait for status light to go blue. (successfully connected to system) Start pulsaudio from cli pulseaudio & WHILE pulseaudio was started from cli and continuously clicking 1818vsl and cycling light from red to blue, after about 15 such pulseaudio cycles execute; /usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:VSL -r44100 -p512 -n8 Then jack usually starts, keep trying this string until by happenchance jack does start Pulseaudio will now connect and remove X on speaker. Go to cadence, make sure pulseaudio sync and start pulseaudio is enabled. Do a Force Restart. Now make sure the Syncs are shown in pulseauedio and that pulseaudio is not directly connected to 1818vsl as is sometimes the case. ================================================= So anyone have an idea why I suddenly have these problems. Seems to be alsa, but getting ANY answer from alsa usergroup- is moot. Alsa seems to be totally dead... Probably the dreaded pulseaudio that killed them off, sad really.