DoP 256 Audio in USB 2.0 Audio firmware Topic is solved

[SonnyDK]

Hi, we have DSD native 256 running but we cannot get DoP running higher than DoP128 and we think it is due to differences in the clock section in audio.xc.

It looks like DoP are using a double as high clock as the DSD native in the code. OR have we misunderstand something?

The DSD clock:
switch (divide)
{
case 4:
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[0]),"r"(dsdSample_l));
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[1]),"r"(dsdSample_r));
p_dsd_clk <: 0xCCCCCCCC;
p_dsd_clk <: 0xCCCCCCCC;
p_dsd_clk <: 0xCCCCCCCC;
p_dsd_clk <: 0xCCCCCCCC;
break;

case 2:
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[0]),"r"(dsdSample_l));
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[1]),"r"(dsdSample_r));
p_dsd_clk <: 0xAAAAAAAA;
p_dsd_clk <: 0xAAAAAAAA;
break;

default:
/* Do some clocks anyway - this will stop us interrupting decouple too much */
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[0]),"r"(dsdSample_l));
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[1]),"r"(dsdSample_r));
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
break;
}

And the DoP part.


if(!everyOther)
{
dsdSample_l = ((samplesOut[0] & 0xffff00) << 8);
dsdSample_r = ((samplesOut[1] & 0xffff00) << 8);

everyOther = 1;

switch (divide)
{
case 8:
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
break;

case 4:
p_dsd_clk <: 0xCCCCCCCC;
p_dsd_clk <: 0xCCCCCCCC;
break;

case 2:
p_dsd_clk <: 0xAAAAAAAA;
break;
}
}
else // everyOther
{
everyOther = 0;
dsdSample_l = dsdSample_l | ((samplesOut[0] & 0xffff00) >> 8);
dsdSample_r = dsdSample_r | ((samplesOut[1] & 0xffff00) >> 8);

// Output 16 clocks DSD to all
//p_dsd_dac[0] <: bitrev(dsdSample_l);
//p_dsd_dac[1] <: bitrev(dsdSample_r);
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[0]),"r"(bitrev(dsdSample_l)));
asm volatile("out res[%0], %1"::"r"(p_dsd_dac[1]),"r"(bitrev(dsdSample_r)));
switch (divide)
{
case 8:
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
p_dsd_clk <: 0xF0F0F0F0;
break;

case 4:
p_dsd_clk <: 0xCCCCCCCC;
p_dsd_clk <: 0xCCCCCCCC;
break;

case 2:
p_dsd_clk <: 0xAAAAAAAA;
break;
}

}

[Ross]

DoP uses twice the effective PCM rate than our "native" implementation this is because DoP transferred 16bit of sample data in a 4byte slot (it uses the other bytes for a header) whereas our "native" version uses 32bits for sample data - it can then run at half the effective PCM rate i.e. 88.2 instead of 176.4 for DSD64.

http://dsd-guide.com/dop-open-standard

[SonnyDK]

So that means to be able to run DoP256 we need twice the clock frequency on MCK?

[SonnyDK]

Closed it by accident.

[Ross]

Regardless of transport mechanism DSD64 has a clock speed of 44.1kHz * 64 = 2.8MHz.

When running DSD64 over DoP the DSD data is transferred over USB like it is 16bit PCM audio @ 176.4kHz (16 * 176 = 2.8MHz)

When running DSD64 over XMOS "native DSD" the DSD data is transferred over USB like it is 32bit audio @ 88.2kHz (32 * 88.2 = 2.8MHz)

In both cases the DSD clock (which is what you mean by MCLK i assume) is always 2.8MHz.

The code looks like that because in for DoP this part of the code is essentially getting samples twice at quickly as it needs them, waits for two chucks of DoP 16bit and outputs 32bits. It probably helps timing to do split the clocking up over the two 16 bit samples.