XMOS ADC 768k driver ? Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
Biquad
Member++
Posts: 20
Joined: Wed May 24, 2017 11:38 am

XMOS ADC 768k driver ?

Post by Biquad »

Hello,
i am using the 6.15.2rc1 package. XUF216 in master mode.
MAX_FREQ set to 768000
MCLK_44_1 512 x 44100
MCLK_48 512 x 48000
I like to have the 768k for my AK5572 ADC for this, i have
made an stereo in / out only configuration with the standard
osc values. The ADC accepts 24MHz MCLK for the 768k.
I can't find a proper test driver all drivers i have access too,
are not switching the LRCLK, it reamains at 384k.

Any suggestions or hints ?

Best regards
Andreas


View Solution
User avatar
fabriceo
XCore Addict
Posts: 181
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi Andreas,
for 768k word clock, considering 64bits per word for stereo I2S, you need a 49.152mhz on MCLK, thats it and thats all :)
so you need :
MCLK_44_1 1024 x 44100
MCLK_48 1024 x 48000
unless you plan to work in dual mono and then some rework of the audio task in Audio.xc file is needed ...
Biquad
Member++
Posts: 20
Joined: Wed May 24, 2017 11:38 am

Post by Biquad »

Hi fabriceo,
sorry for my late reply. I have'nt got a notification.
Thanks for the info.
The AK5572 supports only 24.576 Mhz or 36Mhz MCLK at 768k in slave auto mode. Do i have to divide the 49.152MHz xmos
MCLK to feed the ADC ? What about the SCLK.
Best would be 1x Stereo IN / OUT in future.
User avatar
fabriceo
XCore Addict
Posts: 181
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi
in order to get the best ADC quality minimizing jitter and providing optimal sigma-delta precision, I would configure the AK5572 in Master Mode, feed it with an external 49 or 45mhz cristal and configure it to work in 64fs (as per datasheet table 3).
The xmos usb app can be configured with "CODEC_MASTER" parameter to support this.
But then it is not clear in the AK datasheet how the other modes (48..384k) can be generated and you might need an extra 22/24 set of crystals or a clock divider by 2 with a simple mux between the 44/45 crystal and the mux. Careful attention required on added jitter.

You are right that the datasheet also mention the possibility to use 22/24mhz for 768k but in 32fs mode and then it is not clear how this is handled in I2S or TDM, or if the sample is reduced to 16 bits... !

if you have a DAC on the same board you can also feed it with the same LRCLK/BCLK coming out from the ADC
Biquad
Member++
Posts: 20
Joined: Wed May 24, 2017 11:38 am

Post by Biquad »

Hi,
great idea ! Thanks for your suggestions also for the codec master hint.
I wonder why the xmos don't switch to LRCLK 768k for a simple test ?

The idea about feeding the DAC by LRCLK and BCLK from the ADC is great.
Seems i need a new xmos board with a switchable fsel1 ...fsel4 set of oscillators;)
Would be nice if you can send me via pm a litte schematic with xmos clocks routing for dac and adc.
Big thanks !
User avatar
fabriceo
XCore Addict
Posts: 181
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

well, it is not that I do not want to share but need to put a drawing together and this takes time :)
also I hope you are familiar with this type of topic otherwise this would not help you too much regarding the challenges.
the XU216 or XUF216 is the best option to go, but the XU208 might be ok.
basically you have 2 or 4 crystal that you control the OE pin from a 8bit or 4 bit port from XMOS,
then this master clock goes to the ADC, the DAC and the XMOS mclk_in.
Then the LR+BCLK are generated by 1bit pins from xmos and goes straight to ADC and DAC
finally the DAC data and ADC data both goes to 2 1bit port.
add to that 2 bit from a 4bit port for controlling the ADC and DAC over I2C, xmos being master and your done.
everything else can be found in the "multichannel platform v2 hardware manual" and fo the audio app you will just have to recompute the "divide" in audio() task according to using 45/49 or 22/24 crystal.
But you have to spend some time on understanding the Multichannel platform hardware and read the XU216 datasheet and the swusbaudio user guide, and some hours on this forum to find all the little things required to make the usb app ok for windows 10 and for DSD... it all depends how much spare time you have for this project. but thats gonna be interesting.
feel free to share you schematic on the forum and we can review it.
regards
Biquad
Member++
Posts: 20
Joined: Wed May 24, 2017 11:38 am

Post by Biquad »

Hi,
thats exactly what i need. A short discription of the clock routing as slave. Thank you !

Why the LRCLK is not changing to 768kHz is still unsolved. Maybe one of the xmos guys can help here.
I use xk_216-mc 6.15.2 source as base. Xuf216 as master at the moment.


I have tried to debug the audiohwconfig() to find out if the xmos receives the correct samplerate request ( i use foobar with an 768k pcm file)
from the host but the compiler has removed the debug informations for samFreq.
samFreq shows the value of 0 at breakpoint. For the XUF216 the clocking scheme is different and i have no clue at what point the LRCLK is calculated.

Would also be good to know how to set the samplerate to 768k on the xmos to have a look how the clocks are set, without using a
pc driver.

Best regards
User avatar
fabriceo
XCore Addict
Posts: 181
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi Andreas,
you say you cannot get the 768k with the PC driver, right ?
do you really have a 45/49mhz set of crystal on your board?
if you don't have that crystal then you can change the audio_mclk block settings to temporary feed it from the reference clock divided by 2 with this configure_clock_ref(clk_audio_mclk, 2);
Did you put the MCLK_44_1 and 48 to 1024 * ?
how many NUS_USB_CHAN_OUT and IN do you have ? with 768k you are limited to 2 for each due to 1024 bytes microframe.

but myself I only played with 384k so can't say more;

the I2S sample rate is changed by a request coming into Endpoint0 then Buffer (usb_buffer.xc) set a global variable (g_freqChange_flag) and this triggers the Decouple task to send a Control Token to Audio task which receives it in the Deliver/Transfer functions and then force a returns into Audio.xc par for treatment (recompute divide and reinit ports & clocks, then call audiohwconfig for modifying codec adc & dac).
its pretty difficult to force this process :) but you can easily trace it with some printf around if you use xscope in xscope mode (not jtag mode)

best of luck
Post Reply