[tjw321]

so a RPI with std pi linux and a usb SSD works ok? what player do you use on rpi? strawberry?

I've used a few and haven't really found one that I am completely happy with. I'm currently using "Quod Libet" but I change quite often.

I haven't tried Strawberry yet, so that may be next...

 

[disaster8tio]

I use DeadBeef 1.8.8 as player with Debian 11. Easy to get DAC handling the sound Hz and bits. Choose ALSA then choose the DAC - Direct hardware device without any conversions. Then remove DSD/P pluggin under "DSP". Restart Deadbeef and it is on. May depend on DAC, i use a Topping D10s. And the Deadbeef layout is constumized to my preference.

 

[gimmeheadroom]

I didn't see any post in this thread that proves anybody is getting bit-perfect output. It seems like people think if they get some music app to use a specific device that's all it takes. But that isn't proof of anything.

The only proof I know of bit-perfect is to send an MQA bitstream to an MQA DAC. If your bitstream isn't bit-perfect, it won't play in MQA.

I have not found anything that can play SACD ISOs on Linux. Can anyone recommend a good player comparable to Foobar2000?

 

[111MilesToGo]

I didn't see any post in this thread that proves anybody is getting bit-perfect output. It seems like people think if they get some music app to use a specific device that's all it takes. But that isn't proof of anything.

The only proof I know of bit-perfect is to send an MQA bitstream to an MQA DAC. If your bitstream isn't bit-perfect, it won't play in MQA.

Or send an HDCD bitstream to an HDCD DAC (if one has such), as is being used by the Computer Audiophile, founder of the Audiophile Style website.

I have not found anything that can play SACD ISOs on Linux. Can anyone recommend a good player comparable to Foobar2000?

AFAIK, the closest you can get is MPD, the Music Player Daemon:
- The official version plays DSD nicely from DSF *.dsf and DSDIFF *.dff track files, but not from SACD-ISOs. What you could do in this regard is extract the separate tracks from your ISO on a Windows computer. This is what I am used to do.
- There is an unofficial fork of MPD which says to play SACD-ISOs. I haven‘t tried it. However, use of this fork is sort of disrespected; in particular, one should NEVER ask for help with this fork on the official MPD forum.

The closest analogy to foobar2000 is DeaDBeeF, but not 100%. The wealth of foobar2000 plug-ins remains unsurpassed.

 

[gimmeheadroom]

Or send an HDCD bitstream to an HDCD DAC (if one has such), as is being used by the Computer Audiophile, founder of the Audiophile Style website.

Interesting, I did not know that HDCD required bit perfect. Of course, very few people in this thread can use that method to test and I haven't seen that anybody did.

Anyway, it's troubling to see 34 pages of unsubstantiated claims in this thread. I think it has been a confusing and unhelpful discussion until now. Many people seem to be taking it on faith that if they go through the motions then they get bitperfect. But we have no reason to believe that. It should be verified. And since nothing but Volumio paid subscription seems to claim MQA support on Linux, I would guess most of the bitperfect claims of various distros and setups are untrue.

AFAIK, the closest you can get is MPD, the Music Player Daemon:

I know this is a good one, but to my understanding, the player is not the main issue with bitperfect but rather the many layers of software that gets involved in audio on a general purpose desktop distro.

- The official version plays DSD nicely from DSF *.dsf and DSDIFF *.dff track files, but not from SACD-ISOs. What you could do in this regard is extract the separate tracks from your ISO on a Windows computer. This is what I am used to do.

I think this is not a realistic option for many people and it's also not desireable. I have about 400 SACD ISO rips. I don't plan to spend any time breaking them into individual DSDs, and I don't need to. My goal is to play music in the best environment and despite my hatred of Windows, the best music player environment seems to remain foobar with ASIO. And all my gear supports that.

- There is an unofficial fork of MPD which says to play SACD-ISOs. I haven‘t tried it. However, use of this fork is sort of disrespected; in particular, one should NEVER ask for help with this fork on the official MPD forum.

Thanks for the heads up

The closest analogy to foobar2000 is DeaDBeeF, but not 100%. The wealth of foobar2000 plug-ins remains unsurpassed.

I built deadbeef from source a few years ago and didn't like it. At that time it couldn't play DSD and certainly not SACD ISO. I just tried it again last night from a package repo and supposedly it can invoke ffpmeg to play DSD but after taking a quick look I uninstalled it again.

I get it that people prefer Linux to Windows, I'm certainly one of them. And I get it that Linux drivers and USB have been good enough for years already that USB DACs just work with Linux, unlike in the bad old days. But I don't get it that people don't go for the easy, proven solution of Windows and ASIO and factory-supplied ASIO DAC drivers. To me it is the most sensible solution.

 

[powerhouse64]

I didn't see any post in this thread that proves anybody is getting bit-perfect output. It seems like people think if they get some music app to use a specific device that's all it takes. But that isn't proof of anything.

The only proof I know of bit-perfect is to send an MQA bitstream to an MQA DAC. If your bitstream isn't bit-perfect, it won't play in MQA.

I have not found anything that can play SACD ISOs on Linux. Can anyone recommend a good player comparable to Foobar2000?

I may not be able to answer the question fully, but there are several ways in Linux to see how your audio is handled. After you installed one of the audio players suggested at the beginning of this thread (plus perhaps Strawberry), you can do some checks to see how audio is handled:

lsof /dev/snd/*

lists the programs that are using sound.

watch -n0.5 'pacmd list-sink-inputs | tee -a sound-inputs.log'

shows / monitors the pulseaudio inputs currently active. Only relevant when you have pulseaudio running on your Linux system. This command can be helpful when playing music via alsa to monitor if any pulseaudio is "interfering". If nothing else is producing sound, it will show
0 sink input(s) available.

I'm running gmusicbrowser as my audio player using the settings described in this thread and - while playing - it will block other sound output. In other words, gmusicplayer is able to take exclusive control of the sound output on the specified device. This goes a long way in ensuring that the audio is not mixed.

Assuming you use ALSA, you can list your output devices like this:

aplay -l

While playing music, check with this command:

cat /proc/asound/card0/pcm0p/sub0/hw_params

Replace the card0. pcm0, sub0 entries with what you found with aplay -l. Here is an example output:
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 440
buffer_size: 8820

The above should give a good indication on the audio output.

In general, Linux should provide more and better tools for bit-perfect audio. The reason I'm saying that is because Linux can be downsized to the essential tasks, and there are real-time Linux distros or options. There are some audiophile distros as well, see for example https://www.thewelltemperedcomputer.com/Linux/Distro.htm.

Hope it helps.

 

[gimmeheadroom]

I may not be able to answer the question fully, but there are several ways in Linux to see how your audio is handled. After you installed one of the audio players suggested at the beginning of this thread (plus perhaps Strawberry), you can do some checks to see how audio is handled:

lsof /dev/snd/*

lists the programs that are using sound.

watch -n0.5 'pacmd list-sink-inputs | tee -a sound-inputs.log'

shows / monitors the pulseaudio inputs currently active. Only relevant when you have pulseaudio running on your Linux system. This command can be helpful when playing music via alsa to monitor if any pulseaudio is "interfering". If nothing else is producing sound, it will show
0 sink input(s) available.

I'm running gmusicbrowser as my audio player using the settings described in this thread and - while playing - it will block other sound output. In other words, gmusicplayer is able to take exclusive control of the sound output on the specified device. This goes a long way in ensuring that the audio is not mixed.

Assuming you use ALSA, you can list your output devices like this:

aplay -l

While playing music, check with this command:

cat /proc/asound/card0/pcm0p/sub0/hw_params

Replace the card0. pcm0, sub0 entries with what you found with aplay -l. Here is an example output:
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 440
buffer_size: 8820

The above should give a good indication on the audio output.

In general, Linux should provide more and better tools for bit-perfect audio. The reason I'm saying that is because Linux can be downsized to the essential tasks, and there are real-time Linux distros or options. There are some audiophile distros as well, see for example https://www.thewelltemperedcomputer.com/Linux/Distro.htm.

Hope it helps.

This is all good info, but the proof of bit perfect audio is that a DAC can decode MQA (or HDCD as @111MilesToGo suggested above)

 

[Roseval]

I doubt if MQA is a good test for bit perfect.
Here https://audiophilestyle.com/forums/...s-to-16-bits-and-the-blue-light-still-shines/ you have a guy truncating a 24 bit to 16 and the MQA light still works!

If your media player can write to a file or you can record the digital out of your PC, you can do a null test.
Load the original file and the recorded in a editor
Time align
Substract
If you end up with null's only, the two files are identical.

 

[gimmeheadroom]

I doubt if MQA is a good test for bit perfect.
Here https://audiophilestyle.com/forums/...s-to-16-bits-and-the-blue-light-still-shines/ you have a guy truncating a 24 bit to 16 and the MQA light still works!

Thank you, great thread!

If your media player can write to a file or you can record the digital out of your PC, you can do a null test.
Load the original file and the recorded in a editor
Time align
Substract
If you end up with null's only, the two files are identical.

Well yeah, if everything works... I'm not sure it's more than theory at this point.

Anyway, from a practical point of view MQA is the best test of bit perfect we have.

 

[powerhouse64]

This is all good info, but the proof of bit perfect audio is that a DAC can decode MQA (or HDCD as @111MilesToGo suggested above)

My first post offered some tools to narrow down issues with the audio path. If I use both pulse audio and ALSA, I want to make sure my music player uses ALSA and doesn't mix the sound. For me, this is my only concern.

In your post #498 you are asking for proof that Linux offers bit-perfect sound. The question suggests that Linux isn't capable of outputting bit-perfect audio.
While I can't proof or disproof bit-perfect audio under Linux, at least not right now, I suggest to look at what vendors of top end audiophile music players are selling you: essentially Linux boxes.

I didn't do an all inclusive survey, but have a look at aurender, Lumin, Music Fidelity, Naim, and probably more. There are exceptions too: Taiko Audio Extreme runs a Custom Windows 10 Enterprise LTSC OS.

With music server vendors that run Linux, you have to look for the small print to identify them as Linux servers. I guess Linux still carries the stigma of a nerd OS.

I hope you accept this indirect answer. It's not a proof (perhaps someone else can proof it). My other post may help narrow down issues with your Linux audio configuration.

 

[111MilesToGo]

So here is the proof for Linux being bit-perfect through alsa, as far as such proof can be gathered with the proposed method.

Whatever the inner details of MQA workings and handlings might be, I thought the idea of testing Linux / alsa with an MQA file is a good idea. I used an album by 2L (Christian Grøvlen: Bach - Inside Polyphony) that I got as PCM176, DSD64, and MQA352 (the latter means published as MQA 24/44.1 and unfolding to 24/352.8).

I played the various files from hard disk both under Windows with foobar2000 and Linux openSUSE Tumbleweed with MPD/Cantata to my Cayin N6ii, used as USB-DAC. On Windows I utilized the Cayin ASIO driver, while on Linux I set up MPD to play directly to alsa (circumventing pulseaudio and pipewire, whatever). In addition, I streamed this MQA album from Tidal under Windows using both the Tidal app and Roon with Tidal integration.

The N6ii displays what is happening on the USB audio coming in, and what it does on its DAC. On Windows, I checked the Cayin ASIO driver to show the correct sample rate, while on Linux I checked the alsa hardware parameters to show the correct sample rate and expected bit depth.

Guess what: As far as it can be ”proven“ by MQA detection and unfolding happening in the N6ii, EVERYTHING IS BIT-PERCECT.

The results as per the N6ii display do all make sense. This holds for Tidal under Windows, where the Tidal App does the first unfold, as well as for Roon on Windows, where I can set Roon to do the first unfold or leave all unfolding to the N6ii DAC. foobar2000 on Windows and MPD/Cantata on Linux do produce the same results as Roon without first unfold, as is expected in the case of bit-perfect output from the PC USB port.

As has been said, the premise is that MQA detection in the DAC would imply that all audio bits come out of the USB port in unaltered fashion.

Addendum: Unfortunately, I don‘t have a DAC capable of HDCD detection and decoding. In HDCD, the least significant bit of the encoded 16/44.1 audio contains control and data sequences that enable the HDCD decoder to expand up to 20/44.1. If the bits and in particular the least significant one are being tampered with, HDCD control sequences get destroyed - no HDCD anymore.

 

[gimmeheadroom]

My first post offered some tools to narrow down issues with the audio path. If I use both pulse audio and ALSA, I want to make sure my music player uses ALSA and doesn't mix the sound. For me, this is my only concern.

In your post #498 you are asking for proof that Linux offers bit-perfect sound. The question suggests that Linux isn't capable of outputting bit-perfect audio.

There is no reason to expect that Linux does offer bit perfect. It was not designed for audio at all, much less bitperfect audio. It's a general purpose OS (kinda). The default setup is certainly not bitperfect and this is why we have 34 pages of thread.

While I can't proof or disproof bit-perfect audio under Linux, at least not right now, I suggest to look at what vendors of top end audiophile music players are selling you: essentially Linux boxes.

That has nothing to do with anything. The streamers are not a desktop Linux distro and they don't have the USB issue. They're embedded Linux with a real-timer kernel and the DAC on board. They can also not use ALSA, pulse, jack, or anything else they need. It's a custom setup, which is mostly what Linux is good for, after all...

Whatever the inner details of MQA workings and handlings might be, I thought the idea of testing Linux / alsa with an MQA file is a good idea.

I said above that MQA is the only test I'm aware of for bitperfect audio generally, yes.

I used an album by 2L (Christian Grøvlen: Bach - Inside Polyphony) that I got as PCM176, DSD64, and MQA352 (the latter means published as MQA 24/44.1 and unfolding to 24/352.8).

I played the various files from hard disk both under Windows with foobar2000 and Linux openSUSE Tumbleweed with MPD/Cantata to my Cayin N6ii, used as USB-DAC. On Windows I utilized the Cayin ASIO driver, while on Linux I set up MPD to play directly to alsa (circumventing pulseaudio and pipewire, whatever). In addition, I streamed this MQA album from Tidal under Windows using both the Tidal app and Roon with Tidal integration.

The N6ii displays what is happening on the USB audio coming in, and what it does on its DAC. On Windows, I checked the Cayin ASIO driver to show the correct sample rate, while on Linux I checked the alsa hardware parameters to show the correct sample rate and expected bit depth.

Correct sample rate and bit depth are not proof of bit perfect. Of course that's necessary, but it's not enough.

Guess what: As far as it can be ”proven“ by MQA detection and unfolding happening in the N6ii, EVERYTHING IS BIT-PERCECT.

The results as per the N6ii display do all make sense. This holds for Tidal under Windows, where the Tidal App does the first unfold, as well as for Roon on Windows, where I can set Roon to do the first unfold or leave all unfolding to the N6ii DAC. foobar2000 on Windows and MPD/Cantata on Linux do produce the same results as Roon without first unfold, as is expected in the case of bit-perfect output from the PC USB port.

I don't understand what you are trying to say. Does your Cayin have indication of MQA, and did you get it to work via Linux? You have said a lot about Windows and Roon and Foobar, but I don't see a clear description of the Linux experiment.

As has been said, the premise is that MQA detection in the DAC would imply that all audio bits come out of the USB port in unaltered fashion.

I agree with that. If that's what you verified, this is definitely good info.

I'll do a similar test on my Brooklyn DAC+ but I don't have a good way to connect it from my Linux server right now.

 

[111MilesToGo]

Here‘s a photograph of my experiment with Linux: Cantata controlling MPD, playing an MQA track. The conky monitor shows MPD data as well as alsa hardware parameters in its lower two paragraphs. Up front is the Cayin N6ii, showing MQA Studio detection and unfolding.

 

[gimmeheadroom]

Here‘s a photograph of my experiment with Linux: Cantata controlling MPD, playing an MQA track. The conky monitor shows MPD data as well as alsa hardware parameters in its lower two paragraphs. Up front is the Cayin N6ii, showing MQA Studio detection and unfolding.

Thanks, this is great info. I can't study it all at the moment but you answered my question.

Can you please describe the mpd setup? I'll try to recreate your test over my Brooklyn DAC+ via optical.

 

[tjw321]

FWIW, I've lit up the MQA light on my Meridian Explorer2 DAC from my Raspberry Pi running Linux as well. I'm not using it ATM so I can't recall the exact set up but I do remember that the key was, as @powerhouse64 stated, to go to the correct ALSA device direct. IIRC I had about 4 to choose from with names which didn't directly relate to the DAC so I just went through them in turn until I lit up the MQA light.