Pushing audio bits straight to dedicated audio hardware. For example, sending raw 16bit PCM at 44kHz straight to a DAC. This seems like a reasonable goal if you've got the right hardware, Right?
It still requires some attention but pipewire has improved things.
You will need some hardware, a USB DAC is ideal. It should support the most sample types and frequencies. Lower on the list are HDMI, Coaxial, and Optical. Optical sounds the best as lasers can't get interference from ground loops, can be used by sharks, etc. but it isn't. Toslink doesn't have enough bandwidth for more than two uncompressed channels of audio. Yes, I was disappointed too.
This is the backend where the bits leave the computer. This is useful to see what we are actually piping out to the world and you have a long way to go if you don't see anything here.
aplay -l or -L will tell you about your devices. HDMI audio is a thing so you will
probably have more devices than you expected. For a DAC, you will want to find
the usbstream:CARD=DAC. With the card number X we can see the capabilities:
cat /proc/asound/cardX/stream0
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000
Data packet interval: 125 us
Bits: 32
Channel map: FL FR
Sync Endpoint: 0x81 (1 IN)
Sync EP Interface: 1
Sync EP Altset: 1
Implicit Feedback Mode: No
If you're lucky, you might see Format: SPECIAL DSD_U32_BE for more complicated setups than I will cover.
With aplay -L you'll want to see that you have a iec958 (optical out) device.
iec958:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Digital
IEC958 (S/PDIF) Digital Audio Output
Config files should be copied from /usr/share/pipewire/ to the user path ~/.config/pipewire/.
In the pipewire.conf, you can change the default rate and allowed-rates to match your hardware.
## Properties for the DSP configuration.
default.clock.rate = 96000
default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 352800 384000 ]
restart this all after changing:
systemctl --user restart wireplumber pipewire pipewire-pulse
verify with: pw-metadata -n settings | grep clock.allowed.rates
watch the outputs: pw-top
other useful tools: pw-cli ls Device pw-dump pw-cat pw-play
resampling is another story, maybe for another day.
0.5.x updates the .lua scripts to .json. I thought I had these but abandoned them after the pipewire.conf worked.
Check to see what format and bitrate is actually being used by the device:
~ cat /proc/asound/card0/pcm1p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 44100
buffer_size: 88200
Pipewire comes with a simple pw-play command, which should do the right thing by default.
Setup pipewire output and it should do the right thing. Formerly I had this set to pipe straight to the ALSA device. With Optical output, this would cause glitches when moving from a high bitrate to a lower one (96k -> 44k).
Does not do the right thing yet.
native DSD playback with pipewire
This seems like an interesting tool to dump optical output information, even if it doesn't appear to do much in consumer mode.
iecset -Dhw:1
head-fi bit-perfect-audio-from-linux
Are your files okay? Check the md5sums against values in flac header for corruption! This won't fix a glitchy rip or recode.
find /path/to/music -type f -iname '*.flac' -print0 | xargs --null flac -wst
No glitches, good? why don't they have the same checksums? See what's in the tag info with exiftool.
exiftool filename.flac > filename.txt
hash the audio in the flac stream to see if they're really different:
for f in *.flac ; do echo -n "$f "; ffmpeg -nostdin -i "$f" -c:a copy -f hash - 2>/dev/null ; done
spectrogram paranoia
sox filename.flac -n spectrogram -o filename.png
Are your files actually the same files which were written?
btrfs with raid1 can help find and repair corrupted files from their original checksums. Normal btrfs can too but you'll need a backup to repair.
The audio bits lie! (sorta) Quake's audio soundtrack was a haunting ambient score by NIN which as pressed as extra tracks after the data.
It was recorded to the cd with pre-emphasis applied to the tracks. This means that the higher frequencies would be boosted prior to writing the tracks, resulting in a better signal to noise ratio. If you use a dedicated CD device or direct line, the emphasis bit will be detected, boost removed, and you hear what you expect. Unfortunately, if you read the tracks as data for copying to flac, the boost will persist and you'll have a heavy high frequency version of the soundtrack. This is well handled with SoX but it took me an embarrassingly long amount of time actually learn emphasis existed in spite of decades of listening to this cd.
quake soundtrack solutions - source of the enlightenment.
In 2020 it was remastered on vinyl. Apart from missing a nice booklet, the pre-emphasis was also absent for final verification.
*NOTE
WE DESIGNED THIS REISSUE TO INCLUDE A BOOKLET CONTAINING ESSAYS FROM ID SOFTWARE’S JOHN CARMACK AND AMERICAN MCGEE. A CERTAIN UNNAMED VIDEO GAME PUBLISHER MADE IT IMPOSSIBLE TO INCLUDE THIS IN THE PACKAGE, SO PLEASE HONOR THEIR WISHES BY NOT CLICKING HERE TO EVEN SEE THE ESSAYS OR HERE TO PRINT THE BOOKLET OUT FOR YOURSELF