I Tried Linux as My Main Dev Environment but Was Forced Back to Windows(nickjanetakis.com)
nickjanetakis.com
I Tried Linux as My Main Dev Environment but Was Forced Back to Windows
https://nickjanetakis.com/blog/i-tried-linux-as-my-main-dev-environment-but-was-forced-back-to-windows
56 comments
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.
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.
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.
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.
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.
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.
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
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
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).
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).
[deleted]
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.
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?
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 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/ to system:capture to see what's going on with respect to what jack sees as its input.
I don't know Jack, but it might be worth checking whether something like buggy automatic power management is suspending and resuming the relevant USB path during acquisition...
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.
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.
Is there any tool that you can point at your pulseaudio and it would walk the whole configuration, trying you which parts are likely to cause delays? (With suggestions)
I don't know. I do not typically use pulseaudio on my systems.
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.
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.
What are your views on PipeWire?
Possibly a good direction for consumer audio. Currently it lacks feedback (at the design level) for it to build into something useful for pro audio.
I tried Windows once as my main dev environment but was forced back to MacOS / Linux.
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.
Yeah, I gave a Surface Pro 4 with Windows 10 a go for like 9? months.
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)
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)
Thankfully you don't have to anymore. Steam Proton is so incredibly well-polished and supports a ton of Windows-native games, sometimes even with higher performance.
After a few minutes in the Group Policy Editor, most problems are solved permanently. Also, use the LTSC version, not the regular one.
Where do we get a spin of Windows that disables telemetry and makes us the only admin and not also Micrsoft without needing to edit local GPO?
Is it only the Chinese version?
Is it only the Chinese version?
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.
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'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.
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.
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.
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 tried Windows for 2 decades as my main dev environment, but was forced onto Linux.
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)
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)
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?
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?
>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.
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.
Could you try ffmpeg using aac instead of wave? I think it would involve adding only `-c:a aac` to the command.
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.
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.
>Could you try ffmpeg using aac instead of wave? I think it would involve adding only `-c:a aac` to the command.
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.
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.
Thanks for the replies. I really appreciate it. I'm assuming you're recording at least 2 minutes worth of audio in each of these tests?
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?
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?
>I'm assuming you're recording at least 2 minutes worth of audio in each of these tests?
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.
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.
It sounds clean here. Some ambient room hiss but that is unrelated to pops and cracks.
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 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.
>Scarlett side of the connection.
I touched both sides. Nothing.
>nvidia drivers
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...
I touched both sides. Nothing.
>nvidia drivers
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...
Thanks.
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.
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.
Late to the party here, but if touching the cable introduces noise no matter which software you run, maybe you have a ground loop problem or a really poorly shielded cable. You might try a different, decent quality cable. If that doesn't make a difference try connecting the cases of the Scarlett and the computer. It might be enough to set the Scarlett on the computer case.
Thanks, yes it happens in all environments. But this specific model (2i2) is notorious for having a poor USB port but I don't think all of them are afflicted with the issue.
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.
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.
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.
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.
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?
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?
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.
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.
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'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.
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.
>There is no lesson to be had here, I'm just sad.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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.).
I've had decent luck with a Steinberg UR44 (USB 2, IIRC) on linux.
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.
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.
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?
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?
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.
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.
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 ).