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 08:40:07 +0200 (CEST), Holger Marzen wrote: With those spectre mitigations turned off, it still might be of value to disable audit, see https://lists.archlinux.org/pipermail/arch-general/2018-September/045580.ht…. Why do you disable nohz? -- 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, 2019-07-28 at 10:32 +0200, Holger Marzen wrote: I don't know what exactly the kernel parameter 'audit=0' does, perhaps it does the job. I also don't know if disabling the spectre mitigations for newer kernels, provides a faster path when disabling audit, let alone that I'm not sure that even on an old machine without meltdown and spectre mitigations, but an old kernel with CONFIG_AUDIT disabled, has got noticeable impact on audio performance. I just build my old kernels with disabling it by the kernel config. FWIW those using snaps should consider to keep audit enabled: Old: https://lists.ubuntu.com/archives/snapcraft/2017-January/002219.html Nowadays: "Since version 2.36, snapd enabled AppArmor support for Arch Linux. In order to use it, you have to enable AppArmor in your system, see AppArmor#Installation. Note: If AppArmor isn't enabled in your system then all snaps will run in devel mode which mean they will have same, unrestricted access to your system as apps installed from Arch Linux repositories." - https://wiki.archlinux.org/index.php/Snap#Installation

On Sun, 2019-07-28 at 11:19 +0200, Holger Marzen wrote: So in the meantime you already found the kernel-parameter and the detailed information by the kernel docs, that I didn't know :). You could use ½ of the frames, 12 instead of 24, just by disabling audit, too? What kernel are you using? I should consider to test disabling spectre mitigations and audit by kernel parameters, too. Until now I didn't make much tests, for example just: [rocketmouse@archlinux ~]$ uname -rm 4.19.59-rt24-0-securityink x86_64 [rocketmouse@archlinux ~]$ grep CONFIG_AUDIT= /usr/lib/modules/$(uname -r)/build/.config CONFIG_AUDIT=y [rocketmouse@archlinux ~]$ cat /sys/devices/system/cpu/vulnerabilities/* Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled Mitigation: Clear CPU buffers; SMT disabled Mitigation: PTI Mitigation: Speculative Store Bypass disabled via prctl and seccomp Mitigation: __user pointer sanitization Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling [rocketmouse@archlinux ~]$ grep LABEL\ Securityink /boot/syslinux/syslinux.cfg -A4 LABEL Securityink MENU LABEL Arch Linux Rt ^Securityink LINUX ../vmlinuz-linux-rt-securityink APPEND root=LABEL=s3.archlinux ro INITRD ../intel-ucode.img,../initramfs-linux-rt-securityink.img -- LABEL Securityink_no_micro MENU LABEL Arch Linux Rt Securityink no micro LINUX ../vmlinuz-linux-rt-securityink APPEND root=LABEL=s3.archlinux ro INITRD ../initramfs-linux-rt-securityink.img -- LABEL Securityink_nopti MENU LABEL Arch Linux Rt Securityink nopt^i LINUX ../vmlinuz-linux-rt-securityink APPEND root=LABEL=s3.archlinux ro nopti INITRD ../intel-ucode.img,../initramfs-linux-rt-securityink.img [rocketmouse@archlinux ~]$ hwinfo --cpu | grep Model | sort -u Model: 6.60.3 "Intel(R) Celeron(R) CPU G1840 @ 2.80GHz" -- 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 11:59:02 +0200 (CEST), Holger Marzen wrote: Thank you Holger :), I dropped a note at https://aur.archlinux.org/pkgbase/linux-rt/#comment-702130 [1]. Regards, Ralf [1] "Ralf_Mardorf commented on 2019-07-28 10:16 There's a thread at the Jack-Devel mailing list, that is interesting regarding Spectre mitigations and CONFIG_AUDIT, [see advice on xruns] (http://lists.jackaudio.org/pipermail/jack-devel-jackaudio.org/2019-July/002…). The subscriber is able to reduce frames/period from 24 to 12, [take a look at this posting] (http://lists.jackaudio.org/pipermail/jack-devel-jackaudio.org/2019-July/002…

On 7/28/19 1:26 PM, liebrecht(a)grossmann-venter.com wrote: Yay! Do you happen to know which of the change(s) did the trick? Depending on your system hardware it may only have been one. Maybe, or maybe not, or perhaps even make things worse. -- I recommend to make a backup or document the current state that works first. In Mixbus 5.X the x-run count is the number in the brackets after the DSP load. It is displayed top-right in the status-bar (right-click on the status bar to enable the display if it is hidden; shift+click to reset the count). It's not latency free; just low latency 2 * 64 / 44.1kHz = 2.9ms ~ about 1m of sound in air (similar distance of a guitar on lap to ear). There is likely some additional systemic latency, but still it's more than good enough for most. Cheers! 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."

Am Montag, 29. Juli 2019 08:46 CEST, Holger Marzen <holger(a)marzen.de> schrieb: Most likely a case of Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity." They probably use mass storage mode to provide their custom drivers (which are needed for performance under Windows). Cheers, RalfD

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.

On Mon, 29 Jul 2019 08:35:54 +0200 (CEST), Holger Marzen wrote: Since alsamixer provides to chose between two slave "ADAT" and "SPDIF" clock sources and the "internal" master clock source for the PreSonus AudioBox 1818VSL, the OP might need to ensure that either the internal clock is used or if an external clock is master, that the master does provide the desired clock signal. OT: On Mon, 29 Jul 2019 09:14:13 +0200 (CEST), Holger Marzen wrote: I once registered with Moog, to get an in-app purchase for free as in beer, but never got it. Some companies simply provide a link to a free sample library after registration. However, a few companies provide very excellent software, such as reverbs that are not just another crappy Linux, Apple or Windows reverb. If a user wants to get the reverb, there is no choice, they don't sell it, they only give it away if you register. I don't have a big problem with registration. I fear that in the future we can't buy what we need anymore, we might need to rent it, that is a way bigger problem to me.

On 2019-07-28 08:15, Ralf Mardorf wrote: I always used the realtime checkbox on cadence and was always suspicious of it. I went and read up on it and did. dpkg-reconfigure -p high jackd Didnt expect it to make a difference but it did! mixbus configured to run on 23/24 of the cores. I changed a minimum of priorities the old way, but I am sure it made no difference. I cant wait to implement the kernel options and do the priorities right. Another question, if you all dont mind. The process train is 1818vsl / USB system / alsa / mixbus. I added the following wildcard processes to and.priorities just out of common sense. I made it up based on what was already in the file. * * .*mixbus* * -10 -10 -10 * * .*alsa* * -10 -10 -10 * * .*mixbus* * -10 -10 -10 * * .*pulse* * -1 -1 -1 * * .*jack* * -10 -10 -10 This and the dpkg command was all I did so far Question: Is it preferable to set every process involved e.g. / USB system / alsa / mixbus at high priority. I mean it is easy to do it, but I just ask what your opinion is, as I think the entire chain needs to be at high priority to eliminate possible buffer problems when the buffer is that small. I can now use 128 sample buffer with confidence as it is also working rocksolid at 64. Really great !