Porting USB Audio 2.0 to XU208 - problem with DSD Topic is solved

[AlexAdvice]

We use C5 in TQFP-48, Farnell says - July 2017, Digikey say August 2017.
We also use L8 instead, but in any case want to move to XU(F)208.

BTW, I tried to use #undef __X2A__, and for a 1st view the signals were OK, even at DSD256.
I will check more precisely with DAC connected.

[AlexAdvice]

Checked with the DAC, DSD64-256 works fine.
Thank you for All who helps to solve the problem.


I'm not sure this workaround is the best solution (because not use the features of the new architecture, and 1024Fs MCLK is not possible, also 768kHz and DSD512), but his time it is enough for me.
Hope XMOS team will provide us the better solution, in the next Reference Design revision (or make a patch to the current).

[Ross]

Heya, we've been working on other items and DSD on xCORE-200 hasn't popped up as a priority.

Here are the notes on the internal bug report which should get you going if you haven't managed to fix it using my hint.

The notes are from one of our FAEs in Japan and is unverified, but looking at the code it seems to address the issue I described previously. i.e. comment out some code and change a clock divider.

There are two parts.


================================================================================
[1] Disable BCLK software generation in audio_io.xc:deliver() for DSD playback.
================================================================================

For example...


<Original>----------------------------------------------------
if(dsdMode == DSD_MODE_NATIVE)
{
/* 8 bits per chan, 1st 1-bit sample in MSB */
dsdSample_l = samplesOut[0];
dsdSample_r = samplesOut[1];
dsdSample_r = bitrev(byterev(dsdSample_r));
dsdSample_l = bitrev(byterev(dsdSample_l));

/* Output DSD data to ports then 32 clocks */
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;
----------------------------------------------------------------


<Update>----------------------------------------------------------
if(dsdMode == DSD_MODE_NATIVE)
{
/* 8 bits per chan, 1st 1-bit sample in MSB */
dsdSample_l = samplesOut[0];
dsdSample_r = samplesOut[1];
dsdSample_r = bitrev(byterev(dsdSample_r));
dsdSample_l = bitrev(byterev(dsdSample_l));

#ifdef XS2I2SBCLKHWDIV
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));
#else
/* Output DSD data to ports then 32 clocks */
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;
--------------------------------------------------------------------




================================================================================
[2] Sample rate variable change to have appropriate "divide" variable
================================================================================

In case of DSD64 playback after PCM44.1kHz playback, foobar2000 player does not send new sample rate to USB Device (XMOS). Then in that case, "curSamFreq" variables keeps 44100 and "divide" variable has unexpected value even though "curSamFeq" variable is expected to have 88200 in case of DSD64 playback.

In order to prevent the issue with DSD64 playback after PCM44.1kHz, following code will help to prevent noisy sound with DSD64.


File : audio_io.xc:autio()


<Original-1> -----------------------------------------------------

divide = mClk / ( curSamFreq * numBits);

------------------------------------------------------------------


<Update - 1> -----------------------------------------------------

curSamFreq_xs2 = curSamFreq;

#if (DSD_CHANS_DAC > 0)
if ((dsdMode == DSD_MODE_DOP) || (dsdMode == DSD_MODE_NATIVE))
{
if (curSamFreq == 44100) {
//DSD64 (match with audiohwconfig)
curSamFreq_xs2 = 88200;
}
}
#endif

divide = mClk / ( curSamFreq_xs2 * numBits);


------------------------------------------------------------------





<Original - 2> ---------------------------------------------------

/* Make AudioHwConfig() implementation a little more user friendly in DSD mode...*/
if(dsdMode == DSD_MODE_NATIVE)
{
curFreq *= 32;
}
else if(dsdMode == DSD_MODE_DOP)
{
curFreq *= 16;
}

------------------------------------------------------------------


<Update - 2> -----------------------------------------------------

/* Make AudioHwConfig() implementation a little more user friendly in DSD mode...*/
if(dsdMode == DSD_MODE_NATIVE)
{
curFreq = curSamFreq_xs2 * 32;
}
else if(dsdMode == DSD_MODE_DOP)
{
curFreq = curSamFreq_xs2 * 16;
}

------------------------------------------------------------------

[infiniteimprobability]

1024Fs MCLK is not possible

I thought that was all Ok now!? It should work fine.

http://www.xcore.com/viewtopic.php?t=5776

[AlexAdvice]

1024Fs MCLK is not possible

I thought that was all Ok now!? It should work fine.

http://www.xcore.com/viewtopic.php?t=5776

It woks fine, before I used "#undef __XS2A__" to repair DSD playback.

Of course, it was "brute force" solution.
Now, after Ross was so kind to share his elegant solution, 104Fs MCLK should work anywhere.

Ross, many thanks!
I'll try to implement your solution during the next few days.


BTW, not want to create new topic for small question - do XMOS required MCLK signal, when I2S/TDM is in the slave mode?