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
Dev A <-> JACK <--+--> Zita-ajbridge <-> Dev B
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 -
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.
I'm curious now. Did you ever notice any type of pops and cracks during normal system usage? Not even recording. Just going to Youtube or any page that happens to interface with your sound card. pavucontrol was notoriously bad for triggering it.
It sounds like you have a very clean connection.
ffmpeg -f pulse -i default -c:a aac -strict -2 output2.m4a
ffmpeg -f alsa -i default -c:a aac -strict -2 output2.m4a
no issues. alsa one through pulse too of course. -strict -2 is because distro's ffmpeg is old.
>Did you ever notice any type of pops and cracks during normal system usage? Not even recording.
If I remember correctly, yes. When I had crack/pop issue playing youtube videos or music I would occasionally hear this. But again, it fixed itself.
My general advice is to not use Debian unstable, and if you want a stable working enviroment avoid rolling release distros generally. When I tried living with Debian unstable 10+ years ago someting would constantly break on a apt-get upgrade. Not sure how it is now.
Although in your case it really sounds like the only thing you did was set 44100 and are using Ubuntu instead of Debian.
I mainly went for unstable to get more up to date packages, and didn't want to mess around with adding a billion PPAs with Ubuntu or compile from source for everything, but maybe I will give Ubuntu a shot the next time around.
I did install apt-listbugs and yeah it was scary. I didn't notice anything specifically audio related but seeing multiple critical / severe bugs like "may cause machine to lock" isn't what you want to see heh.
By the way, how sturdy is your Scarlett's USB connection in the back? Do you hear distortion and cracks if you touch it with headphones on? You don't need to wiggle it hard. Just basically touching it with the lightest amount of force possible within reason.
Also, does your motherboard happen to have an ALC892 based sound card as its built in sound device?
Occasionally I record hours of audio with Audacity without an issue, and don't hear any cracks pops, when I listen to it, and I certainly would have noticed absent words. So I'm pretty sure the issue is either not present or extremely rare.
You can hear for yourself http://s000.tinyupload.com/?file_id=08701491608992765221 Sorry, it requires amplification, and I clean in the background.
>Do you hear distortion and cracks if you touch it with headphones on?
Since I don't hear anything wrong with audio, I assume it's pretty sturdy. But I'm pretty sure your issues are not caused by the connection. Digital stuff either works or not.
Around the time it fixed itself I bought a new power supply. But I don't remember if it affected anything. I higly doubt it. What I remember distinctly is how I was amazed at the lack of latency/delay in Audacity after an upgrade to 16.04 from 14.04.
>Ubuntu or compile from source for everything
You can just try installing a different distro onto a spare drive to test if the issue goes away.
As for compiling everything from source -- how many super fresh dependencies do you really need for development 5? 10? IMHO it's reasonably tolerable with manually built libraries in a custom prefix. And programming languages have their own package managers pip, cargo etc.
I do notice a crazy amount of pops and cracks if I touch that cable by the way. That's only why I asked. It's mainly around touching it near the Scarlett side of the connection.
Super fresh dependencies would mainly be for things like nvidia drivers, i3, compton, ffmpeg, obs, maybe pulseaudio / alsa-utils, vim, xterm, maim, kdenlive (for editing videos until I get a GPU pass through working so I can use Camtasia), gimp, pass, vlc, tmux, weechat, ranger, sxiv, dunst, kvm/qemu/virt-manager. That's 20ish and that's only things I managed to discover after using Linux for about 3 days.
I touched both sides. Nothing.
for nvidia drivers I use official nvidia debs for that. There is a cuda.list in my sources.list.d with
deb http://developer.download.nvidia.com/compute/cuda/repos/ubun... /
inside. It has the latest versions. There is an instruction somewhere on nvidia.com on how to get the keys for that.
As for the other things on your list, you really need to ask yourself if you really need the latest version. I remember my younger linux newbie self also desiring the lastest thing as soon as possible, but now I apply effort only if there is a specific feature I need, or something is not right with the easiliy available version.
For example both vim and xterm are very very old and don't change fundamentally from year to year. Same for weechat, pulseaudio, alsa-utils. I can understand the need for a fresh ffmpeg or a video player - I have a custom built newish ffmpeg and an mpv player, for reasons of better h265 encoding support and better HDR video support in mpv in the recent versions, but for most of the stuff one can live without the latest version. And some of the packages are simply buggy on the freshest point release - RHEL has older software for a reason.
Ubuntu 18.04 is only a year old in terms of software versions presently. It's not THAT outdated.
I'm kinda stuck with 16.04 because I have a rather involved encrypted zfs root mirror setup, that requires a manual installation of the os (with chroot and all) and I have no desire to touch this stuff again until 0.8.xxx zfs release is included in an LTS release. But it's pretty livable still. Sometimes yes, system packages are SO old that it would require me to build literally tens of dependencies manually to build something fresh from source. (So I don't do it) But that happens only if I want something very new and involved. Sometimes you can transplant debs from newer ubuntu releases painlessly, but that takes some experience...
Vim is still actively developed btw. The latest version has added a bunch of new things that are very useful.
I guess I just didn't want to get into a loop of having to read every changelog in detail for every package I install, then compile from source for all of these packages (or use the default distro's version if it's ok). That just seems like a lot of extra work. Manually hunting around and installing dependencies isn't fun at all, and third party PPAs aren't necessarily going to be around for everything.
I'm also used to the Windows world where you would typically download the latest stable release of a program. Of course on a Linux server, I'm always reaching for Debian stable or Ubuntu LTS but that's a different story.
First things first. I need to test Ubuntu 18.04 with the Scarlett and see how it goes.
I was using the cable that comes with it, but I could try a spare. Good idea on touching the cases too. Right now they are apart. I didn't even think about it being related to that.
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?