3 ms·

Linux is not ideal for recording audio, but it has improved remarkably in recent years. It used to require a bunch of kernel patching to get low latency recordi

Linux is not ideal for recording audio, but it has improved remarkably in recent years. It used to require a bunch of kernel patching to get low latency recording (though once you jumped through those hoops, it was lower latency than most Windows environments), but now most of those patches have been mainlined, and you just have to add your user to the realtime group on your system to allow JACK to use realtime scheduling. I don't notice the latency, but I also haven't measured it, and I just do it as a hobby, so spending some of my time tinkering with quirky stuff is fine (though it's not really that quirky anymore...tons of stuff Just Works). If it were my job, I would probably consider a mac. It's not; my job is software, where Linux is the clear winner. But, I don't think it's nearly as clear as it used to be that Linux isn't suitable for pro audio work. I think a reasonable person might give it a try, whereas five (or ten, or twenty, which is when I first started poking at audio on Linux) years ago it would have been madness to try to do real audio work on Linux.

snvzz 9y ago
In my own experience, for desktop/workstation/audio, linux-rt (the -rt patchset) is the kernel to use, hands off. Nevermind the lower latency, it does feel way better to use. It's like using a different operating system, one that's actually a decent desktop OS.
- SwellJoe 9y ago
  I wouldn't think just the rt stuff would make a difference for normal desktop stuff since processes have to opt in to realtime scheduling (and the processes that don't can then be pushed aside to meet deadlines for the RT processes). But, maybe there are other scheduler changes present in the patch set. I just use whatever RT features are shipping with current Fedora, and it works well enough for me. I don't miss patching a kernel every couple of weeks as was required back in the bad old days of doing audio on Linux. (Though CCRMA made it easier with their package repository, so it hasn't really required a completely DIY process for many years.)
  - snvzz 9y ago
    >I wouldn't think just the rt stuff would make a difference for normal desktop stuff since processes have to opt in to realtime scheduling (and the processes that don't can then be pushed aside to meet deadlines for the RT processes). The same sort of opt-in as in mainline. SCHED_FIFO or SCHED_RR. Yes, it makes a difference even without opting in. By all means. Arch makes trying linux-rt very easy. Try rt-tests on Linux and on Linux-rt. See the examples at: https://wiki.archlinux.org/index.php/Realtime_kernel https://wiki.archlinux.org/index.php/Realtime_kernel I get spikes beyond a ms within minutes on mainline, on all my hardware. In practice, without even setting SCHED_FIFO or SCHED_RR, I can play sfc(snes) games on higan on linux-rt. This is not possible on mainline, not even with SCHED_FIFO, as even with higher audio buffer sizes, it cuts constantly. Same with audio work with jackd and low latency buffer sizes. >I just use whatever RT features are shipping with current Fedora, and it works well enough for me. No such luck for me, and I've even tried ck's patchset and such. It barely provides any improvement. Yet linux-rt is radically better. And, while unrelated, even the usual disk i/o stalls that plague Linux (on any hardware, using any common distro standard kernel) haven't happened at all to me on linux-rt. It's as if using an entirely different OS. It feels responsive. >I don't miss patching a kernel every couple of weeks as was required back in the bad old days of doing audio on Linux. (Though CCRMA made it easier with their package repository, so it hasn't really required a completely DIY process for many years.) Me neither, as AUR makes linux-rt very convenient.

snvzz 9y ago

In my own experience, for desktop/workstation/audio, linux-rt (the -rt patchset) is the kernel to use, hands off. Nevermind the lower latency, it does feel way better to use. It's like using a different operating system, one that's actually a decent desktop OS.

SwellJoe 9y ago
I wouldn't think just the rt stuff would make a difference for normal desktop stuff since processes have to opt in to realtime scheduling (and the processes that don't can then be pushed aside to meet deadlines for the RT processes). But, maybe there are other scheduler changes present in the patch set. I just use whatever RT features are shipping with current Fedora, and it works well enough for me. I don't miss patching a kernel every couple of weeks as was required back in the bad old days of doing audio on Linux. (Though CCRMA made it easier with their package repository, so it hasn't really required a completely DIY process for many years.)
- snvzz 9y ago
  >I wouldn't think just the rt stuff would make a difference for normal desktop stuff since processes have to opt in to realtime scheduling (and the processes that don't can then be pushed aside to meet deadlines for the RT processes). The same sort of opt-in as in mainline. SCHED_FIFO or SCHED_RR. Yes, it makes a difference even without opting in. By all means. Arch makes trying linux-rt very easy. Try rt-tests on Linux and on Linux-rt. See the examples at: https://wiki.archlinux.org/index.php/Realtime_kernel https://wiki.archlinux.org/index.php/Realtime_kernel I get spikes beyond a ms within minutes on mainline, on all my hardware. In practice, without even setting SCHED_FIFO or SCHED_RR, I can play sfc(snes) games on higan on linux-rt. This is not possible on mainline, not even with SCHED_FIFO, as even with higher audio buffer sizes, it cuts constantly. Same with audio work with jackd and low latency buffer sizes. >I just use whatever RT features are shipping with current Fedora, and it works well enough for me. No such luck for me, and I've even tried ck's patchset and such. It barely provides any improvement. Yet linux-rt is radically better. And, while unrelated, even the usual disk i/o stalls that plague Linux (on any hardware, using any common distro standard kernel) haven't happened at all to me on linux-rt. It's as if using an entirely different OS. It feels responsive. >I don't miss patching a kernel every couple of weeks as was required back in the bad old days of doing audio on Linux. (Though CCRMA made it easier with their package repository, so it hasn't really required a completely DIY process for many years.) Me neither, as AUR makes linux-rt very convenient.