[Jack-Devel] advice on xruns

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] advice on xruns

liebrecht

Anyone have an in depth treatise on xruns and how to minimize them. By
that I dont mean just adjusting the buffer size, I mean really getting
into the gears of why xruns happen and how to potentially minimize them.

Reason I ask is that I use jack on a live music basis amd it is crucial
for me to get no more than 2.9ms latency.
I can hear and feel every latency above above that.

I am lucky with mixbus and jack on Linux to get 2.9ms with the
occasional xrun every 2 minutes, but I want to see if I cannot eliminate
them.

Any advice or point to very relevant reference material will be
appreciated.

Thanks

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Hermann Meyer

Am 28.07.19 um 04:05 schrieb [hidden email]:

>
> Anyone have an in depth treatise on xruns and how to minimize them. By
> that I dont mean just adjusting the buffer size, I mean really getting
> into the gears of why xruns happen and how to potentially minimize them.
>
> Reason I ask is that I use jack on a live music basis amd it is
> crucial for me to get no more than 2.9ms latency.
> I can hear and feel every latency above above that.
>
> I am lucky with mixbus and jack on Linux to get 2.9ms with the
> occasional xrun every 2 minutes, but I want to see if I cannot
> eliminate them.
>
> Any advice or point to very relevant reference material will be
> appreciated.
>
> Thanks
>

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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Holger Marzen
In reply to this post by liebrecht
On Sat, 27 Jul 2019, [hidden email] wrote:

>
> Anyone have an in depth treatise on xruns and how to minimize them. By that I
> dont mean just adjusting the buffer size, I mean really getting into the gears
> of why xruns happen and how to potentially minimize them.
>
> Reason I ask is that I use jack on a live music basis amd it is crucial for me
> to get no more than 2.9ms latency.
> I can hear and feel every latency above above that.
>
> I am lucky with mixbus and jack on Linux to get 2.9ms with the occasional xrun
> every 2 minutes, but I want to see if I cannot eliminate them.
>
> Any advice or point to very relevant reference material will be appreciated.

Besides the fact that some USB ports on my notebook computer allow
buffer sizes down to 24 without xruns (when just playing music via
Firefox -> Pulseaudio-> jackd) and others only allow bigger sizes I
could eliminate occational xruns by:

- use 48000 Hz, not 44100 to get 1 ms-chunks with appropriate bufsizes
- use multiples of 48 for the bufsize
- blacklist modules for wifi, camera, bluetooth, onboard-audio
- switch off kernel parms that were introduced mainly for multi client
  data centers after some flaws in intel cpus were discovered


/etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="nohz=off threadirqs noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off quiet splash"

/etc/modprobe.d/blacklist-audiotuning.conf:
blacklist bluetooth
blacklist btrtl
blacklist btintel
blacklist btbcm
blacklist btusb
blacklist uvcvideo
blacklist iwlwifi
blacklist snd_hda_intel
blacklist snd_hda_core
blacklist snd_hda_codec
blacklist snd_hda_codec_realtek
blacklist snd_hda_codec_hdmi

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
In reply to this post by Hermann Meyer
On Sun, 28 Jul 2019 06:00:32 +0200, Hermann Meyer wrote:

>Am 28.07.19 um 04:05 schrieb [hidden email]:  
>> Anyone have an in depth treatise on xruns and how to minimize them.
>> By that I dont mean just adjusting the buffer size, I mean really
>> getting into the gears of why xruns happen and how to potentially
>> minimize them.
>>
>> Reason I ask is that I use jack on a live music basis amd it is
>> crucial for me to get no more than 2.9ms latency.  
>
>What I found over the years is, there is no general rule for how to
>optimize your system. It depend deeply on your hardware.  

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
In reply to this post by Holger Marzen
On Sun, 28 Jul 2019 08:40:07 +0200 (CEST), Holger Marzen wrote:
>"nohz=off threadirqs noibrs noibpb nopti
>nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable
>no_stf_barrier mds=off mitigations=off quiet splash"

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.html.

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Holger Marzen
On Sun, 28 Jul 2019, Ralf Mardorf wrote:

> On Sun, 28 Jul 2019 08:40:07 +0200 (CEST), Holger Marzen wrote:
> >"nohz=off threadirqs noibrs noibpb nopti
> >nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable
> >no_stf_barrier mds=off mitigations=off quiet splash"
>
> 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.html.

Can I disable it on the kernel command line if it's compiled in the kernel?

> Why do you disable nohz?

Got an error message in syslog, googled a bit, disabled it without
deeper knowledge.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
On Sun, 2019-07-28 at 10:32 +0200, Holger Marzen wrote:

> On Sun, 28 Jul 2019, Ralf Mardorf wrote:
>
> > On Sun, 28 Jul 2019 08:40:07 +0200 (CEST), Holger Marzen wrote:
> > > "nohz=off threadirqs noibrs noibpb nopti
> > > nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable
> > > no_stf_barrier mds=off mitigations=off quiet splash"
> >
> > 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.html.
>
> Can I disable it on the kernel command line if it's compiled in the kernel?

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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Holger Marzen
On Sun, 28 Jul 2019, Ralf Mardorf wrote:

> On Sun, 2019-07-28 at 10:32 +0200, Holger Marzen wrote:
> > On Sun, 28 Jul 2019, Ralf Mardorf wrote:
> >
> > > On Sun, 28 Jul 2019 08:40:07 +0200 (CEST), Holger Marzen wrote:
> > > > "nohz=off threadirqs noibrs noibpb nopti
> > > > nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable
> > > > no_stf_barrier mds=off mitigations=off quiet splash"
> > >
> > > 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.html.
> >
> > Can I disable it on the kernel command line if it's compiled in the kernel?
>
> 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:

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.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
On Sun, 2019-07-28 at 11:19 +0200, Holger Marzen 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.

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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Holger Marzen
On Sun, 28 Jul 2019, Ralf Mardorf wrote:

> On Sun, 2019-07-28 at 11:19 +0200, Holger Marzen 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.
>
> 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?
That's what happened. Of course this is no scientific examination.

> What kernel are you using?

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.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
On Sun, 28 Jul 2019 11:59:02 +0200 (CEST), Holger Marzen wrote:
>> You could use ½ of the frames, 12 instead of 24, just by disabling
>> audit, too?  
>
>That's what happened. Of course this is no scientific examination.
>
>> What kernel are you using?  
>
>linux-image-4.16.12-rt5-avl1

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/002037.html).
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/002043.html)."
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

liebrecht
In reply to this post by Ralf Mardorf
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



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Robin Gareus
On 7/28/19 1:26 PM, [hidden email] wrote:
> 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 !

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.

> 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.

Maybe, or maybe not, or perhaps even make things worse. -- I recommend
to make a backup or document the current state that works first.

> Please let me know to which log xruns are logged, as I want to make sure
> I catch even inaudible ones if they exist.

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).

> Latency free monitoring at last it seems and realtime playback sound.

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
In reply to this post by liebrecht
On Sun, 2019-07-28 at 07:26 -0400, [hidden email] wrote:
> I havent even implemented all the changes that was suggested here

Hi,

what have you already done?

> Please let me know to which log xruns are logged

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

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

liebrecht
On 2019-07-28 08:15, Ralf Mardorf wrote:
> On Sun, 2019-07-28 at 07:26 -0400, [hidden email]
> wrote:
> what have you already done?
>

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 !

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Robin Gareus
On 7/28/19 5:08 PM, [hidden email] wrote:

> On 2019-07-28 08:15, Ralf Mardorf wrote:
>> On Sun, 2019-07-28 at 07:26 -0400, [hidden email] wrote:
>> what have you already done?
>>
>
> 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!

I'm actually surprised that Mixbus + jack started without jack rt
permissions.


> Is it preferable to set every process involved e.g. / USB system / alsa
> / mixbus at high priority.

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

liebrecht
In reply to this post by Robin Gareus
On 2019-07-28 08:03, Robin Gareus wrote:
> On 7/28/19 1:26 PM, [hidden email] wrote:
>> Thanks to all who participated. (Ralf Holger, Hermann)

> 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).
>
>> Latency free monitoring at last it seems and realtime playback sound.
>
> 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.
>


Absolutely correct Robin, not latency free, just sensory and audibly
indistinguisable from latency free (that is why I included  "it seems"
with latency free in my statement..
I could have used better grammar.

I get 2-10 xruns in the brackets, when I just start up, probably while
starting jack etc.
After Mixbus is started and up, it stays at that value for hours as far
as I tested which is supernice.

There are no more clicks every minute or so. All gone.

I just wish I could work at 48000Hz. 1818VSL refuses to do it even
though it can do 96000. It is a stupid process of using windows
configurator software to set it to 48khz, but after I plug it into linux
all I get is 44100. Maybe I dont understand alsa correctly, because a
48kHZ jackd string doesnt work at 48kHz.

That will enable me to increase the buffer for the same latency and is
the quality I want to work at.



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Robin Gareus
On 7/28/19 5:26 PM, [hidden email] wrote:
>
> I get 2-10 xruns in the brackets, when I just start up, probably while
> starting jack etc.
> After Mixbus is started and up, it stays at that value for hours as far
> as I tested which is supernice

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 just wish I could work at 48000Hz.

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?

> Maybe I dont understand alsa correctly, because a 48kHZ jackd string
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

liebrecht
On 2019-07-28 11:41, Robin Gareus wrote:

> On 7/28/19 5:26 PM, [hidden email] wrote:
>> I just wish I could work at 48000Hz.
>
> 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?
>
>> Maybe I dont understand alsa correctly, because a 48kHZ jackd string
> 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

In my case I dont get a sample rate only bguffer size.


~$ jack_bufsize
128
~$

Although 1818vsl works great now I am stuck withy 44100. I am moving
completely to Motu in future and drop the presonus path. I am half way
in the process of moving over actually. I tried whatever I could but
44100 it is with 181vsl.
Interesting comment you made. Idid however tr4y all the factory resets.
No go. stays 44100.





















_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: advice on xruns

Ralf Mardorf
On Sun, 28 Jul 2019 12:07:52 -0400, wrote:
>Although 1818vsl works great now I am stuck withy 44100.

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12