5 ms·

I was just marveling at how well Wine+Linux works with my old music and audio hardware. A lot of my old gear hasn't had functional Windows drivers since XP...bu

I was just marveling at how well Wine+Linux works with my old music and audio hardware. A lot of my old gear hasn't had functional Windows drivers since XP...but, Linux picks it right up. And, a few days ago I thought, "What the heck, let's see if the sysex editor/librarian for this old beast will work in Wine?" And, it did! It saw that the driver wasn't the official driver from the manufacturer (since it was the ALSA driver) when starting and it warned about it, but it still worked, and still detected the device and loaded up all the patches and such. Historically for these abandoned devices, I'd just use MIDI for communicating with it; since MIDI hasn't changed in decades, it all continues to work just fine (in Windows and Linux). But, it's certainly convenient to just plugin the synth itself via USB and have it all Just Work. But, yeah, to speak to your point: There are mountains of old software (and hardware!) that won't work on Windows anymore, but will run fine on Linux with Wine. That's pretty amazing to me. I couldn't believe how smooth it all was; I remember spelunking docs for hours to figure out how to make things work. Now, I just run the installer (or just run "wine app.exe") and there it is. I'm sure there are exceptions, but damned if I'm not still impressed. I rarely consider any program important enough to reboot to use it, since I'm most comfortable and productive in Linux, and Wine becoming so good over the past few years makes it even less of an issue. I still keep a Windows partition on my laptop, Just In Case, but I haven't needed it in months.

samplatt 9y ago
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.

samplatt 9y ago

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.