[111MilesToGo]

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.

Of course, this is my mpd setup in mpd.conf:

############################################################################
### begin of mpd configuration file
### created by `mpd-configure' (version 0.9.5) on 2018-02-21T11:17:54+01:00.
### see: Ronald van Engelen, https://github.com/ronalde/mpd-configure/
############################################################################
### This is the mpd configuration in a per-user setup.
### Local configuration stored in ~/.config/mpd (all files)
###
### Autostart of mpd with systemd, running the user unit (NO sudo priv's!):
### systemctl enable --user mpd.service
###
### Devices: Chord Hugo 2, miniDSP USB Streamer B,
### Cayin N6ii, Cayin RU6, AudioQuest DragonFly Red, Internal Sound Cards
##
### Hugo 2 DSD only via DoP, Linux quirks.c w/o native DSD patch for Chord.
### Dito Cayin N6ii and RU6
###
### Cayin RU6 PCM enforced to be 24-bit, since bit depth changes
### from track to track are hit-or-miss. Requires specifying DSD, too
###
### Resampling is applied by mpd only to DragonFly,
### but doesn't adhere to the 44.1/48k ladders yet (feature request to mpd)
###
############################################################################

## start processing `01_output-audio-alsa.conf'

#### Chord Hugo 2
audio_output {
    type                "alsa"
    name                "Chord Hugo2 - USB Audio"
##    device              "hw:2,0"
    device              "hw:CARD=Hugo2,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
    dop                 "yes"
    replay_gain_handler "none"
    mixer_type          "none"
}
#### end of Chord Hugo 2

#### miniDSP USB Streamer B (optical input to Hugo 2)
audio_output {
    type                "alsa"
    name                "miniDSP USB-to-Optical - USB Audio"
##    device              "hw:2,0"
    device              "hw:CARD=USBStreamer,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
    dop                 "yes"
    replay_gain_handler "none"
    mixer_type          "none"
}
#### end of miniDSP USB Streamer B

#### Cayin N6ii
audio_output {
    type                "alsa"
    name                "Cayin N6ii - USB Audio"
##    device              "hw:2,0"
    device              "hw:CARD=MK2,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
    dop                 "yes"
    replay_gain_handler "none"
    mixer_type          "none"
}
#### end of Cayin N6ii

#### Cayin RU6
audio_output {
    type                "alsa"
    name                "Cayin RU6 - USB Audio"
##    device              "hw:2,0"
    device              "hw:CARD=RU6,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
##    format              "*:24:*"
    allowed_formats     "*:24:* dsd64:*=dop dsd128:*=dop"
    dop                 "yes"
    replay_gain_handler "none"
    mixer_type          "none"
}
#### end of Cayin RU6

#### AudioQuest DragonFly Red
audio_output {
    type                "alsa"
    name                "AudioQuest Dragonfly Red - USB Audio"
##    device              "hw:2,0"
    device              "hw:CARD=v10,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
    dop                 "no"
    replay_gain_handler "none"
    mixer_type          "none"
}
#### end of AudioQuest DragonFly Red

#### Internal Sound Card - HP 8570w
audio_output {
    type                "alsa"
    name                "Internal Sound Card - HP 8570w"
##    device              "hw:0,0"
    device              "hw:CARD=PCH,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
    dop                 "no"
    replay_gain_handler "none"
    mixer_type          "none"
}
#### end of Internal Sound Card - HP 8570w

#### general settings for all output devices
resampler {
    plugin              "libsamplerate"
    type                "0"
}
replaygain                  "off"

## done processing

## start additional settings

#### input plugins
input {
    plugin              "qobuz"
    enabled             "no"
}
input {
    plugin              "tidal"
    enabled             "no"
}

## done additional

## start processing `02_paths.conf'
music_directory        "~/AVs/I/Music"
db_file                "~/.config/mpd/database"
log_file               "~/.config/mpd/mpd.log"
playlist_directory     "~/.config/mpd/playlists"
pid_file               "~/.config/mpd/pid"
state_file             "~/.config/mpd/state"
sticker_file           "~/.config/mpd/sticker.sql"
save_absolute_paths_in_playlists  "no"
## done processing

## start processing `03_general.conf'
filesystem_charset     "UTF-8"
## id3v1_encoding         "UTF-8"
log_level              "default"
## log_level              "verbose"
auto_update            "yes"
auto_update_depth      "4096"
## done processing

## start processing `04_client-limits.conf'
connection_timeout     "60"
max_connections        "10"
max_playlist_length    "16384"
max_command_list_size  "2048"
max_output_buffer_size "8192"
## done processing

## start processing `05_network.conf'
bind_to_address        "0.0.0.0"
## done processing

## start processing `06_zeroconf.conf'
zeroconf_enabled       "yes"
## done processing

############################################################################
### end of mpd configuration file
############################################################################

As mentioned at the beginning, I had built my mpd config originally by running a script by Ronald van Engelen. His - defunct - website taught me how to get up and running with audio under Linux. Remnants of his website can be found on github, and the old lacocina.nl site can be accessed via the wayback machine.

mpd is set up in a per-user configuration, cf. the respective comment.

I have a number of DACs, as specified in the above file. The Hugo 2 can be fed via USB directly from my computer, which is specified in the "Hugo 2" section. It can also be fed via optical, for which I use a little USB-to-optical converter by miniDSP between computer and Hugo 2.

I hope that helps.

I am using two Linux operating systems, openSUSE Tumbleweed and Manjaro. The mpd/Cantata system with the a.m. configuration works extremely reliably on both. Cantata's setup is no wizardry at all, as Cantata just controls mpd; setting up Cantata is a matter of personal preferences regarding the library display a.o. When listening, Cantata allows to easily switch between the various (alsa) output devices. There is a big advantage as compared to foobar2000: An mpd/Cantata playlist can arbitrarily mix PCM and DSD tracks, since mpd.conf specifies in one place how these types shall be handled. In foobar2000. switching to PCM to DSD unfortunately is a two-step manual process.

 

[gimmeheadroom]

############################################################################
### end of mpd configuration file
############################################################################

Thanks a lot, I have been too lazy to set up mpd on my FreeBSD box but I really should. Thanks for the links and info!

An mpd/Cantata playlist can arbitrarily mix PCM and DSD tracks, since mpd.conf specifies in one place how these types shall be handled. In foobar2000. switching to PCM to DSD unfortunately is a two-step manual process.

This is an interesting comment. I don't use playlists but I don't understand why foobar can't play any time of audio in a playlist. I set the ASIO DSD driver and all formats including PCM plays fine. Is there something else? Or maybe foobar's playlist support is broken somehow?

 

[111MilesToGo]

Thanks a lot, I have been too lazy to set up mpd on my FreeBSD box but I really should. Thanks for the links and info!


This is an interesting comment. I don't use playlists but I don't understand why foobar can't play any time of audio in a playlist. I set the ASIO DSD driver and all formats including PCM plays fine. Is there something else? Or maybe foobar's playlist support is broken somehow?

Off-topic, but nevertheless. Regarding foobar2000 under Windows: To me, the output selection is not as straightforward as it should be. Maybe that's me only. Let's say I have a couple of PCM albums and some DSD albums in my playlist (which actually is the dafault list = standard window), and let's say they appear in an arbitrary order, i.e. foobar2000 has to switch between PCM/DSD types.

What I have to do is: When playing PCM, I select one of my ASIO drivers, as required by the device in use, e.g. the Hugo 2 or the Cayin N6ii or the RU6. That is a one-click process, as the Output Preference is in the selction box at the top. However, before going to play a DSD track as native DSD, I have to select the "DSD Transcoder (DoP/Native)" as the output device, and I have to select the actual ASIO driver as the targeted output of this transcoder. The latter is a multiple-click process, kind of a nuisance - Preferences -> Playback -> Output -> ASIO. The reason behind that is that the famous SACD plugin provides DoP audio data only, and the "DSD Transcoder (DoP/Native)" has to be used as the output in order to recover the native DSD stream from the DoP stream, which by the way of course is bit perfect since DoP is a fake-PCM wrapper around the native DSD.

The attached screenshots show these: (1) PCM playback; (2) switching the outputs for DSD; (3) DSD playback.

Remark: My foobar2000 setup is built along the directions given on the "diyaudioheaven" website, where Part 1 has the basics and Part 2 teaches DSD replay. Maybe things could be done in an easier fashion.

But I guess off-topic should end here ...

 

[111MilesToGo]

Thanks a lot, I have been too lazy to set up mpd on my FreeBSD box but I really should. Thanks for the links and info!

You are very welcome. Please feel free to ask here or in a PM in case I could be of further help.

EDIT: There are a number of GUI controllers for mpd. Cantata just did and still does fit my personal preferences best, even though it is out of active development afaik.

 

[gimmeheadroom]

Off-topic, but nevertheless. Regarding foobar2000 under Windows: To me, the output selection is not as straightforward as it should be. Maybe that's me only. Let's say I have a couple of PCM albums and some DSD albums in my playlist (which actually is the dafault list = standard window), and let's say they appear in an arbitrary order, i.e. foobar2000 has to switch between PCM/DSD types.

What I have to do is: When playing PCM, I select one of my ASIO drivers, as required by the device in use, e.g. the Hugo 2 or the Cayin N6ii or the RU6. That is a one-click process, as the Output Preference is in the selction box at the top. However, before going to play a DSD track as native DSD, I have to select the "DSD Transcoder (DoP/Native)" as the output device, and I have to select the actual ASIO driver as the targeted output of this transcoder. The latter is a multiple-click process, kind of a nuisance - Preferences -> Playback -> Output -> ASIO. The reason behind that is that the famous SACD plugin provides DoP audio data only, and the "DSD Transcoder (DoP/Native)" has to be used as the output in order to recover the native DSD stream from the DoP stream, which by the way of course is bit perfect since DoP is a fake-PCM wrapper around the native DSD.

Some of my DACs support DoP even at high rates (256) others only until 128. Only this week I started using the transcoder proxy so I can't remember if I had any issues to play PCM with it enabled. I'll check later.

And, I don't use playlists. But it seems to me I can play any kind of file without changing anything. I agree, if you want to select a specific device it's annoying but I guess not more than other players. And I didn't see any good SACD ISO player for Linux at all.

Anyway, I solved the device selection problem to some extent by using a DDC as the main output and not changing it. From there I can go to various devices: reclocker, DACs, format converter/switch to digital recorders etc.

The attached screenshots show these: (1) PCM playback; (2) switching the outputs for DSD; (3) DSD playback.

I think you can playback PCM without changing anything in the DSD setup, can't you?

Remark: My foobar2000 setup is built along the directions given on the "diyaudioheaven" website, where Part 1 has the basics and Part 2 teaches DSD replay. Maybe things could be done in an easier fashion.

But I guess off-topic should end here ...

We can talk about it here https://www.head-fi.org/threads/the...ad-got-problems-or-questions-ask-here.624628/

 

[BaTou069]

MQA is the only test I'm aware of for bitperfect audio

Hey, isn't it you that chimed into my thread about converting flacs on linux and told me how linux was not built for sound, has way more layers of crap in the chain and whatnot?
1. Why do you think bitperfect is the holy grail? 2) Why do you think that MQA is a viable test for bitperfect? 3) Why do you even think that MQA is bitperfect?
I recommend you check out this post about MQA and think again.

The advantage of Linux VS Mac/Win is that you can directly communicate with ANY hardware. No need for drivers. Of course Linux was never built for audio, you're right, exactly like mac or windows weren't build for audio as well. I don't know how old you are but I can still remember the sound of the early computers end 80s early 90s: AdLib, Creative Labs Sound Blaster (8bit/44.1), Roland LAPC-I... Sound was always an afterthought so who cares if Linux wasn't built for audio playback? Even if there are 10 processes/layers the sounds has to go through, it doesn't matter. The 1s and 0s will arrive at the DAC and you won't hear a difference

 

[111MilesToGo]

1. Why do you think bitperfect is the holy grail? 2) Why do you think that MQA is a viable test for bitperfect? 3) Why do you even think that MQA is bitperfect?

I‘ll try to provide answers.

1. The capability to provide a bit-perfect reproduction of a digitized recording is a basic requirement. Bit errors shouldn‘t be tolerated. Of course, any (digital) sound processing like EQ’ing results in (bit-wise) deviations from the original - on purpose.

2. The jury still is out on whether using an MQA track is a viable test for bit-perfect reproduction. That is due to the fact that MQA is proprietary, we don’t know precisely what it does. In fact, HDCD would definitely provide a viable test, since control and data sequences are encoded in the least significant bit - tampering with the bits kills HDCD.

3. No, the term bit-perfect does not refer to MQA itself. Bit-perfect refers to output versus input in any digital audio reproduction system - a must as explained above. What you mean is ”lossy“. Yes, MQA is a lossy way of encoding higher sample rates and bit depths (not sure about the latter) into 24/44.1 or 24/48.

Hope to have clarified matters a bit.

 

[tjw321]

... 2) Why do you think that MQA is a viable test for bitperfect? ...

...
3. No, the term bit-perfect does not refer to MQA itself. Bit-perfect refers to output versus input in any digital audio reproduction system - a must as explained above. What you mean is ”lossy“. Yes, MQA is a lossy way of encoding higher sample rates and bit depths (not sure about the latter) into 24/44.1 or 24/48.
...

Ironically, it's the lossy bit (sort of) of MQA that makes it work as a test for bit-perfect. The bits that MQA messes with effectively contain a watermark which identifies the bits as MQA encoded bits (that's the "authentication", which is the A of MQA). If you do anything to that watermark, the MQA light on your DAC goes out.

 

[111MilesToGo]

Ironically, it's the lossy bit (sort of) of MQA that makes it work as a test for bit-perfect. The bits that MQA messes with effectively contain a watermark which identifies the bits as MQA encoded bits (that's the "authentication", which is the A of MQA). If you do anything to that watermark, the MQA light on your DAC goes out.

Yeah, similar to HDCD, which operates from the least significant bit, putting control codes and data therein. These give the prescription how to recalculate the other bits of the 16/44.1 data stream during (actually before) digital-to-analog conversion in order to get the original 20/44.1 audio stream back. Tampering with the least significant bit kills HDCD, i.e. the HDCD light on the DAC goes out. Actually, I figure the least significant bit in HDCD is sacrificed during the process; audio that was there originally isn‘t recoverable.

 

[BaTou069]

I‘ll try to provide answers.

1. The capability to provide a bit-perfect reproduction of a digitized recording is a basic requirement. Bit errors shouldn‘t be tolerated. Of course, any (digital) sound processing like EQ’ing results in (bit-wise) deviations from the original - on purpose.

2. The jury still is out on whether using an MQA track is a viable test for bit-perfect reproduction. That is due to the fact that MQA is proprietary, we don’t know precisely what it does. In fact, HDCD would definitely provide a viable test, since control and data sequences are encoded in the least significant bit - tampering with the bits kills HDCD.

3. No, the term bit-perfect does not refer to MQA itself. Bit-perfect refers to output versus input in any digital audio reproduction system - a must as explained above. What you mean is ”lossy“. Yes, MQA is a lossy way of encoding higher sample rates and bit depths (not sure about the latter) into 24/44.1 or 24/48.

Hope to have clarified matters a bit.

1. Can you define biterrors? Are those a real concern happening?
2. As you wrote, MQA is proprietary, nobody knows what it does, so how can this please become THE VIABLE TEST for bit-perfect audio reproduction? You understand how this makes no sense?

Ironically, it's the lossy bit (sort of) of MQA that makes it work as a test for bit-perfect. The bits that MQA messes with effectively contain a watermark which identifies the bits as MQA encoded bits (that's the "authentication", which is the A of MQA). If you do anything to that watermark, the MQA light on your DAC goes out.

Its nothing special to take a signal of lets say 24/96, to downsample it to 14bit/20khz, and then to upsample it back to 24/96. Yes, your DAC will shows 24/96, but is that bitperfect? I think this whole MQA discussion makes no sense, just check out goldenears headfi thread, youtube video, you name it. Many people showed how you can play non MQA files and still get that soothing light - MQA if anything degrades the sound and certainly is by no means a reference for bitperfect playback OMG

Yeah, similar to HDCD, which operates from the least significant bit, putting control codes and data therein. These give the prescription how to recalculate the other bits of the 16/44.1 data stream during (actually before) digital-to-analog conversion in order to get the original 20/44.1 audio stream back. Tampering with the least significant bit kills HDCD, i.e. the HDCD light on the DAC goes out. Actually, I figure the least significant bit in HDCD is sacrificed during the process; audio that was there originally isn‘t recoverable.

ive never heard if hdcd before but a hydrogen audio wiki post says its a scam



My main points were about these claims:

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.

Like this is somehow different with mac or win, it wasnt designed for audio, much less for bitperfect, its a general purpose OS and the default setup is certainly not bitperfect. All true for mac and windows... with the only difference that with linux you directly communicate with hardware, IO, Kernel. Not sure why using a driver from a manufacturer due to windows incompatibility to just exchange bits with hardware is better in your eyes

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.

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.

1. What would be a proof of bit perfect audio? dont even start with mqa
2. again, false. MQA is not bitperfect. Im amazed how someone with so many unix based computers in his home, someone who breathes and lives open source, can say that some stupid blue light that some company charges for with proprietary technology without any transparence into what they actually do & if its legit at all, making all those crazy claims and charging royalties from anyone from hardware manufacturers to streaming companies to US (mfr pays more > equipment more expensive)

WE, People who love music, sound, equipment, open source and the ability to tinker around and to optimize it, WE and all of headfi, Audiosciencereview, superaudiofriends, hydrogeneaudio, diyaudio and more, all of those should stand up and rise against such insanity. We are creating the demand for this BS and we have the power to stop it. Enough artists that pulled music from tidal or manufacturers that voiced their opinions but only implement MQA because of US, because the demand is there and audio device manufacturers after all are companies with the goal to provide value and revenue.

 

[tjw321]

1. Can you define biterrors? Are those a real concern happening?
2. As you wrote, MQA is proprietary, nobody knows what it does, so how can this please become THE VIABLE TEST for bit-perfect audio reproduction? You understand how this makes no sense?



Its nothing special to take a signal of lets say 24/96, to downsample it to 14bit/20khz, and then to upsample it back to 24/96. Yes, your DAC will shows 24/96, but is that bitperfect? I think this whole MQA discussion makes no sense, just check out goldenears headfi thread, youtube video, you name it. Many people showed how you can play non MQA files and still get that soothing light - MQA if anything degrades the sound and certainly is by no means a reference for bitperfect playback OMG



ive never heard if hdcd before but a hydrogen audio wiki post says its a scam



My main points were about these claims:

Like this is somehow different with mac or win, it wasnt designed for audio, much less for bitperfect, its a general purpose OS and the default setup is certainly not bitperfect. All true for mac and windows... with the only difference that with linux you directly communicate with hardware, IO, Kernel. Not sure why using a driver from a manufacturer due to windows incompatibility to just exchange bits with hardware is better in your eyes

1. What would be a proof of bit perfect audio? dont even start with mqa
2. again, false. MQA is not bitperfect. Im amazed how someone with so many unix based computers in his home, someone who breathes and lives open source, can say that some stupid blue light that some company charges for with proprietary technology without any transparence into what they actually do & if its legit at all, making all those crazy claims and charging royalties from anyone from hardware manufacturers to streaming companies to US (mfr pays more > equipment more expensive)

WE, People who love music, sound, equipment, open source and the ability to tinker around and to optimize it, WE and all of headfi, Audiosciencereview, superaudiofriends, hydrogeneaudio, diyaudio and more, all of those should stand up and rise against such insanity. We are creating the demand for this BS and we have the power to stop it. Enough artists that pulled music from tidal or manufacturers that voiced their opinions but only implement MQA because of US, because the demand is there and audio device manufacturers after all are companies with the goal to provide value and revenue.

I think you are missing the point. Nobody has said that MQA is good, nobody has said that MQA is bitperfect, nobody has offered any support or desire for MQA. We are simply taking advantage of the fact that it is very hard to persuade an MQA DAC to indicate that a stream is MQA unless the stream contains the bits that it started with at the time the fie was created - i.e. that the stream is bitperfect. In my case I don't use tidal or MQA. That doesn't mean that I can't take advantage of it to do a simple test.

 

[gimmeheadroom]

I think you are missing the point. Nobody has said that MQA is good, nobody has said that MQA is bitperfect, nobody has offered any support or desire for MQA. We are simply taking advantage of the fact that it is very hard to persuade an MQA DAC to indicate that a stream is MQA unless the stream contains the bits that it started with at the time the fie was created - i.e. that the stream is bitperfect. In my case I don't use tidal or MQA. That doesn't mean that I can't take advantage of it to do a simple test.

Well I think MQA sounds good, but true enough, that doesn't mean it is good

 

[BaTou069]

I think you are missing the point. Nobody has said that MQA is good, nobody has said that MQA is bitperfect, nobody has offered any support or desire for MQA. We are simply taking advantage of the fact that it is very hard to persuade an MQA DAC to indicate that a stream is MQA unless the stream contains the bits that it started with at the time the fie was created - i.e. that the stream is bitperfect. In my case I don't use tidal or MQA. That doesn't mean that I can't take advantage of it to do a simple test.

I honestly don't think that i missed a point, it's very easy to persuade a MQA DAC to indicate a stream is MQA.
How will the DAC know what was in the file at the time it was created? Did MQA upload a database of all MQA encoded files into those DACs?

I'm intrigued about your simple test please tell me more


So nobody has said that MQA is bit perfect?

This is all good info, but the proof of bit perfect audio is that a DAC can decode MQA

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

If MQA isn't bit perfect, how is it then the best test for bit perfect we have? Easy, it's neither bit perfect nor the best test for bit perfect.

You know what is?

Looking into hw_params (check first your dacs name)

/proc/asound/card1/pcm0p/sub0/hw_params

format: S24_3LE indicates 24-bit, rate is sampling rate (sent to DAC)
The stream0 file shows the supported sample rates of your DAC

Then if your DAC supports showing what it plays, check there again. Voila.


This thread clearly is about playing bit perfect on linux. Its not about MQA.
Telling Linux users, people who clearly value open source, that some blue LED light provided by some secretive organization that charges royalties for a proprietary technology that nobody can even validate works or how it work, nobody really knows why or when its turned on, besides what marketing tells you... telling those users that this blue LED should be a proof for anything besides that the DAC gets current is crazy.

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!

 

[BaTou069]

Well I think MQA sounds good, but true enough, that doesn't mean it is good

You're right, people love tube sound that has many distortions, people me including like the Cayin RU6 R2R dac even tho it measures worse than 20y old equipment, and then there is equipment that measures excellently but many people don't like the sound.

To me it's not about being objective VS subjective, it's more about a middle ground. I do expect from gear like DACs for example to measure well with 16/44.1 & I don't really care for improvements beyond the audible threshold.

Is a measurable difference an audible difference? Will you not enjoy your DSD files because playback is PCM? Will you suffer using PulseAudio?

I don't think so

 

[tjw321]

I honestly don't think that i missed a point, it's very easy to persuade a MQA DAC to indicate a stream is MQA.
How will the DAC know what was in the file at the time it was created? Did MQA upload a database of all MQA encoded files into those DACs?

I'm intrigued about your simple test please tell me more


So nobody has said that MQA is bit perfect?



If MQA isn't bit perfect, how is it then the best test for bit perfect we have? Easy, it's neither bit perfect nor the best test for bit perfect.

You know what is?

Looking into hw_params (check first your dacs name)

/proc/asound/card1/pcm0p/sub0/hw_params

format: S24_3LE indicates 24-bit, rate is sampling rate (sent to DAC)
The stream0 file shows the supported sample rates of your DAC

Then if your DAC supports showing what it plays, check there again. Voila.


This thread clearly is about playing bit perfect on linux. Its not about MQA.
Telling Linux users, people who clearly value open source, that some blue LED light provided by some secretive organization that charges royalties for a proprietary technology that nobody can even validate works or how it work, nobody really knows why or when its turned on, besides what marketing tells you... telling those users that this blue LED should be a proof for anything besides that the DAC gets current is crazy.

"This is all good info, but the proof of bit perfect audio is that a DAC can decode MQA" does not say that MQA is bit perfect, just that it can be used as proof that the MQA bits haven't been altered (but...). I read that thread and it is correct to say that it isn't actually proof - however it is still hard to get that light to illuminate without bit-perfection, or a perl script, or a specific type of truncation, so it's still a valid test (but not proof).
The DAC doesn't need a database of MQA encoded files - it uses something like a checksum, similarly to how packets on a network are verified without knowing what the contents are in advance. (So again not proof, but reasonably unlikely to be incorrect)
It is the best test in some senses (easy to do, easy to get a result) - but again, I agree it is not proof that you are bit perfect - but you can probably trust a negative result (e.g. no light, not bit-perfect, light possibly bit-perfect).
So it is a useful test, but not proof.
But I'm happy to accept that any statements about MQA should be treated with a healthy degree of scepticism and that this "proof" of bit-perfection in Linux isn't really necessary. But if it's possible to do (it is), and it helps someone feel more comfortable using Linux for audio....why not?
(and that is it from me... I don't actually disagree with you, other than I do think that there is some merit in this test - whether there is merit in MQA itself or not I leave up to individuals to decide for themselves)