1. 5
  1.  

  2. 1

    Sadly, the only way to run jack on Linux with still bad but reasonable (e.g. 2ms) delay without xruns is to patch the kernel (run linux-rt).

    Even on SCHED_FIFO, mainline Linux will have peaks over 20ms of latency within minutes.

    1. 3

      Running the real time kernel is not the same as ‘patching the kernel’ given that the RT kernel is a simple apt install away:

      $ apt-cache search linux-image|grep 'PREEMPT_RT'
      linux-image-5.6.0-1-rt-686-pae-unsigned - Linux 5.6 for modern PCs, PREEMPT_RT
      linux-image-5.6.0-1-rt-686-pae - Linux 5.6 for modern PCs, PREEMPT_RT (signed)
      linux-image-4.19.0-9-rt-686-pae-unsigned - Linux 4.19 for modern PCs, PREEMPT_RT
      linux-image-4.19.0-9-rt-686-pae - Linux 4.19 for modern PCs, PREEMPT_RT (signed)
      

      By the way, we know by now you don’t like Linux.. What do you recommend to use instead of it for these applications, and can you point at third-party sources confirming both the problems caused by Linux as well as the solutions offered by the alternatives? I don’t know about others but I’m only interested in free software (as in freedom although I would not pass a free beer) since I consider the problems caused by proprietary systems to be larger than a few milliseconds of delay. Constantly complaining about the deficiencies of Linux (of which there are many, in this respect it matches the alternatives quite well) without pointing at true alternatives does not really help.

      1. 1

        given that the RT kernel is a simple apt install away

        Which means the distribution was kind enough to patch the kernel for you, and provided you with a package. Kudos to Debian for that, but it doesn’t change anything about disappointing behaviour of Linux mainline.

        By the way, we know by now you don’t like Linux.

        This is not accurate. I love Linux, use it as my main system everyday and have done so for a little over two decades.

        I do, however, not see it as the end-it-all of operating systems, nor do I see it as the best choice for every purpose.

        can you point at third-party sources confirming both the problems caused by Linux

        Contrary to what seems to be popular belief?, I do not collect papers against Linux. However, you can trivially verify the issue I described yourself, by the usage of cyclictest from rt-tests. Leave it running in the background with SCHED_FIFO (-S -p99), and see what happens. Unit is µs. For most purposes, the only value that matters is the Max one.

        I don’t know about others but I’m only interested in free software (as in freedom although I would not pass a free beer) since I consider the problems caused by proprietary systems to be larger than a few milliseconds of delay.

        A few milliseconds of delay will literally discard Linux as an option for a problem where the deadline is below Linux behaviour, such as a live musical performance at home, or worse, on stage.

        This is less of an issue but also annoying when doing VoIP, as everything adds up to the latency of the communications path between the participants themselves. A few milliseconds on each end is a lot of milliseconds.

        If non-free software is the only way, then using non-free software is the only option. Even RMS is ok with this, as a temporal measure until free software is ready for the job.

        Fortunately, for the described live music scenario, Linux-rt is good enough. As it also has been measured to only have a small effect in throughput, I find it annoying it isn’t mainlined and the default yet (although a lot of progress has been made on mainlining lately). Latency is a pet peeve of mine, and I fear even when merged, it will take a long time for distributions to do the right thing (PREEMPT_RT in the default kernel + separate kernel install-able as package for people who need the little extra throughput for servers)

        For a much more critical scenario (such as one where missing a deadline is the difference between life and death of human beings), then hard realtime i.e. the ability to guarantee response time below a deadline is required.

        The only such operating system kernel I am aware of that provides a complete enough proof of Worse Case Execution Time (WCET) is the seL4 microkernel, which fortunately falls under Open Source (GPLv2).

        1. 3

          OK, thanks, I’ll have a somewhat deeper look at seL4 to see whether it holds up to the somewhat lofty promises I’ve seen about the system.

          By the way, Linux is perfectly usable for audio purposes, I’ve been using it for just that for, well, decades for applications ranging from simple media server through VoIP and videoconferencing to DAW and DJ-ing (at school parties, nothing ‘professional’). That is where my comment on those few milliseconds comes from, personal experience. It might not be the first choice to build an engine control unit, airbag controller or ABS unit but it works just fine for the purpose which this article is about: a midi spy. That is why I reacted here, seeing yet another Linux-dissing post where no such dissing is warranted.

          I still do wonder why something like seL4 doesn’t take off if it offers a solution to all these ‘problems’ (between quotes because the jury is still out on the validity of many of those problems) with Linux. Is it just a lack of exposure?

          1. 1

            I’ll have a somewhat deeper look at seL4

            It’s certainly a good time, with this whitepaper being freshly published.

            By the way, Linux is perfectly usable for audio purposes

            In my own experience, running a range of audio tasks including simple pass-audio-from-input-through jack pipelines and midi input into software synth into analog output, Linux mainline sucks, but linux-rt is very workable, as long as the hardware is somewhat overspec’d.