Topic: Dsd audiopath (Read 8712 times)

Rubén · « **on:** September 10, 2015, 02:36:28 pm »

I have been using jriver for several years from version 17, but since dsd mode has been included always there is something extrange for me...my dac can play 64, 128, 256 dsd files in native mode via asio driver, and i have choosen dsd bitstreaming and asio driver, but for example, if i play 64 dsd files although i have choosen dsd bitstreaming for the audiopath, first the screen shows the correct dsd sample rate and 1 second after changes to 352,8 khz and bitperfect icon turns on, my question, is this normal?

Thank you for your support.

Rubén · « **Reply #1 on:** September 12, 2015, 01:07:44 pm »

no one has the same problem?

dtc · « **Reply #2 on:** September 13, 2015, 10:36:39 am »

I do not use direct DSD, just DSD over DoP. My DAC does not accept direct DSD. But, I set MC up to send direct DSD by turning off DoP in the ASIO driver. The DAC just gave noise as expected, but AudioPath showed 5.6 MHz dff with no 352.8KHz. So, I think what your are seeing is not normal. Is Output Format in DSP Studio unchecked, or, if checked, is Output Format set to None and Sample Rate Greater Than 384K set to No Change? Can you try DoP nd see if that works?

Rubén · « **Reply #3 on:** September 13, 2015, 02:17:32 pm »

Please take a look at this screen, as you can see, audiopath is showing DSD Bitsreaming (DSD 2,8 MHz in and out) but alternate display text view shows 352,8 KHz like if DSD 2,8 MHz stream is being converted to PCM 352,8 KHz stream internally and then one more time to DSD 2,8 MHz to feed the DAC ...what is happening?

dtc · « **Reply #4 on:** September 13, 2015, 03:03:03 pm »

So, Audio Path shows the 2.8 MHz bit streaming but the top display shows 352 Khz. For 1XDSD I see the same thing. For 2xDSD, the top display shows 704 KHz, but Audio Path shows 5.6 MHz direct. I think Audio Path is correct and the display shows the PCM value as if it is being converted, but I am not sure. This may be related to some volume option, even though with bit streaming the volume algorithms are bypassed.

If you have a 2X DSD try that and see if it plays correctly. If it does and your DAC does not play 704 then MC is sending the correct DSD native signal.

When I play 1XDSD native I get static even though my DAC plays 352 KHz. So I do not think it is sending 352. Also, if you look at [Bit Depth] in display, it is 1.

All this tells me that the DSD signal is being sent correctly, but the top display is showing the wrong sample rate.

IF someone who knows the details does not respond, you might want to post another comment saying "Playing native DSD displays wrong sample rate" or something like that. This seems like it could be a bug.

blgentry · « **Reply #5 on:** September 13, 2015, 03:43:51 pm »

I'm guessing your DAC doesn't have a display that indicates what kind of digital signal it is receiving? Most don't. I'm asking just in case.

Do Windows ASIO drivers have a status panel of some sort? Something that would show what the DAC is receiving? That would be helpful to see.

Brian.

Rubén · « **Reply #6 on:** September 13, 2015, 03:52:28 pm »

I Have many 2X DSD files and always i have got same result, top display shows 704 KHz, but Audio Path shows 5.6 MHz direct, i have set volume to internal, is it a bug maybe?

Could some one check this and share the results please?

Thank you for your reply Brian, my dac is a Lampizator Level 4 with dsd module, it does not have display, Amanero Asio driver does not have device control panel neither...

dtc · « **Reply #7 on:** September 13, 2015, 04:17:31 pm »

Quote from: blgentry on September 13, 2015, 03:43:51 pm

I'm guessing your DAC doesn't have a display that indicates what kind of digital signal it is receiving? Most don't. I'm asking just in case.

Do Windows ASIO drivers have a status panel of some sort? Something that would show what the DAC is receiving? That would be helpful to see.

Brian.

If 1X DSD were being played at 352 my DAC would play it. It does not. Bit depth is reported as 1. 352/1 makes no sense.

My DAC shows colors depending on the sample rate. For 352KHz it should show purple, but it show red, its default color for 44 KkHz, which simply means it cannot figure out what it is receiving. This is correct, since it does not play native DSD.

I am pretty sure the 352 KHz (or 704 KHz for 2x) in the display is incorrect.

dtc · « **Reply #8 on:** September 13, 2015, 04:30:37 pm »

Quote from: Rubén on September 13, 2015, 03:52:28 pm

... i have set volume to internal ...

I have volume set to disable. It should not matter for bit streaming. I am just wondering if it is reporting the sample rate as if volume was being controlled. The sample rate is not the DoP one, so it might come from the internal volume calculation. I am not sure what else it might be.

Matt · « **Reply #9 on:** September 13, 2015, 05:17:44 pm »

I just checked the audio path when bitstreaming to my Mytek, and it shows DSD 2.8 MHz input, and DSD 2.8 MHz output.

If I'm not bitstreaming, it shows 352.8 kHz as the input. That's also reasonable since it's in PCM at that point.

Rubén · « **Reply #10 on:** September 13, 2015, 05:24:14 pm »

Quote from: Matt on September 13, 2015, 05:17:44 pm

I just checked the audio path when bitstreaming to my Mytek, and it shows DSD 2.8 MHz input, and DSD 2.8 MHz output.

If I'm not bitstreaming, it shows 352.8 kHz as the input. That's also reasonable since it's in PCM at that point.

Can you check the alternate text view?, what is the sample rate that it shows when bitstreaming?

Matt · « **Reply #11 on:** September 13, 2015, 05:26:53 pm »

Quote from: Rubén on September 13, 2015, 05:24:14 pm

Can you check the alternate text view?, what is the sample rate that it shows when bitstraming?

The alternate text does show 352.8 kHz. This is probably because that's what it would become *if* it was converted to PCM.

I agree with you that it's a little strange. It might be an overreach to call it a bug, but I'll at least take a look.

dtc · « **Reply #12 on:** September 13, 2015, 05:32:56 pm »

Quote from: Matt on September 13, 2015, 05:26:53 pm

The alternate text does show 352.8 kHz. This is probably because that's what it would become *if* it was converted to PCM.

I agree with you that it's a little strange. It might be an overreach to call it a bug, but I'll at least take a look.

352K seems pretty high for default 1xDSD conversion. It would normally be either 88 KHz or 176 KHz, depending on one' thinking. And 2X shows as 704KHz.

Seems like a bug. There should be no 352KHz involved.

Matt · « **Reply #13 on:** September 13, 2015, 05:34:52 pm »

Quote from: dtc on September 13, 2015, 05:32:56 pm

352K seems pretty high for default 1xDSD conversion. It would normally be either 88 KHz or 176 KHz, depending on one' thinking. And 2X shows as 704KHz.

Seems like a bug. There should be no 352KHz involved.

The default rate that 1x DSD converts to in PCM is 352KHz.

dtc · « **Reply #14 on:** September 13, 2015, 05:41:44 pm »

Quote from: Matt on September 13, 2015, 05:34:52 pm

The default rate that 1x DSD converts to in PCM is 352KHz.

Seems pretty high, but OK.

dtc · « **Reply #15 on:** September 13, 2015, 09:10:44 pm »

While your looking at this, please also look at the display sample rate for DSD over DoP. It shows the PCM rate, which may be technically what is being sent, but does not reflect the actual audio signal being sent. Audio Path shows correctly that it is 2.8 MHz DSD, but the sample rate in the display is 176 KHz. So, if DSD is being bit streamed, show the actual DSD sample rate and bit depth, rather than the internal rate being used. I think people are really expecting to see the DSD rate the is being bit streamed for both DSD native and DSD Dop, not the internal rates. Thanks.

Rubén · « **Reply #16 on:** September 14, 2015, 06:00:37 am »

Jriverwiki says about Dsd:

"by default, DSD sources will be converted to PCM for playback and handled by the Media Center audio engine like any other file type. The DSD to PCM conversion process converts from 1-bit DSD to 64-bit PCM at 1/8th of the DSD sample rate. The total amount of data from this conversion grows by 8x, so the process is effectively lossless / perfect. Once you have PCM, it will be 64bit @ 352.8 kHz for DSD, and 64bit @ 705.6 kHz for 2×DSD."

I thought that bitstraming bypass MC's audio engine, but seeing sample rate in alternate text mode i have reasonable doubt about it...

Hendrik · « **Reply #17 on:** September 14, 2015, 06:10:15 am »

It shows these sample rates in alternate text because thats what the audio buffer looks like internally. 2.8MHz 1-bit format gets internally stored as a 352,8kHz signal in the audio buffers, because we can't store single bits, we have to store bytes. One byte is 8 bits, and 2.8MHz divided by 8 is 352.8 kHz.
In short, it just describes how the audio buffers look internally, but in the case of bitstreaming, that information isn't exactly giving you an accurate picture.

Its just a different representation, but it doesn't actually convert the audio to PCM when bitstreaming.

Either you trust this information and MC to do the right thing, or I don't know what else to tell you. If the source file is DSD, and your DAC says that its receiving DSD input, then all you have to do is check the CPU usage on your system. Converting from DSD to PCM and then back to DSD would be extremely stressful on the CPU, while bitstreaming uses next to no CPU power.

Additionally you can always check the audio path, it uses more accurate information than the alternate text mode.

dtc · « **Reply #18 on:** September 14, 2015, 06:58:02 am »

Thanks Hendrick, that makes sense from a technical perspective. However, the display of [Sample Rate] should still represent the actual audio data that is being sent, not the internal storage mechanism. It seems like a simple check of whether bit streaming is turned on and if it is DSD then the actual audio sample rate could be displayed, rather than the internal representation. As soon as users see the PCM-like numbers they question the process. I always display [Bit Depth] and [Sample Rate] for anything other than 44/16 and would like to see the correct audio rates shown, not the internal representation. Certainly 352/1 makes little sense for native 1X DSD. Thanks.

Rubén · « **Reply #19 on:** September 14, 2015, 07:16:40 am »

Quote from: dtc on September 14, 2015, 06:58:02 am

Thanks Hendrick, that makes sense from a technical perspective. However, the display of [Sample Rate] should still represent the actual audio data that is being sent, not the internal storage mechanism. It seems like a simple check of whether bit streaming is turned on and if it is DSD then the actual audio sample rate could be displayed, rather than the internal representation. As soon as users see the PCM-like numbers they question the process. I always display [Bit Depth] and [Sample Rate] for anything other than 44/16 and would like to see the correct audio rates shown, not the internal representation. Certainly 352/1 makes little sense for native 1X DSD. Thanks.

I am agree, in fact, there is a "translating" work from one sample rate to another and then once again to DSD for doing the output...so bitstreaming here does not meaning "without touch the data stream"...

Matt · « **Reply #20 on:** September 14, 2015, 07:37:10 am »

For the next build, we'll try this:
Changed: The sample rate of DSD when bitstreaming will be reported more correctly by the player (it was showing the rate it would become if it became PCM).

I'm only about 70% sure that the change is good, so we'll proceed carefully.

dtc · « **Reply #21 on:** September 14, 2015, 07:56:21 am »

Quote from: Rubén on September 14, 2015, 07:16:40 am

I am agree, in fact, there is a "translating" work from one sample rate to another and then once again to DSD for doing the output...so bitstreaming here does not meaning "without touch the data stream"...

Hendrick's description does not say that the data is being changed. It is just a programming method to store the DSD data. No bits are changed. Basically, a byte contains 8 bits (a 1 or 0). A byte is a standard way to store data in a computer, whereas a bit is not. Therefore, for efficiency, they pack 8 bits into a byte internally. But, what comes out is simply the same stream of bits that went in. The data that is sent out is exactly what is in file. Not changes are being made.

If the DSD sample is 1 0 1 0 1 0 1 0, MC simple stores those bits in a byte as 10101010 and then that gets sent out as 1 0 1 0 1 0 1 0. No change is being made. They are just using the byte to store 8 of the 1's and 0's. The 352 K is just the number of bytes rather than the number of bits (2.8M) that are used to store a second of audio - 2.8M/8 = 352K.

What I am saying is that storing the data is bytes versus bits is an internal programming methodology and should not be used as a basis to display the sample rate.

dtc · « **Reply #22 on:** September 14, 2015, 08:01:20 am »

Quote from: Matt on September 14, 2015, 07:37:10 am

For the next build, we'll try this:
Changed: The sample rate of DSD when bitstreaming will be reported more correctly by the player (it was showing the rate it would become if it became PCM).

I'm only about 70% sure that the change is good, so we'll proceed carefully.

Thanks. Appreciate the effort.

What are you concerned about? From what I can see this should only effect the display. It seems the tags and other internal processing should be unchanged.

Note that Hendrick's description of why 352K seems a little different than yours. Maybe they are both correct?

blgentry · « **Reply #23 on:** September 14, 2015, 08:49:48 am »

Regarding the bits versus bytes storage and representation of DSD data:

A. This is just a way of describing how the bits are being transported. It's like having 16 apples you need to transport. You can put 8 apples in each cart, or you can put one apple in each cart. When you put one apple in each cart, you have to use 16 carts to move your apples around. When you put 8 apples in each cart, you get to only use 2 carts. The apples are unchanged. All the apples get there without being mashed or blended or cooked. Same apples. Two different ways of packing them for transport. The bits in a DSD stream are the same. We just call the carts "bytes", and the apples, "bits".

B. I do agree that displaying the byte representation (352 kHz), is confusing, since most people will assume that means PCM in some way, even when it is NOT. The change in display is a smart decision. I hope the change goes well.

Brian.

Rubén · « **Reply #24 on:** September 14, 2015, 11:15:56 am »

Quote from: Matt on September 14, 2015, 07:37:10 am

For the next build, we'll try this:
Changed: The sample rate of DSD when bitstreaming will be reported more correctly by the player (it was showing the rate it would become if it became PCM).

I'm only about 70% sure that the change is good, so we'll proceed carefully.

This change will be welcome, this way misunderstandings will be avoided, thank you for consider my comment.

INTERACT FORUM

Author Topic: Dsd audiopath (Read 8712 times)