native DSD gives error

[HerbieSundiver]

Hi guys,

I have actually a similar problem:
System: Playback from windows PC (with foobar or Jriver) to custom ASIO driver to xmos XU316 and via I2S to custom fpga dac. (driver and whole chain is verified in our older systems with older xmos chip)

1. Playback of PCM: everything works fine up to 384kHz
2. Playback of DoP: plays back fine (and the dac recognizes it, all good) --> but "dsdMode" in "AudioHwConfig" does not go to DSD_MODE_DOP.
3. Playback of DSD natively: The software players do not start with an error "not supported" or similar --> do I have to change some descriptor?

I do have "#define NATIVE_DSD (1)" in "xua_defs.h" but this does not change anything...what am I missing?

Thanks for your thoughts!
Greets

[HerbieSundiver]

Hi again,
today I played around with the THESYCON demo driver and found something weird:
If I use the xmos VID/PID and the THESYCON driver, everything works! PCM, DoP, and native DSD.
When I now ONLY change the VID/PID to ours and our driver, then only native DSD is not working anymore. BUT: All products with the old xmos work fine with the same VID/PID and the same driver on the same PC...

Anyone a clue?

Thanks,
regards

[HerbieSundiver]

Hi again,
after doing some tests and descriptor dumps I found a difference in the interface usage:


If my dumps are correct, the standard xmos uses interface 1 alternate 3 for DSD and our old systems use interface 1 alternate 2 for DSD.

So my question is: Where is the best place to change this? Do I have to modify sw_usb_audio-_sw_v8_1_0\lib_xua\lib_xua\src\core\endpoint0\xua_ep0_descriptors.h or is there a better way?

Thanks in advance,
regards

[Ross]

"Native DSD" is an XMOS invention for transporting DSD over USB in a specification friendly manner. It requires driver support but has some advantages over DoP (required driver support is the disadvantage)

Do you have a Thesycon licence for your product? The demo driver will only work for the XMOS VID/PID parts built into it.

[HerbieSundiver]

Hi Ross,

yes I know (and I doubt it is an xmos invention as we do it since way before 2007 natively with out driver ;-) )

No, we have no Thesycon license, I played around with the demo-beep driver...

But again: It works with our older products and it works with the Thesycon driver...so I guess there is a little mismatch only for the interface 1 alternate 2 descriptors...could you tell me where is the best place for changing the descriptors?
I just changed "#define OUTPUT_FORMAT_COUNT" from 3 to 2 and now get the right amount of interfaces and also DSD raw is on Int1 Alt2 but still our driver refuses to let the player software even start playback of native dsd. Everything else works fine...
So I am further scanning through the descriptors to find mismatches. Just need the "smartest" place to change them.

Thanks in advance,
regards,

[HerbieSundiver]

So after many trials I have it running. I have to set "#define I2S_CHANS_ADC (0)" in „xua_defs.h“, then the interfaces are in the right order and native dsd plays fine through our driver. I still do not fully understand why this is because our driver supports input and output channels...

Some questions that I now have:
- I'm still unable to change "wLockDelay", I changed it by inserting a #define in "xua_ep0_descriptors.h" but all of them get overwritten somehow....any hints?
- Where would be the best place to assign custom ep to the interfaces (because I think our driver expects certain interfaces on certain eps, sorry I did not write the driver to know it exactly)

Greets,
Herbie

[Ross]

yes I know (and I doubt it is an xmos invention as we do it since way before 2007 natively with out driver ;-) )

Oh, it's 100% XMOS invention/proprietary. I know because it was me that specified its operation and dealt with the development in conjunction with our driver partner. It was done to address the drawbacks of DoP in some early projects for Sony themselves (they wanted x256 on a device that only supported PCM 192 kHz). I only mention his because I don't really expect it to work with any other driver, unless the implementation is reverse engineered and copied of course. Whilst the implementation is in the spirit of the USB spec there is no standard for this - hence the proprietary nature - there are other potential implementation schemes that could have been chosen that fit within the confines of the specification(s). Above the USB layer was the DSD mode in ASIO which was already present at the time, of course.

Maybe you have some similar USB layer scheme (it was hardly one of my most creative innovations!) but sounds like you're finding some differences... looks like you're already using a matching slotsize/resolution (effects required sample-rate) and bit ordering - typically a bit (no pun intended) to notice versus PCM - as the implementations might differ so I'd double check that.

[Ross]

Not aware of that value be getting over-written - there's some pre-processor checks around there though so check that modifying correct value

[HerbieSundiver]

Hi Ross,
that is so cool! So my partner Andreas Koch might have worked with you at that time :-) That is how circles close! (Don't know if that is a even saying in english)

Anyways, the old stuff works beautifully but the transistion to the new xmos was a bit a stoned way as I neither designed the old xmos software nor the driver...my home is more on the FPGA side and the hardware design.

So still I could need some help from you as I might have to put the interfaces in a different order to finally have 2ch in and 2ch out via I2S...or at least adjust the EPs for the interfaces?
Every help is welcome on where to adjust this...

Thanks and greets,
Herb

[Ross]

Can you explain what you mean by "older xmos"? Im not sure anything has changed in the design in this area for quite a while! Or was their custom mods in your old design you think?