BEGINNER QUESTION : Getting "BitPerfect" output in Linux ?

[MRC01]

I don't know about ALSA, but you can create your own custom stream and have Google Chrome output to it.
On my Ubuntu system, Chrome always resamples everything to a fixed rate, while Firefox passes audio at the audio's native rate.

 

[Lttlwing16]

and have Google Chrome output to it.

I didn't see a way to change the output of Google Chrome -- how do you go about that?

 

[Lttlwing16]

One thing I did not try last night was to set the alternate sample rate to 96000hz... The vinyl rips and subsequent .flac files are in 96000hz, so it may be a viable option. Everything else is fine at 44.1khz. Looks like s32le is the default bit depth for now regardless of settings.


I'll check tonight and report back.

 

[MRC01]

I didn't see a way to change the output of Google Chrome -- how do you go about that?

I haven't yet discovered the command-line way, so I use the PulseAudio Volume Control app. On the Playback tab you can assign a Pulseaudio stream to any app that is playing audio. That is, after running the above command to create your own audio stream, it will show up in the GUI app and you can assign various apps to use it.

 

[danadam]

I haven't yet discovered the command-line way, so I use the PulseAudio Volume Control app. On the Playback tab you can assign a Pulseaudio stream to any app that is playing audio.

pacmd move-sink-input ?

move-sink-input Move sink input to another sink (args: index, sink)

 

[danadam]

I have my /etc/pulse/daemon.conf file properly modified to bit rate of s24le, yet in the hwparams and in the sink output it states floate32LE.

I commented those out [...]. However, the bit depth was still returning s32le

So which one is it, float32le or s32le?

If the value in the alsa sink is different from the configured default, it just means that the hardware (or the alsa driver for the hardware) does not support it. If you want to know what is supported then look into /proc/asound/cardN/. For usb devices I have stream0 file, for example:

Gmaxtech AudIo. UDA-01 96KHz USB DAC at usb-0000:00:13.1-1, full speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Bits: 24
    Channel map: FL FR

For HDA Intel devices I have codec#0 file, for example:

Codec: Realtek ALC889A
...
Default PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
...

 

[Lttlwing16]

So which one is it, float32le or s32le?

Well, it seems pacmd list-sink-inputs is showing float32le, where the output of hwparams is s32le.

Here is the output of stream0 for my SDAC:

Grace Design SDAC-B USB 2.0 at usb-0000:00:1d.7-5, high speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600
    Data packet interval: 125 us
    Bits: 32
    Channel map: FL FR
  Interface 1
    Altset 2
    Format: SPECIAL
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600
    Data packet interval: 125 us
    Bits: 32
    DSD raw: DOP=0, bitrev=0
    Channel map: FL FR

So, yeah surprisingly looks like it only supports 32bit? Seems odd, but that explains everything output in s32le

and the output of the same file playing back via audacious:

[david@david-protools ~]$ pacmd list-sink-inputs
1 sink input(s) available.
    index: 9
    driver: <protocol-native.c>
    flags:
    state: RUNNING
    sink: 0 <alsa_output.usb-Grace_Design_SDAC-B_USB_2.0-00.analog-stereo>
    volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
            balance 0.00
    muted: no
    current latency: 500.00 ms
    requested latency: 460.00 ms
    sample spec: float32le 2ch 44100Hz
    channel map: front-left,front-right
                 Stereo
    resample method: copy
    module: 14
    client: 20 <Audacious>
    properties:
        media.name = "Audacious"
        application.name = "Audacious"
        native-protocol.peer = "UNIX socket client"
        native-protocol.version = "35"
        application.process.id = "3767"
        application.process.user = "david"
        application.process.host = "david-protools"
        application.process.binary = "audacious"
        application.language = "en_US.utf8"
        window.x11.display = ":0"
        application.process.machine_id = "675df23d99b8436bb7b9875ef0b74bd4"
        application.process.session_id = "2"
        application.icon_name = "audacious"
        module-stream-restore.id = "sink-input-by-application-name:Audacious"

Every 1.0s: cat /proc/asound/card2/pcm0p/sub0/hw_params

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 44100
buffer_size: 88200

Good news is it appears that, with exception of the fixed bit depth, I've been able to configure things to my liking. Below is my findings:

etc/pulse/daemon.conf changes


avoid-resampling = true default-sample-format = s24le default-sample-rate = 44100 alternate-sample-rate = 96000

*Pulse audio volume control will lock 44.1 hz, must be closed for above to function properly


Pulseaudio volume control Configuration:


Built in Audio: Analog Stereo Input

SDAC-B USB 2.0 : Analog Stereo Output

Audacity -- confirmed to be recording via internal card at s32le 96000hz and playback. With *pacmd list-sink-inputs returns -0- , confirming bypass of Pulseaudio.

Audacity controls configured for ALSA with Alsamixer properly controling volume in Audacity for recording and playback with PA volume control closed.


Audacious - Configured to output to Pulseaudio

Confirmed with native playback of sample rate, and no resampling. All bitdepth is listed as s32le via terminal hwparams. Appropriate sample rate according to media was displayed in terminal output.


Google Chrome/Spotify/Youtube

Appropriate playback @ s32le / 44.1khz for listed websites. * did not test online hi fidelity files.

So, for me alternate sample rate and avoid-resampling were key to arrive at the settings that work for me.

Thanks for all your help!

 

[johnk]

FYI

I recently found this excellent summary of the various Linux sub-systems which has really helped me to understand how it works.

https://venam.nixers.net/blog/unix/2021/02/07/audio-stack.html

 

[Lttlwing16]

Hey folks, I wrote up my process for recording in Manjaro Linux and posted it here.

 

[Sal1950]

All good Linux stuff, thanks for posting gentleman.

 

[danadam]

Hey folks, I wrote up my process for recording in Manjaro Linux and posted it here.

You normalize tracks separately from each other? Won't you lose relative differences in loudness that the album was mastered with?

(I'll refrain from commenting on using 24/96 for vinyl )

 

[Lttlwing16]

You normalize tracks separately from each other? Won't you lose relative differences in loudness that the album was mastered with?

(I'll refrain from commenting on using 24/96 for vinyl )

Did you mean relative differences in loudness -- track to track, or within the track?

The way I understand normalization, and feel free to correct me -- with the exception of a random pop or click affecting the normalization, dynamic range should be conserved within the track. Each track's peak transient would be brought to the level specified (-1.0 in my tutorial) and the rest of the information would be brought up relative to this peak, maintaining the dynamic range.

The recommendation I picked up on was over on Steve Hoffman, here.

However, thinking it through, you make a good point and it would probably be better practice to normalize the entire album together, then edit out the tracks. This way the entire dynamics of the album are retained. I'll experiment tonight.

-- Comment any way you'd like, not going to bother me! Think 24/96 is overkill for vinyl rips? Some think it's underkill! I had the hardware capacity and storage space, and from what I've gathered the increased bit depth helps with the normalization/editing. The sample rate, well, some would argue higher sample rates handle impulse response better. To each their own!

 

[Lttlwing16]

@danadam you were absolutely right. To maintain the album dynamics, one needs to normalize as a whole, unless of course, one wants to really normalize each track to each other. I updated the tutorial over on the manjaro forum with the update, so thanks for the tip.

Here are couple images of before and after normalization to demonstrate the maintenance of relative track volumes:

BEFORE:

AFTER Norm:

 

[danadam]

Comment any way you'd like, not going to bother me! Think 24/96 is overkill for vinyl rips?

IMO it's overkill in general, but 24 bit for vinyl is in particular. Through unmentionable methods I obtained a rip of "Daft Punk / R.A.M. / Get Lucky" from 180 g vinyl, in DSD128. Big numbers, so must be good. The last 4 seconds is a nice "silence", i.e. vinyl scratching. Here's how its left channel compares to 14 and 15 bit dither:

In addition to that, the track is not normalized and the peak is at -8 dBFS. There is no reason not to apply at least 6 dB of gain, which would move the grey graph that much higher.
If you want you can listen to "silence" samples in attachment. The "gain" versions have 30 dB of gain applied.

I had the hardware capacity and storage space,

I guess I'm weird but for me it is no argument at all

from what I've gathered the increased bit depth helps with the normalization/editing.

For capturing and editing, sure. I'm just talking about the final product.

 

[Sal1950]

I ripped my entire vinyl collection before I retired and moved to FL.
I used Audacity at 16/44.1 and doing careful listening tests I couldn't hear any difference between the LP and the file.
That's as it should be since done properly the Redbook standard should offer all the resolution the human ear is capable of hearing.
Besides, vinyl being vastly inferior as a medium for music , RB should be all you would ever need.
YMMV

 

[Lttlwing16]

Here is a pretty informative read on the topic : https://www.soundguys.com/audio-bit-depth-explained-23706/

That said, if I'm recording at 24 bit for editing purposes, and want to avoid dithering, I'd have to output to 24bit. Why would I want to avoid dithering? Just one more process to possibly introduce error/noise.

In the end, I see and understand the marketing hype used to push 24 bit/high sample rate audio. However, I feel the logic stands, if it isn't costing anything extra (accept storage space, which is cheap), it's not hurting anything, and opens the potential for the best transfer from analog to digital while keeping editing and output homologous, why not?

 

[dc655321]

Why would I want to avoid dithering? Just one more process to possibly introduce error/noise.

That's genuinely funny!

I can't imagine adding dither to an inherently noisy LP signal would cause any degredation.

 

[Lttlwing16]

That's genuinely funny!

I can't imagine adding dither to an inherently noisy LP signal would cause any degredation.

Lol, good point, but only if the software and user execute it properly! My point! Another step, another chance for introducing errors along the line.

Backdrop that with the "can't hurt, can only help" logic of exporting to 24bit, 96000hz (obviously overkill) and I see no need for dithering anything anyway.

Once again, to each their own!

 

[Sal1950]

That said, if I'm recording at 24 bit for editing purposes,

Well yeh, if your going to do a bunch of editing to the files you might want the security of more elbow room.
If only for doing archiving, beyond Redbook is just a waste of bandwidth.
YMMV

 

[Lttlwing16]

Next question for me -- how up to snuff this on-board ADC on the Realtek ALC262 soundcard is vs a newer USB soundcard like the Motu M4 or Scarlett 2i2 Gen3?