4 ms·

I'm getting a new laptop soon to start tinkering a bit more with my keyboard and a synth, and I'm considering a Macbook for the first time in my life based on a

I'm getting a new laptop soon to start tinkering a bit more with my keyboard and a synth, and I'm considering a Macbook for the first time in my life based on a recent HN article regarding latency. Have you found that a linux machine has noticable latency when playing/recording music and applying filters?

SwellJoe 9y ago
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.
squarefoot 9y ago
If you get high latency on a Linux machine when doing audio stuff you probably have hardware problems or software is misconfigured. Years ago I moved everything I had under XP (Reaper+plugins) to a Wine directory, reinstalling those plugins that didn't like to be moved, and never looked back. I'm using the kxstudio repositories software (RT kernel, Wine etc). http://kxstudio.linuxaudio.org/ http://kxstudio.linuxaudio.org/ Latency is very low, even on old PCs such as Core Duo ones, and compatibility is very high. The only problem I encountered with Reaper under Wine is that it needs a lot of time to buffer a very big audio track when it's being added to a project. Say I record my band on our portable recorder then I drag and drop the big sample (2-3 hours stereo 44.1khz x16bit stereo uncompressed .wav) on a Reaper track, it starts eating all PC's memory to buffer it hanging the machine for a a good minute. Once the track is added, the memory gets released and it works perfectly though, so it's not technically a bug and I have no idea if it depends on Wine or Reaper. A few months ago I also started to use the native Linux Reaper port which is fantastic and lately got a lot more stable, but all my attempts to have Windows plugins working in parallel with it through Wine failed although they say it is possible, so although there are some interesting plugins out there, they're not remotely comparable to what is available for Windows (but that would be the case for every other native application): using Wine is still the best option if you are not just strictly recording and need external plugins. I also explored the possibility to have musical software working on a Windows VM with disconforting results so far: computing power is there, but latency is a nightmare. As of today, to me Wine still offers the best options if one needs both low latency and compatibility.

SwellJoe 9y ago

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.

squarefoot 9y ago

If you get high latency on a Linux machine when doing audio stuff you probably have hardware problems or software is misconfigured. Years ago I moved everything I had under XP (Reaper+plugins) to a Wine directory, reinstalling those plugins that didn't like to be moved, and never looked back. I'm using the kxstudio repositories software (RT kernel, Wine etc). http://kxstudio.linuxaudio.org/ http://kxstudio.linuxaudio.org/ Latency is very low, even on old PCs such as Core Duo ones, and compatibility is very high. The only problem I encountered with Reaper under Wine is that it needs a lot of time to buffer a very big audio track when it's being added to a project. Say I record my band on our portable recorder then I drag and drop the big sample (2-3 hours stereo 44.1khz x16bit stereo uncompressed .wav) on a Reaper track, it starts eating all PC's memory to buffer it hanging the machine for a a good minute. Once the track is added, the memory gets released and it works perfectly though, so it's not technically a bug and I have no idea if it depends on Wine or Reaper. A few months ago I also started to use the native Linux Reaper port which is fantastic and lately got a lot more stable, but all my attempts to have Windows plugins working in parallel with it through Wine failed although they say it is possible, so although there are some interesting plugins out there, they're not remotely comparable to what is available for Windows (but that would be the case for every other native application): using Wine is still the best option if you are not just strictly recording and need external plugins. I also explored the possibility to have musical software working on a Windows VM with disconforting results so far: computing power is there, but latency is a nightmare. As of today, to me Wine still offers the best options if one needs both low latency and compatibility.