
I Tried Linux as My Main Dev Environment but Was Forced Back to Windows - nickjj
https://nickjanetakis.com/blog/i-tried-linux-as-my-main-dev-environment-but-was-forced-back-to-windows
======
fundamental
Maintainer of a project in the linux audio space here. The simplified view is
that for pro-audio pulseaudio is the enemy. It is not built for low latency,
it is a complex beast to tune, it can be opaque to debug, and some defaults
are not ideal (e.g. resampling behavior). If you are having problems with xrun
like events then I would start by trying to reduce how much involvement
pulseaudio can have on the pipeline.

In many cases linux audio can just work, but when it doesn't the debugging
process can end up getting somewhat involved. There are a few places where you
might have some luck with more detailed debugging like the linuxmusicians
forum, the linux-audio-user mailing list, or one of several IRC channels on
freenode (e.g. #jack ).

~~~
nickjj
That's the interesting thing though. According to Jack I have no xruns with
512/2, but the pops remain (but only on Linux because using the same hardware,
same USB ports, etc. on Windows has no pops).

I'm just recording my voice in 1 line of the Scarlett, so 50-100ms of latency
is no problem.

You ever hear of a case where pops were coming in quite often but it wasn't
related to xruns reported by Jack?

Thanks for the heads up on #jack, I didn't even know they had an IRC channel,
but in theory I should be able to pull this off without Jack too since I'm not
doing anything fancy (such as redirecting sound through a DAW)? Still, pops
happened without Jack too.

~~~
fundamental
Having pops without jack indicates that either some other software layer is
choking (e.g. pulse if the audio is still routed through it) or a hardware
issue. You indicate that the hardware is without issue elsewhere, so that
leaves the linux ALSA driver/driver settings, pulse (if it's interfering),
jack, or the recording app. I do recall some mentions of a few of the Scarlett
devices having quirks in the past, though I haven't personally been all that
involved in those discussions.

If jack or the recording application (connected to jack) were causing the
issue then you should see an xrun reported from jack which makes me think that
there's the possibility that it's being unexpectedly routed around via pulse
(which can cause all sorts of shenanigans) or it's a know ALSA level driver
quirk with respect to the device. The latter is unlikely as you're indicating
that this is a USB device (IIRC the firewire ones were the more fussy ones).
Even if you're not striving for low latency I would recommend some of the
audio communities as they're likely to have stressed the same device a fair
bit and may have encountered similar issues.

~~~
nickjj
Thanks. Is there any chance the Windows driver has some special sauce to deal
with hardware defects that alsa / pulseaudio aren't aware of? Maybe some crazy
edge case defects (since it's not affecting everyone with a Scarlett).

I think I am still using pulse mainly because I installed qjackctl and
pulseaudio-module-jack, but my audio devices according to pavucontrol were
Jack, but it's still being routed through pulse right?

I Googled to the end of the world on this device with Linux but came up empty
handed. It was just a few success stories.

~~~
fundamental
Typically that approach setups up jack as the primary device user and pulse as
the secondary. Your setup involves a usb audio device in addition to what I
assume is some builtin audio device on your desktop/laptop. JACK's server only
takes full control over a single device, so it's possible that JACK took over
something other than your Scarlett leaving a different routing mechanism to
shuttle data from the Scarlett to it.

As that's a mouthfull, what may be happening is:

Dev A <-> JACK <-> Pulse <-> Dev B

If that's happening then you'd want to switch the setup to:

Dev B <-> JACK <-> Pulse <-> Dev A

or

    
    
      Dev A <-> JACK <--+--> Zita-ajbridge <-> Dev B
                        |
                        +--> Pulse
    

Per the windows driver, I have no idea and likely neither do ALSA devs since
the source is not available there. If the Scarlett driver is a standard usb-
audio device, then it likely should be exceptionally robust and very similar
across operating systems.

~~~
nickjj
You are correct in that I also have a built-in sound card that's on the
motherboard, but currently there's no microphone connected to it. I also had
my headphones connected directly to the Scarlett.

When Jack was wired up with that pulse module plugin, if I talked into my the
mic, pavucontrol showed the input bar jumping around. Does that mean it was
operating on the correct mic? When I used OBS' jack client, it also picked up
the Scarlett's mic once I wired it through qjackctl.

I know on Windows I was getting pops and cracks until I installed the Scarlett
driver and specifically set the buffer to 512. Any other value would produce
pops on Windows (even worse with 1024 which is weird).

~~~
fundamental
If you look at qjackctl's connection window then the system:playback and
system:capture ports should correspond to what jack is directly connected to.
If jack is connected directly to your device, then any pops due to xruns
should be recorded and displayed in qjackctl.

~~~
nickjj
Yeah it was set up so that the PulseAudio JACK Sink was set to the
system:playback_1 and 2, and then the PulseAudio JACK Source was set to
system:capture_1 and 2.

There were pops but no xruns recorded with Jack.

Then in the OBS case, when I used the specific JACK client (as a secondary
test), I wired the system:capture to whatever client came up with OBS. In
hindsight, maybe that was a mistake, and I should have instead wired up the
JACK sink's front-left/right instead of system capture?

~~~
fundamental
It looks like HN's reply limiter has kicked in preventing further replies, so
I'd recommend shifting discussion to one of the resources I've already
mentioned. Based upon your most recent comment it is still not clear if jack
is connected to the desired device or not. I'd recommend connecting a simple
waveform viewer e.g. [http://baudline.com/](http://baudline.com/) to
system:capture to see what's going on with respect to what jack sees as its
input.

------
kevinherron
I tried Windows once as my main dev environment but was forced back to MacOS /
Linux.

~~~
asark
It's weird that the version of Windows that finally added tools that _might_
make it possible, if not pleasant, for me to do real work on it without truly
doing all my work in a VM, also went so far into crazy-town that I don't even
use it for gaming anymore.

~~~
11sdmb8m
After a few minutes in the Group Policy Editor, most problems are solved
permanently. Also, use the LTSC version, not the regular one.

~~~
kiddico
Where can a regular end user get an LTSC version?

Last time I looked around the conversation quickly dissolved into piracy. Not
sure if I was just looking in the wrong places though.

~~~
11sdmb8m
You can't, it's for Enterprise users.

You can find a clean ISO and change the KMS server to a server that will
always activate your copy of Windows. That way you can be sure there's no
malware involved.

~~~
kiddico
Oh dear. I'm late to my own party.

I'll look into settings all that up. I wasn't aware you could even take over
that part of windows. Do you mean modify the iso before installing?

Most of the not-a-kid-poking-things part of my life has been linux oriented,
so I'm not really sure what things are open to modification in windows.

------
nullifidian
Try installing Ubuntu. I'm using 2i2 with a AT2030 through pulseaudio, and not
having any issues in Audacity right now. My Ubuntu version is 16.04 with
4.4.0-137 kernel. I remember having some crack/pop issues (you could literally
see absent points in Audacity) with earlier versions of the distro/kernels,
but I think they evaporated after upgrade/reinstall. So it's kinda
unreliable/flaky, depends on some kernel config perameter maybe, or config
file in the distro.

I forced mine to work in 44100 sampling rate due to an unrelated hardware
malfunction that causes loud pops during device initialization and sample rate
switching(observable in windows also). In /etc/pulse/daemon.conf

default-sample-rate = 44100

alternate-sample-rate = 44100

Don't know if it affects the recording pops/cracks. Probably not.

Another issue I had that evaporated with updates is that pulseaudio/audacity
recording used to work with ginormous latency, like a second or more, maybe
caused by the crack/pop issue itself forcing pulseaudio to increase buffer
size to absurd sizes or something.

Another bit of sound configuration I found in my "how to reinstall ubuntu
guide" I've written for myself:

in /etc/pulse/default.pa add the following before 'load-module module-default-
device-restore':

load-module module-remap-source source_name=input1 master=alsa_input.usb-
Focusrite_Scarlett_2i2_USB-00.analog-stereo master_channel_map=front-left
channel_map=front-left format=s32le rate=96000 remix=no

this line turns 2 scarlet's inputs interpreted as stereo by the os into a a
mono source (probably requires customization of the device name)

~~~
nickjj
Have you tried recording with ffmpeg (using pulse or even alsa), or even OBS
studio?

Those drop outs are exactly what I think is happening here, even though I
never looked at the waveform in Audacity, that's exactly what it sounds like.
If it happened mid-word, it was like that section of the word was removed from
the face of the Earth. The problem is I'm using a very new kernel (4.19) hmm.

I was using 44.1k too by the way (also tried 48k too) and set it exactly how
you did in daemon.conf.

Thanks, that is a handy line to have in case I can get all of this to work.
Sure beats mixing it back to mono in post-production for every recording.
Although isn't that resetting the rate back to 96000 when you want it to be
44100?

~~~
nullifidian
>Have you tried recording with ffmpeg

Just tried ffmpeg -f pulse -i default output.wav

No issues observed.

>Although isn't that resetting the rate back to 96000 when you want it to be
44100?

Yeah, I just noticed that too. I inherited 96000 since before I resorted to
using 44100, so... It just works, too lazy to change it.

As for alsa without pulse, I tried using ardour with jack year or two ago, and
no issues either.

arecord --device=default --format=S32_LE -r44100 -c2 -t raw | aplay -r44100
-c2 --format=S32_LE --device=default -

works too.

So it's either software, or something else in your system is affecting it. As
someone said in this thread, debugging such an issue could get very arcane.

------
otterpro
If audio recording is the only thing holding you back, then I'd recommend you
get a second PC dedicated for audio recording, running Windows or Mac, and use
your main PC for Linux. That way, you'll be happy user and maintain your
sanity, instead of complaining of the OS of your choice.

Majority of video streamers (ie Twitch streamers) uses 2 system setup, where
one PC is used for games and the second PC is dedicated for video recording in
order to reduce the load on the gaming PC. Similarly, for screencast, I'd
recommend Elgato CamLink or other Linux compatible HDMI capture device, so you
can do recording/capturing on the Windows machine, while working on your Linux
workstation.

As for me, I use all three major OS: Mac, Windows, and Linux (Debian). Each OS
have their strength and their weakness, so I try to use the right tool for the
job.

~~~
nickjj
Thanks for the reply.

I thought most gamers just streamed through OBS on their main machine, since
they are always tinkering with various OBS scenes in real time, etc..

It is audio recording holding me back but it's in the context of recording
programming tutorials where I would want to record my desktop inside of a
Linux environment as a screencast video.

Right now I just do things through WSL but it's not comparable to a native
Linux set up, and VMs are even worse (I tried the VM approach for over 5 years
and it sucks).

Would you mind going over the work flow for using one of those CamLinks? It's
the first time I've heard of that before but it seems like it might be an
interesting solution -- or at least something to look into as a last resort
option.

I'm not opposed to building a 2nd machine but how can something like this come
together to solve my problem?

Let's say I have 2 computers (1 running Windows and 1 running Linux) and I
have 2 monitors, and in non-recording mode I would want to leverage both
monitors in Linux. Would I need a third monitor to make this work? What does
the set up look like?

------
true_tuna
I switched from Mac to Linux. On my Lenovo X1 everything works out of the box
(audio is fine, Bluetooth and WiFi are fine, external displays etc). It’s not
all sunshine and roses but no deal-breakers in two years. I’m super impressed
by how far Linux has come.

------
Zyst
I wavered in and out of using Linux for years, OS X, and roughly speaking have
given up, and focus on Windows nowadays.

The main reason I stopped using Linux is that a lot of "small" stuff won't
just work, so then I go down a google quest, and fix it in anywhere between 5
minutes, and never. OS X mostly just works, Windows mostly just works.

There are a lot of compromises to privacy, or games, or worse development
environments, or worse performance for some hardware, or worse UX, or having
to track down byzantine errors. I mostly reached the conclusion that no matter
which OS you choose you are going to sacrifice something.

Right now, I like games, I want to be able to play effortlessly. The friction
between having to restart from OS X/Linux to windows is too much for me, I
like to open Dark Souls, play 15 minutes, die, rage quit, get some work done,
open Dark Souls again. That's a hard flow to get working in those operating
systems.

The future of Linux GPU VM dedicated pass through looks amazing, and my next
computer I intend to at least give a shot of getting that to work, but I
suspect that much like the author there will just be either a lot of tiny
issues, or one big issue that will end up making me go back to Windows full
time.

There is no lesson to be had here, I'm just sad.

~~~
nickjj
> That's a hard flow to get working in those operating systems.

That is my exact use case for not dual booting either. Sometimes you want to
do something without losing your entire context / environment from a reboot.

With recording it's even more tricky because a dual boot won't work since you
need to record the Linux environment and dual booting to break up the
recording and editing aspect is no way going to happen. That's where the GPU
pass through VM will come into play.

I will try the GPU pass through approach in a few months once this course is
done, assuming I can resolve the audio pops on Linux first since I would still
be recording in Linux no matter what approach I went with.

------
seiferteric
Don't know if it's related but I had pops and cracks in my audio when setting
up 5.1 surround sound in Linux over S/PDIF. I messed with all the stuff
mentioned including setting tsched=0 to no avail. The solution was to also set
my channels to 6 in alsamixer, even though it was already set to 6 in pulse
config. Another tip I read was to try disabling auto-mute in there, but that
didn't work for me.

------
falcolas
As someone who also uses a Scarlet 2i2 for recording audio in Linux (using
Audacity), I can't say that I've run into this problem. The Scarlet "just
works" for my usecase.

Of course, that's probably not a point in favor of Linux.

But, by the same token, I didn't precisely have a clear run of it in Windows
either. Biggest was the inconsistent ducking and mic level behavior as
everything tried to be the master of the audio system. The fact that some pre-
processing engines on Windows needed to include "restart engine regularly" was
also quite annoying.

~~~
nickjj
Are you recording your voice?

Did you plug it into a USB 2.0 or 3.0 port?

Are you using Jack or anything else?

Also in general, how finnicky is the red USB cable that connects your Scarlett
to your machine? Does it cause a ton of distortion / pops if you move it the
slightest?

I wasn't moving mine during recording of course but it just feels like the
whole thing is going to come disconnected, like it's hanging by a thread in
terms of audio signal.

~~~
falcolas
Voice only, yes (Highly amateur podcasting & tutorials)

3.0 USB port.

No additional software other than audacity.

No problems with the USB cable so far. It's a fairly standard cable though, so
getting a new one with better shielding shouldn't be too hard if that's a
concern.

~~~
nickjj
If you touch that cable, you don't hear any distortion coming through the
channel? If you have headphones on you'd hear it.

~~~
falcolas
I don't. Powered monitors, headphones, neither has a problem (even with the
48v mic power supply enabled).

------
slyrus
I wonder if the author has tried using a low-latency or RT kernel. Setting up
jack/pulseaudio/alsa isn't for the faint of heart but it's great when it all
works right.

~~~
nickjj
I didn't. I'm using the stock Debian kernel.

But in the kernel's defense, on a much worse computer in terms of specs, a
different USB mic had no pops with an older kernel (whatever ships with
xubuntu 16.04).

I also wasn't getting any xruns (according to Jack) at 512/2 which gave
something like 45ms of latency which isn't too low (but is totally fine for
talking into a mic, as opposed to drums, etc.).

------
squarefoot
Cracks and pops without buffer xruns might indicate some interrupt related
problem. A long time ago in another galaxy we had a problem causing a very
small but very regular data loss over local network communications using
protocols with no flow control. Of course we would expect some data loss since
we were using the wrong protocols for the job (though on a LAN it's not that
common), but its regularity made it worth investigating, and in the end I
discovered that an interrupt fired by the video card driver (IIRC) every x
time would clog the system for a tiny fraction of a fraction of second during
which the CPU would essentially be loaded at 100%. To get to the culprit I had
to match to the millisecond timestamps of system interrupts with those of data
losses. (I totally miss those days...)

Back to the point: had I played audio instead of transmitting data, I would
likely have heard those milliseconds of overloaded CPU in the form of pops and
cracks, so it may be worth checking if you have something loading the system
in bursts during which it cannot process audio safely.

~~~
nickjj
I was keeping htop open during recording and never noticed anything too crazy.
CPU was always about 30%-35% max on each of the 4 cores.

Would you still think it's an interrupt issue if there were no pops and cracks
on Windows using the same exact hardware in the same USB port?

~~~
squarefoot
Mine was just an idea. If you're experiencing an extremely short burst that
overloads the machine, it could be so short that it disappears when measuring
average cpu load which is what most tools do, but it could affect a near
realtime buffer write or read (from an audio or network card). If there is any
way to plot very short high spikes it should become recognizable, especially
if it obeys some regular pattern like a timed irq or the like. In our old
case, the hardware were Alpha workstations and Tru64 the OS, we nailed the
problem to a driver because installing both Linux and *BSD on the same
hardware the problem disappeared, so it can be a software issue.

------
120bits
For me Homebrew made me moved back to MacOS. I love having a linux like
system. I love having iTerm2 and flexibility to create bash scripts. Just few
features I use and enjoy everyday.

