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

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post by 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.


View Solution
AlexAdvice
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post by 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).
User avatar
Ross
XCore Expert
Posts: 962
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by 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;
}

------------------------------------------------------------------
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by 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
XCore Addict
Posts: 138
Joined: Sun Feb 23, 2014 11:30 am

Post by AlexAdvice »

infiniteimprobability wrote:
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?
Post Reply