PC build 1

It's high time I assemble a desktop computer.

At a high level, I want to bisect the machine into two: a Linux side for most of my work and a Windows side for the occasional game¹⁾. Ideally, each would be installed on its own SSD, with a much larger disk shared between the two²⁾. I want to give each side a related hostname to reflect this dual nature.

The hardware will be selected based on the most demanding software I intend to run on it. Since my laptop can run most things reasonably well, that list mostly contains games.

Going by this table, a quad-core 3.5 GHz CPU and 16 GB of RAM should suffice to start. As for the motherboard, 4-ish SATA ports would be ideal. I'd also like one with sufficient space to increase my RAM if desired in the future (maybe get a single 16 GB stick?). Expansion slots will be dictated by choice of GPU.

An ultra-wide monitor would be awesome, although I have no clue where I'm going to put it (or the machine itself, for that matter).

First pass:

• CPU

  • AMD Ryzen 7 3700X ($290): 8 cores @ 3.6 GHz, 65 W TDP, cooler included, socket AM4
• RAM

  • Corsair Vengeance LPX 16 DDR4-3000 ($40)
• motherboard

  • Asus ROG Crosshair VIII Dark Hero ATX AM4 ($390): no onboard video, X570 chipset
• GPU

  • Gigabyte EAGLE OC Rev 2.0 GeForce RTX 3060 12GB 12 GB Video Card ($370)
• SSD

  • Samsung 860 Evo 1 TB 2.5“ ($144)
• case

  • Corsair Airflow 4000D
• misc

Assembly proceeded mostly without issue, though there was a simple snag: we struggled to mount the disks in the included 2.5” brackets. We found the included screws too short, the brackets too slim, and the bracket mount point incompatible with disk cables. This was because we were trying to place the disks inside the brackets rather than the outside where they belong. As it happens, we were not the only ones to have this problem³⁾. The rest of the components fit together immediately and functioned as expected. Though we haven't heavily stress-tested it yet, the cooling system seems to be working well.

During the assembly process, we at last settled on the hostnames for this machine: jekyll for the Linux side and hyde for the Windows side⁴⁾. Most of this section will be concerned with the former, since that's where the bulk of our effort was spent.

When installing Manjaro i3, we faced the same interface problem that occurred when preparing ultiboot. Windows in active workspaces would not update, necessitating constant workspace switching to get through the installation process. Unlike with ultiboot, the problem persisted post install. The root cause was picom's glx backend, which “requires sane drivers” for Nvidia hardware. Switching to the xrender backend and later back to glx with video-nvidia installed fixed the issue. The original drivers also prevented Steam from fully loading.

VLC similarly required some wrangling to get working. Out of the box, it crashed any time it tried to play videos. As documented on the Arch Linux forum⁵⁾, this apparently began with libva 2.17 but clearly persisted into 2.18 (the version we had installed). Rather than downgrade the package to 2.16, we opted for the workaround suggested early in the thread of setting LIBVA_DRIVER_NAME=nvidia. This solved the problem.

Since one of our major goals with this machine was to use it for recording music, it was imperative that the audio system be as flexible as possible with minimal maintenance effort. To that end, we decided to go all-in on JACK as the primary audio interface. Following instructions on the unofficial ALSA wiki⁶⁾, we created an ALSA loopback device at index 0 and a script to bridge it to JACK. Relevant portions of the configuration files are shown below. The first is /etc/modprobe.d/sound.conf, which specifies that the two primary sound cards (motherboard sound and GPU sound) should be enumerated on indices 1 and 2 and the virtual loopback on index 0. ALSA index 0 is used by most applications as the default device⁷⁾, so even those without detailed audio support can operate without friction.

sound.conf

# create a stereo loopback at index 0 to feed to jack
options snd-aloop index=0 pcm_substreams=2
# the other two cards
options snd-hda-intel index=1,2

The second is ~/.asoundrc, which describes how hardware devices (including the loopback) link to software devices.

.asoundrc

# https://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge
# * ALSA playback = subdevice 0,0 
# * ALSA capture  = subdevice 0,1  
# * Jack readable client (cloop) = subdevice 1,0  
# * Jack writable client (ploop) = subdevice 1,1
 
# playback 
pcm.amix {
    type dmix
    ipc_key 219345
    slave.pcm "hw:Loopback,0,0"
}
 
# capture
pcm.asnoop {
    type dsnoop
    ipc_key 219346
    slave.pcm "hw:Loopback,0,0"
}
 
# duplex device to combine the above
pcm.aduplex {
    type asym
    playback.pcm "amix"
    capture.pcm "asnoop"
}
 
# jack devices
pcm.ploop {
    type plug
    slave.pcm "hw:Loopback,1,1"
}
 
pcm.cloop {
    type dsnoop
    ipc_key 219348
    slave.pcm "hw:Loopback,1,0"
}
 
# default device
pcm.!default {
    type plug
    slave.pcm "aduplex"
}

Finally, we have the script that connects those software devices within JACK.

loop2jack

#!/bin/bash
 
# create jack clients
/usr/bin/alsa_in -j "from alsa" -dcloop -p 2048 2>&1 1>/dev/null &
/usr/bin/alsa_out -j "to alsa" -dploop 2>&1 1>/dev/null &
 
# pass some time
sleep 1
 
# connect alsa -> jack
jack_connect "from alsa:capture_1" "system:playback_1"
jack_connect "from alsa:capture_2" "system:playback_2"
 
# connect jack -> alsa
jack_connect "system:capture_1" "to alsa:playback_1"
jack_connect "system:capture_2" "to alsa:playback_2"