USB to I2S

[Ross]

DSD is PDM do I'd start my looking at some of the PDM Microphone code in lib_mic_array

Your naming scheme seems fine ;)

[HerbieSundiver]

Maybe I explained it wrong, but I do not need a physical DSD interface.
DSD is coming from USB via our ASIO driver and should go via I2S to our FPGA-codec. So basically USB 2ch in/2 ch out to I2S 2ch in/ 2ch out. Those two channels carry pcm and dsd data.
Isn't the lib_xua closer to this? I only cannot find the DSD input (from ADC) part...

[fabriceo]

Hi,

if your FPGA is in charge of converting an I2S pcm stream to a dsd stream in both direction, then there is nothing special to do on the lib_xua : just configure it as PCM only with NO DSD_CHANS_DAC and no NATIVE_DSD
you will be able to exchange i2s in both directions with a normal BCLK+LRCLK.

Now if you want to use the special feature inside the lib_xua which gives the possibility to deal with DSD stream with a special USB Alternate Setting accepting the DSD (raw 32) format, then be aware that all the logic behind this is not implemented for inputs (ADC), but only for outputs.

by the way, you can also configure the XMOS as "master", delivering the BCLK and LRCLK while accepting the master clock as an input, coming from the FPGA or directly the crystal.

also FYI, I m not sure that lib_xua accept a single master frequency (like 45mhz) but need 2 (45 & 49). Even if you only need one with DSD usual frequencies.

hope this helps
fabriceo

[HerbieSundiver]

Now if you want to use the special feature inside the lib_xua which gives the possibility to deal with DSD stream with a special USB Alternate Setting accepting the DSD (raw 32) format, then be aware that all the logic behind this is not implemented for inputs (ADC), but only for outputs.

Yes, that is what I need :-) pcm AND native DSD and DoP. And I wanted to ask where the best point is to add/change code to implement the input side (ADC).

Clocking wise I am flexible but my plan was to supply the xmos clk via crystal and the MCLK comes from the fpga. I'll do the needed clock changes in the fpga with separate vcxos...

Greets,
Sun

[fabriceo]

Hi,
Basically you will have to create an additional Alternate Settings for the Input descriptor. I think at the moment there are only 2, one for 16 bits and one for 24 bits, you will need another one for raw32-DSD (and I would also put one for PCM32). this impacts quite some files as the corresponding Defines are used for the descriptor and in the endpoint source.
Also are you sure that the host driver will accommodate such format for the input stream ?
Then you need to duplicate the special handling of DSD output port (in the deliver section of audio i2s) to make also the inputs, and this impact the port declaration as there is no DSD_CHANS_ADC in the source code.
When it comes to DoP, you will want to encode this instead of decoding it. Again leveraging the DSD DoP deliver and adding ADC acquisition and encoding at twice the speed...
But then I don't understand what is the role of the FPGA when it comes to PCM-DSD conversion ?
That is a nice project, more details requires effort which are out of the contribution on this forum, hope this helps anyway

[HerbieSundiver]

Hi Fabriceo,
thanks for your reply...yes I thought so but hoped it would be less of a "deep dive" project.

Also are you sure that the host driver will accommodate such format for the input stream ?

Yes, as we have the system running fine with an now obsolete XS1 ans our custom ASIO driver. But unfortunately I do not have the source code of the XS1 project...

When it comes to DoP, you will want to encode this instead of decoding it. Again leveraging the DSD DoP deliver and adding ADC acquisition and encoding at twice the speed...

Not even this, we do it in the fpga, so a simple pass through as undetected pcm is fine

But then I don't understand what is the role of the FPGA when it comes to PCM-DSD conversion ?

It is our main processor and DAC without using a codec chip. So basically we only need the USB interface function of the xmos like a "clever phy".

I'd rather need a pass-through from USB to I2S (or whatever interface) and depending on the alternate setting I'd set a GPIO to inform the FPGA if it is native DSD or not. Same for the ADC-to-host direction, one alternate for pcm and one for native DSD.

It would be really cool if Ross could do like a template for this pass-through thing as I will surely mess up the code ;-)

Regards,
Sun

[fabriceo]

Hi Sun,
good,
if you do DoP encoding then you just need to push the encoded PCM stream with a proper lrclk+bclk and yes the XMOS would simply be passthrough. Upto the host software to accept this format.
You "just" need to modify the source code (just verified on the latest lib_xua on GitHub) because they have not implemented the 3 Input Alternate Stream with the flexibility required (flagged as TODO). typically HS_STREAM_FORMAT_INPUT_1_SUBSLOT_BYTES is associated with HS_STREAM_FORMAT_INPUT_3 ...
https://github.com/xmos/lib_xua/blob/cb ... rs.h#L1916
or maybe you simplify and just publish one single AltSet at 32 bits by changing the STREAM_FORMAT_INPUT_1 only

What I m not getting is the DSD case. The 32 bits words that you send to the XMOS, are they representing a "pdm" data flow , and you push them with a single bitclock signal ? or are they representing already a converted PCM 32 bit stream sent with Lrclk and Bclk ?
if you are in the second case (where I do see a value for an FPGA) then yes you are right talking about a simple passthrough again and then the standard XMOS application does the job already.

But if you are in the first case then my previous answer is valid and quite big rework is need.

[HerbieSundiver]

Hi Fabriceo,

What I m not getting is the DSD case. The 32 bits words that you send to the XMOS, are they representing a "pdm" data flow with a single bitclock signal ? or are they representing already a converted PCM 32 bit stream sent with Lrclk and Bclk ?
if you are in the second case (where I do see a value for an FPGA) then yes you are right talking about a simple passthrough again and then the standard XMOS application does the job already.

I2S as container (just higher frequency) but the "pcm content" or better the content of the 32bits may be PCM, raw DSD or DoP. So the host only knows what to expect due to the interface/alternate setting.
(Int/alt1 is pcm to dac, int1/alt2 is DSD to dac, int/alt1 is pcm to host and int2/alt2 is DSD to host)

I think you're right, the host-to-dac side (PCM and DoP) is already there with the examples but for interface2 (adc to host) I have to start modifying...

Our main reason for an FPGA is it being everything else: the DAC and all the other I/Os (AES, SPDIF etc.) including all the SRC and so forth...

[fabriceo]

Hi Sun, now I have the feeling that you just need a bidirectional PCM to I2S and I2S to PCM passthrough interface as you may have pointed at the beginning .
Then good news this is immediately feasible with lib_xua, with the limits discussed on AltSets. but in and out are possible, just read the pdf file to understand how to configure this and select the right xmake config.

Still if you want the Host (end user side) Application to make a difference between PCM and DSD by the USB configuration with 2 different altsetiings, then you have several issues at different levels:
- this is the host who chose the AltSettings, never the device.
- The lib_xua is developed so that DSD output type of AltSetting is recognized and then cascaded to the audio task in order to change the 32bit delivery mechanisms (split inside deliver() ). in dsd no lrclk and one-2-one relation between a port and a channel. in pcm, 2 channels are sent to the same port with the lrclk switch in between.
- In case you effectively need the DSD AltSet for Input as well, nothing is ready for that, on the usb side or i2s side.

some homework required :)

Also I recognize the benefit of an fpga somewhere in a multi modal product nowadays

good luck

[HerbieSundiver]

Good morning Fabriceo!

Thanks so much for your inputs! That'll help me to work my way through...
I'll surely come back to you guys with more questions :-)

Thanks, till soon,
Sun

P.S. yes, our recording software is choosing for the ADC side of course :-)