rnd:projects:pc_build_1

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rnd:projects:pc_build_1 [2023-07-05 01:18] asdfrnd:projects:pc_build_1 [2023-07-09 23:45] (current) asdf
Line 38: Line 38:
   * misc   * misc
  
-===== Assembly =====+===== Assembly and configuration =====
 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((https://www.reddit.com/r/buildapc/comments/khro6k/mounting_860_evo_ssd_into_corsair_4000d_airflow/)). 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. 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((https://www.reddit.com/r/buildapc/comments/khro6k/mounting_860_evo_ssd_into_corsair_4000d_airflow/)). 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((The joke being that the Linux side is its respectable face, and the Windows side is the madman we don't openly acknowledge.)). Most of this section will be concerned with the former, since that's where the bulk of our effort was spent.
 +
 +==== Video ====
 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.  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. 
  
-Audio-wiseALSA decided to select the graphics card as its default audio deviceWe set it to the onboard audio following instructions on the ALSA wiki((https://www.alsa-project.org/wiki/Setting_the_default_device)). +VLC similarly required some wrangling to get working. Out of the boxit crashed any time it tried to play videos. As documented on the Arch Linux forum((https://bbs.archlinux.org/viewtopic.php?id=282638)), 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.  
 + 
 +==== Audio ==== 
 +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((https://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge)), 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 soundshould 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((The default device index can be set within ''.asoundrc'', but we thought it best to keep it simple.)), so even those without detailed audio support can operate without friction. 
 + 
 +<file text 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 
 +</file> 
 + 
 +The second is ''~/.asoundrc'', which describes how hardware devices (including the loopback) link to software devices. 
 + 
 +<file text .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" 
 +
 +</file> 
 + 
 +Finally, we have the script that connects those software devices within JACK. 
 + 
 +<file bash 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" 
 +</file> 
 + 
 +<WRAP center round todo 60%> 
 +Figure out how to connect other devices ([[:sounds:zedi 10]], [[:sounds:acdc]]) into the JACK graph. 
 +</WRAP>
  
 +{{tag>needswork}}
  • rnd/projects/pc_build_1.1688519914.txt.gz
  • Last modified: 2023-07-05 01:18
  • by asdf