Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[HTPC Videophile]

In linux version the 24 bit audio source is displayed  as 32 bit whereas in windows version it displays correctly as 24 bit depth

[Awesome Donkey]

MC will automatically pad playing audio to the max bit-depth your DAC supports on-the-fly by adding zeros (it's not doing any sort of dithering). I suppose it could depend on drivers on stuff, but for me with the various DACs I've used the max has always been 32-bit on both Windows and Linux (and macOS in the past).

[HTPC Videophile]

MC will automatically pad playing audio to the max bit-depth your DAC supports on-the-fly by adding zeros (it's not doing any sort of dithering). I suppose it could depend on drivers on stuff, but for me with the various DACs I've used the max has always been 32-bit on both Windows and Linux (and macOS in the past).

I 'm referring to the input not the output of audio path pop-up message. The input should  display this: 48 kHz 24 bit 6ch from Source format truhd for the above example(highlighted in Standard view). Please note for 16bit audio depth , it correctly reports as 16 bit.

[HTPC Videophile]

No Solution ?? Am i wrong in my assumption that for the Input path in Audio Path ,the info should report the actual property(i.e. actal unpadded bit depth of the audio as in Windows System) ?

[bob]

No Solution ?? Am i wrong in my assumption that for the Input path in Audio Path ,the info should report the actual property(i.e. actal unpadded bit depth of the audio as in Windows System) ?

You could look in the log. I'd guess it probably has to go through libav on linux, maybe not on windows.

[pkfeldman]

I have the same concern. When sourcing from the Id, I would much prefer to see the real bit depth of the input source file on my DAC’s display, not 32 bits (the max of my DAC, a Mytek Brooklyn DAC+). Then I would know if it’s a 16-bit or 24-bit input file. If I feed the DAC from Windows JRiver, it does show the correct bit depth.

Also I’m not an expert but intuitively it seems it can’t possibly add any value to pad 8 or 16 zeroes in each sample, and that might detract from sound quality.

In a future upgrade to Linux JRiver (for use on the Id), please consider changing the auto-pad approach. Thank you.

[bob]

I have the same concern. When sourcing from the Id, I would much prefer to see the real bit depth of the input source file on my DAC’s display, not 32 bits (the max of my DAC, a Mytek Brooklyn DAC+). Then I would know if it’s a 16-bit or 24-bit input file. If I feed the DAC from Windows JRiver, it does show the correct bit depth.

Also I’m not an expert but intuitively it seems it can’t possibly add any value to pad 8 or 16 zeroes in each sample, and that might detract from sound quality.

In a future upgrade to Linux JRiver (for use on the Id), please consider changing the auto-pad approach. Thank you.

The ALSA drivers only support certain formats for each device. If you run
/usr/lib/jriver/MCxx/alsacap
or on the Id choose the audio device option 10 from the test menu
with MC not playing a track, at the bottom of each device entry you'll see the supported formats.
Most common is S32_LE and by default the output format is set to Automatic in MC's audio device settings the highest supported format will be the output format used. You can select a specific output format if your device supports more than one or a different one all together. For example a USB dragonfly DAC only supports S24_3LE

[pkfeldman]

I tried a few of those PCM formats but they all resulted in an error popup on the Id.

I jump between hi-res PCM and DSD which I play natively on the Brooklyn, so even if I found an off-Auto PCM setting that worked, would that conflict with occasional native DSD playback? Would I have to switch to Auto every time I felt like listening to DSD, or would there be no impact?

At any rate I would rather keep that setting on Auto if possible, but just send the file as is into the DAC without any bit padding. It seems like a reasonable thing to keep in the user’s control. Why can’t I have that option?

[JimH]

Also I’m not an expert but intuitively it seems it can’t possibly add any value to pad 8 or 16 zeroes in each sample, and that might detract from sound quality.

It is if that's what the device requires.

[Awesome Donkey]

This post explains the bit-depth padding more: https://yabb.jriver.com/interact/index.php/topic,104255.msg724769.html#msg724769

[bob]

This post explains the bit-depth padding more: https://yabb.jriver.com/interact/index.php/topic,104255.msg724769.html#msg724769

That's a good explanation.
At any rate you can see the supported formats as I told you, On the Id through function 10. No need to hunt and peck through them.

There is only one supported DSD format in linux MC which is why you don't have to choose one. Either the device supports it (as far as I can tell this has been standardized on linux) or it doesn't. The format will show up in the function 10 I mentioned above. It's DSD_U32_BE. If that's there, DSD will work natively. If it isn't it won't.

[pkfeldman]

Thank you for the follow up. I don’t have DSD_U32_BE listed. Option 10 points “USB Audio” to the Brooklyn DAC+, an option not listed in JRemote or JRiver MC. There is “usbstream” but I’ve been running with Player set to hw:CARD=DAC,DEV=0.

I think this is all I can do. I’m going to stay with the “Auto (recommended)” setting.

I understand there are benefits to sending the maximum bit depth the dac can handle, but it would be more useful information to me to see the real bit depth on the Brooklyn’s display.

[bob]

Thank you for the follow up. I don’t have DSD_U32_BE listed. Option 10 points “USB Audio” to the Brooklyn DAC+, an option not listed in JRemote or JRiver MC. There is “usbstream” but I’ve been running with Player set to hw:CARD=DAC,DEV=0.

I think this is all I can do. I’m going to stay with the “Auto (recommended)” setting.

I understand there are benefits to sending the maximum bit depth the dac can handle, but it would be more useful information to me to see the real bit depth on the Brooklyn’s display.

The option 10 names don't exactly correspond to the device selection in MC, the info in each is there, in a different order. In function 10 card ID is first and the name follows [ALSA]. The MC device selection is based on what the system offers as suggested devices and there are several possibilities for each device in function 10. hw: or front: without conversion are the direct devices.
Just out of curiosity, what formats does your DAC says it's supports in function 10?

[pkfeldman]

In the MC UI, the options under Auto (recommended) are: S32_LE, S24_3LE, S24_LE, S16_LE, FLOAT_LE, FLOAT64_LE.

When I choose Option 10, the results fly by and I don’t see the “hw” option that I use in practice. I do see “USB Audio” listing the Brooklyn DAC+, and that line lists: S16_LE, S32_LE, and IEC958_SUBFRAME_LE. But as I noted earlier, I don’t see “USB Audio” in the options under “Link” in JRemote - Player.

[bob]

In the MC UI, the options under Auto (recommended) are: S32_LE, S24_3LE, S24_LE, S16_LE, FLOAT_LE, FLOAT64_LE.

When I choose Option 10, the results fly by and I don’t see the “hw” option that I use in practice. I do see “USB Audio” listing the Brooklyn DAC+, and that line lists: S16_LE, S32_LE, and IEC958_SUBFRAME_LE. But as I noted earlier, I don’t see “USB Audio” in the options under “Link” in JRemote - Player.

You can expand the window to see more of the info.
So basically your DAC supports 32 bit and 16 bit native formats on linux at any rate.
Those are the formats the ALSA driver is saying that the device supports.
We can't send it any format other than those. The ALSA driver will refuse to open the device if we do.