BEGINNER QUESTION : Getting "BitPerfect" output in Linux ?

[simbloke]

Does your DAC report receiving the data stream speed of the song your listening to? IE do you see it change from 44 to 96 or 192 if that's what the source is providing?

Yes. The player runs mpd and outputs via ALSA at whatever rate the stream is.

 

[Klangliebe]

For beginners. What you get is high musicality for little money, no boom boom boom.


Step 1 - buy one Soundblaster SB0460 (EMU20K1 Chip + Cirrus Logic CS4382 DAC 24-Bit, 192 khz + ST MC4558 opamps + Wolfson WM8775 ADC). Between 5 and 25 € on eBay. Can drive headphones up to 250 Ohm easily. 600 Ohm is may be too silent. Peculiarity - 100% compatible with all Linux distros.

Step 2 - buy one (used) Sennheiser HD598 (creamy brown) or Beyerdynamic DT 990 Black Edition 250 Ohm (less Beyerpeak than PRO).

* May 2020 139,00 € 179,00 € special offer for all Europeans. https://europe.beyerdynamic.com/deals/

Step 3 - /etc/asound.conf

ctl.!default {
card XFi
type hw
}

pcm.!default {
card XFi
type hw
}

#With the "hw" Alsa plugin we communicate directly with the ALSA kernel driver. It is a raw communication without any conversions. Now by default Alsa try to use the same quality characteristics as the source. But PulseAudio still interferes a little, therefore:

Step 4 - /etc/pulse/daemon.conf

resample-method = soxr-vhq
avoid-resampling = yes

default-sample-rate = 192000
alternate-sample-rate = 44100
default-sample-channels = 2

Step 5 - install and use MPV https://mpv.io/ Player for Videophiles but also suitable for Audiophiles (in my opinion). Add the following settings to ~/.config/mpv/mpv.conf

volume-max=120

Voila! Welcome to the world of Audiophiles. If you are not susceptible to HiFi placebo you will be very satisfied. Enjoy your music and love your dreams.

 

[bennetng]

I don't use Linux but here are my measurements of the SB0460 X-Fi card above:
https://www.audiosciencereview.com/...nts-of-evga-nu-audio-pc-card.9137/post-385305
DNR is good, but SINAD is on ASR's "red zone" (88dB).

J-Test:
https://www.audiosciencereview.com/...ents-do-you-like-to-see-next.2343/post-145871

There are also AP2700 measurements on this website:
http://ixbtlabs.com/articles2/multimedia/creative-x-fi.html

The Youtube thumbnail on the post above shows some pins at the right hand side of the card, here are the pinouts (compatible with Audigy series)
The SPDIF I/O are usable with the official Creative driver.

Don't know if the Linux drivers can utilize the card's onboard DSP or not.

 

[dasdoing]

EDIT: I withdraw this post. will just leave it here in order to not destroy logic of following posts

everybody who cares about sound in Linux uses Jack.
the only reason to keep PulseAudio I can think of is Skype app.
alsa only apps you route to Jack like this: https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_with_ALSA

 

[somebodyelse]

everybody who cares about sound in Linux uses Jack.
the only reason to keep PulseAudio I can think of is Skype app.
alsa only apps you route to Jack like this: https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_with_ALSA

As with most things it depends on the use case. Pulse, Jack and pure alsa each have their strengths and weaknesses. It'll be interesting to see whether PipeWire manages to be all things to all men, or just has a different set of compromises.

 

[dasdoing]

As with most things it depends on the use case. Pulse, Jack and pure alsa each have their strengths and weaknesses. It'll be interesting to see whether PipeWire manages to be all things to all men, or just has a different set of compromises.

I don't hate pulseaudio, unlike many others. it's a great sw with user experience in mind. but it comes to it's limit very fast.

 

[Sal1950]

everybody who cares about sound in Linux uses Jack.

You'll have to modify that by at least 1. I care very much about sound and have no use for Jack. My media players all get their data streams thru alsa and to my multich pre/pro totally unmolested, can't do better than that.
Come to think about it, we now have 9 pages on this Linux thread and this is very near the first time Jack has come up. So I think there might be a few more Linux music lovers here that don't use Jack.
I am glad you like it.

 

[somebodyelse]

I don't hate pulseaudio, unlike many others. it's a great sw with user experience in mind. but it comes to it's limit very fast.

So long as your user doesn't want an experience that the developers have decided to block by design

 

[dasdoing]

You'll have to modify that by at least 1. I care very much about sound and have no use for Jack. My media players all get their data streams thru alsa and to my multich pre/pro totally unmolested, can't do better than that.
Come to think about it, we now have 9 pages on this Linux thread and this is very near the first time Jack has come up. So I think there might be a few more Linux music lovers here that don't use Jack.
I am glad you like it.

ok, I expressed myself badly. I was talking about advanced usage.
just one example: with jack you can create crossovers for your outputs in a few minutes.
also any advanced routing is only possible with jack. how you send REW output into a convolver and convolver output to speakers with alsa for example? it's probably possible with a lot of work in .asoundrc, but would be a pita

 

[PenguinMusic]

Hi,
I used to use Jack and then switched to "Pure ALSA".
But thanks to the "no re-sampling" trick in PulseAudio, I can now play all sounds, from all sources, without having to quit an app to have sound on the other one. That is pretty nice.

Also, JACK has a limitation when it comes to "BitPerfect".
As PulseAudio it uses a a "fixed sample rate".
So if you configure it to output 24/96, it will output 24/96 even if the source is 16/44...

So, not really the best option.
Of course, for advanced sound AMNIPULATION Jack may be the way to go.
For simple playback, I am unsure if it is even needed.

 

[dasdoing]

I edited my first post here. I the context of most use-cases by the users here, it was wrong

Also, JACK has a limitation when it comes to "BitPerfect".
As PulseAudio it uses a a "fixed sample rate".
So if you configure it to output 24/96, it will output 24/96 even if the source is 16/44...

this is only half the truth though. jack will never do any sample rate conversion. The player you use does (or not). If you use Audacious for example, it wont play the file with wrong sample rate. It has a converter plugin for this, but it wont be enabled by default

 

[PenguinMusic]

I edited my first post here. I the context of most use-cases by the users here, it was wrong

this is only half the truth though. jack will never do any sample rate conversion. The player you use does (or not). If you use Audacious for example, it wont play the file with wrong sample rate. It has a converter plugin for this, but it wont be enabled by default

Hum, if you say so...
But my DAC has a small indicator to inform about the sample rate of the input signal.
If I use Jack and set it to 24/96, the indicator remains on 24/96 even if I feed it with 16/44 signal.

It is the same the other way round.
If I set Jack tou 16/44, the indicator remains on 16/44 even if the files played are 24/96 :-(

So, maybe there is no resampling when the 16/44 is played and Jack is set to 24/96...
But I cannot imagine there is no resamplingwhen Jack is set to 16/44 and it is fed with 24/96 files.

All in all : to go the safe route : configure JACK to 24/192... so the files will be "played as 24/192" but with no addition to the original format (16/44 or 24/96) ?

Regards.

 

[dasdoing]

Hum, if you say so...
But my DAC has a small indicator to inform about the sample rate of the input signal.
If I use Jack and set it to 24/96, the indicator remains on 24/96 even if I feed it with 16/44 signal.

It is the same the other way round.
If I set Jack tou 16/44, the indicator remains on 16/44 even if the files played are 24/96 :-(

So, maybe there is no resampling when the 16/44 is played and Jack is set to 24/96...
But I cannot imagine there is no resamplingwhen Jack is set to 16/44 and it is fed with 24/96 files.

All in all : to go the safe route : configure JACK to 24/192... so the files will be "played as 24/192" but with no addition to the original format (16/44 or 24/96) ?

Regards.

they way jack works is that it is fixed at one sampe rate. If you start it in one sample rate it will only accept this sample rate. it was created for audio production.
so, the only way to play missmatching sample rates is to convert it in the player software. imo a media player should have options to control the sample rate conversion behaviour.
I understand that this behaviour of jack is unconvinient in this case. but it is that way to ensure that in audio production samplerates always match

 

[somebodyelse]

ok, I expressed myself badly. I was talking about advanced usage.
just one example: with jack you can create crossovers for your outputs in a few minutes.
also any advanced routing is only possible with jack. how you send REW output into a convolver and convolver output to speakers with alsa for example? it's probably possible with a lot of work in .asoundrc, but would be a pita

Not that much of a PITA - see the bruteFIR plugin for Volumio for an example. Crossovers aren't too hard either. And they work headless and with system-level player daemons where Pulse doesn't (explicit design decision) and Jack is less easy than it could be.

 

[Sal1950]

they way jack works is that it is fixed at one sampe rate. If you start it in one sample rate it will only accept this sample rate. it was created for audio production.
so, the only way to play missmatching sample rates is to convert it in the player software. imo a media player should have options to control the sample rate conversion behaviour.

So Jack may be the thing to use for production use, but for the Audiophile who's main interest is getting bit-perfect playback of his/her cherished high resolution music files, pure Alsa is still the way. I'm a multich guy and things can get dicey when trying to playback mixed and unmatched 2, 4, 5.1, and Atmos files of all different speeds and types, PCM & DSD. When I'm listening to my music I don't want to be bothered by other sound files/sources so that is not a limitation, it's a feature.

 

[dasdoing]

Alsa will put out same sample rate as source (unless dmix is envolved). you guys are right, for playback alsa is better

 

[xthechar]

Alsa is nice because you know your music isn't getting resampled. It's bit-perfect by default and by design. But now that pulse has avoid-resampling, any time you play a single audio source at a time, it will do bit-perfect playback as well. The feature-set is pretty much a superset of alsa at this point, since it will play any single source bit-perfectly but will also allow for playback from multiple sources at a time, or for automatically switching between configurations without fiddling with config files. I see no drawback of using pulse, unless you always use a configuration so simple that alsa can cover it painlessly. Since I use my computer for things besides just music-listening and often have multiple audio streams open at a time, pulse suits me perfectly. In addition to tweaking the daemon.conf file, I have configured default.pa by editing the line:

load-module module-udev-detect

to read

load-module module-udev-detect tsched=1 tsched_buffer_size=2824

What this does is lower the buffer to 8ms, which is half a 60fps frame, so essentially real time.

I have also successfully played 96khz files via firefox, for what it's worth. It seems that firefox or chromium will pass through the file to pulse in its native format, and pulse will treat it the same way it treats a file coming from any other application, like a music player.

 

[MRC01]

Interesting. It should have worked, as long as you actually only have one source playing. Running `pacmd list-sink-inputs` as I mentioned before, can help finding out what is actually being sent to PA. Likewise, PA can also be too helpful in autodetecting your setup sometimes and running `pacmd list-sinks` can also help iron out some kinks in how it operates.

Actually, it is working now! I set the primary secondary rates to either 44.1 / 48, or 88.2 / 96. As long as I don't have anything else using audio, then Pulse will resample to the "best" of these 2 options. It seems to choose "best" not by whichever is closest, but whichever is an integer multiple. For example, a 176.4 recording will resample to 88.2, not to 96. And a 48 kHz recording will resample to 96, not 88.2 or 44.1.

In my view, this behavior is correct and as expected. The Pulseaudio version 11 feature of avoid_resampling actually shifts to the exact rate without resampling. That's great. But this version 1.8 behavior is perfectly sufficient because you can pick the primary & alternate rates so that whatever resampling it does is always an integer multiple.

 

[MRC01]

In addition to tweaking the daemon.conf file, I have configured default.pa by editing the line:

load-module module-udev-detect

to read

load-module module-udev-detect tsched=1 tsched_buffer_size=2824

What this does is lower the buffer to 8ms, which is half a 60fps frame, so essentially real time.

I have also successfully played 96khz files via firefox, for what it's worth. It seems that firefox or chromium will pass through the file to pulse in its native format, and pulse will treat it the same way it treats a file coming from any other application, like a music player.

Excellent advice! I was getting dropouts with Pulseaudio version 1.8, so I disabled tsched entirely and used fragments to increase the buffer to 200 ms. However, if I can increase the buffer with the newer timer-based scheduling this is even better. I'll give this a try.

OK so the problem with this approach is that you can make the buffer smaller than the default (196,608 bytes), but you can't make it bigger. When I set smaller values, I see it use them and latency goes down. But when I set bigger values, it ignores them and uses its default. And in my case, the default buffer isn't big enough. So it's impossible to get glitch-free audio with timer-based scheduling on this machine. Incidentally, it's a fast machine (i7-4770 at 3.7 GHz) so it's probably an OS limitation not being able to schedule the interrupts reliably enough for low latency to work.

However, by disabling timer-based scheduling and using buffer-based, I can increase the buffer size above the default and get higher latency with glitch-free audio. The latency is 100 msec which is pretty bad, but I'm not a gamer so it doesn't affect me at all. The default tries for 18 ms which is a bit too low.

But that's a great tip that will be useful to others, if not to me.

 

[MRC01]

I got a couple of Ubuntu PCs that had glitchy audio both working smoothly with Pulseaudio. Now they play audio at any bit rate without resampling and without glitching. In doing so I documented the config settings I changed. Posted them here, and here, in case this helps anyone else.