I Tried Linux as My Main Dev Environment but Was Forced Back to Windows
nickjanetakis.com
nickjanetakis.com
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 ).
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.
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.
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.
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
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).
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?
It is possible to disable the power management at several levels. The "powertop" utility is a convenient way to play with the top-level device/driver tunables. And the /sys/bus/usb filesystem has a power/autosuspend setting for individual devices.
I do have tools which are built to check source code for low latency compatible C/C++, but it sounds like you want something to inspect a running pulse audio daemon.
Some things I remember that drove me crazy:
- high DPI support was terrible
- typed "git status" into a Linux subsystem terminal and it took so long to finish I gave up
- there were ads in my Start menu (WTF)
Is it only the Chinese version?
Last time I looked around the conversation quickly dissolved into piracy. Not sure if I was just looking in the wrong places though.
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.
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.
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)
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?
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.
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.
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?
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.
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.
This pretty perfectly sums up how I feel after two decades of obsessing over the concept of a "good" OS. There is and will never be any such thing as an OS with a good UX + ecosystem that hits all three major use cases: development, productivity, and fun. Maybe I'm being pessimistic or maybe my standard are too high, but coming to grips with this conclusion has brought me some measure of peace.
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.
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.
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.
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.).
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.
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?