Weird behaviour of custom USB to SPDIF bridge

[mon2]

1) What are the values for the defines inside your customdefines.h?

2) Confirm the clock values at the output of each clock generator - are they accurate?

3) Install the original design reference clock of 11.2896MHz and use the XMOS supplied customdefines.h values -> re-compile and test again.

Do you still hear the distorted audio issues at the supported data rates?

4) Which codec are you using? Must be different than the ref design since you are supporting > 192khz?

From my limited understanding of this design, you have sped up the clocks to offer support for higher end audio but not sure if this design / IP is certified for the applied over clocking. The small package CPU is reported to be strapped to 400 Mhz (even though you are sourcing the C5 grade = 500 Mhz capable). This would mean that you will have to alter the source code (PLL configuration) to support 500 Mhz operation if that is required for this operation. Not sure on this but start with the simple replacing of the clock back to factory, only to confirm if the widget works for all operating systems, even if at the lower sample audio rates.

----

Interesting thread worth a read:

http://www.xcore.com/viewtopic.php?f=37&t=4375

https://www.asus.com/microsite/essence/ ... -ASIO.html

[Lorien]

Thank you to all of you for your time and help! I'm sorry for my lack of reply as I'm really pissed off about this trouble! I checked EVERYTHING on my board and the single conclusion I came with is this: there's a problem inside the old XS1-L01 chips (now with a different serial No., but the same silicon) that the external clocks are reclocked to system clock. So obviously there's some jitter coming from this since my math never helped me to get an integer value after subtracting 22.5792 MHz or 24.576 Mhz from 100 MHz (or 400 MHz for that matter). I'm assuming my old design was working because the 13 MHz clock needed by the XMOS processor was a stable one while the "audio" clocks were quite close to the XMOS chip... not to mention separate PSUs for: 3.3V I/O on XMOS, 1.0V for XMOS core, 1.0V for PLL, and 3.3V for each oscillator + 3.3V for clock multiplexer and buffer. I was lucky?
And, on my old design there was NO galvanic isolation chip between audio clocks and XMOS.
So, reading the XMOS documents about USB audio I came to conclusion that, the XMOS chip need to send a feedback to the host in therms of a fractional value. I'm assuming the reference of that value is the external clock signal received by the XMOS processor. That's why all this USB Audio application is called "asynchronous", NO? So, what if that feedback is scrambled by the jitter from the isolator + own jitter made by sampling the ports with internal 100 Mhz clock (for a C4 part)? Jitter values are added thus making things worse!

I'm just saying... as I'm not an expert otherwise I wouldn't be here.
Still, I want to THANK YOU very much for all your help
... but after one year of struggle I completely ditched this design!
... and, since the help I had on this matter wasn't enough to even understand what's the source of this issue... I cannot be sure that my future designs will stay untouched by this problem!
So, I ditched any of the XMOS chips too!
I saw Thesycon are doing a good job in building their own hardware receiver called U-Hear so I'll go on that path with my future projects! What I can be certain is that they are more responsive than XMOS!

Kind regards,
L

[Lorien]

Thank you to all of you for your time and help! I'm sorry for my lack of reply as I'm really pissed off about this trouble! I checked EVERYTHING on my board and the single conclusion I came with is this: there's a problem inside the old XS1-L01 chips (now with a different serial No., but the same silicon) that the external clocks are reclocked to system clock. So obviously there's some jitter coming from this since my math never helped me to get an integer value after subtracting dividing 22.5792 MHz or 24.576 Mhz from 100 MHz (or 400 MHz for that matter). I'm assuming my old design was working because the 13 MHz clock needed by the XMOS processor was a stable one while the "audio" clocks were quite close to the XMOS chip... not to mention separate PSUs for: 3.3V I/O on XMOS, 1.0V for XMOS core, 1.0V for PLL, and 3.3V for each oscillator + 3.3V for clock multiplexer and buffer. I was lucky?
And, on my old design there was NO galvanic isolation chip between audio clocks and XMOS.
So, reading the XMOS documents about USB audio I came to conclusion that, the XMOS chip need to send a feedback to the host in therms of a fractional value. I'm assuming the reference of that value is the external clock signal received by the XMOS processor. That's why all this USB Audio application is called "asynchronous", NO? So, what if that feedback is scrambled by the jitter from the isolator + own jitter made by sampling the ports with internal 100 Mhz clock (for a C4 part)? Jitter values are added thus making things worse!

I'm just saying... as I'm not an expert otherwise I wouldn't be here.
Still, I want to THANK YOU very much for all your help
... but after one year of struggle I completely ditched this design!
... and, since the help I had on this matter wasn't enough to even understand what's the source of this issue... I cannot be sure that my future designs will stay untouched by this problem!
So, I ditched any of the XMOS chips too!
I saw Thesycon are doing a good job in building their own hardware receiver called U-Hear so I'll go on that path with my future projects! What I can be certain is that they are more responsive than XMOS!

Kind regards,
L

[Lorien]

Thank you to all of you for your time and help! I'm sorry for my lack of reply as I'm really pissed off about this trouble! I checked EVERYTHING on my board and the single conclusion I came with is this: there's a problem inside the old XS1-L01 chips (now with a different serial No., but the same silicon) that the external clocks are reclocked to system clock. So obviously there's some jitter coming from this since my math never helped me to get an integer value after subtracting dividing 22.5792 MHz or 24.576 Mhz from 100 MHz (or 400 MHz for that matter). I'm assuming my old design was working because the 13 MHz clock needed by the XMOS processor was a stable one while the "audio" clocks were quite close to the XMOS chip... not to mention separate PSUs for: 3.3V I/O on XMOS, 1.0V for XMOS core, 1.0V for PLL, and 3.3V for each oscillator + 3.3V for clock multiplexer and buffer. I was lucky with that design?
And, on my old design there was NO galvanic isolation chip between audio clocks and XMOS.
So, reading the XMOS documents about USB audio I came to conclusion that, the XMOS chip need to send a feedback to the host in therms of a fractional value. I'm assuming the reference of that value is the external clock signal received by the XMOS processor. That's why all this USB Audio application is called "asynchronous", NO? So, what if that feedback is scrambled by the jitter from the isolator + own jitter made by sampling the ports with internal 100 Mhz clock (for a C4 part)? Jitter values are added thus making things worse!

I'm just saying... as I'm not an expert otherwise I wouldn't be here.
Still, I want to THANK YOU very much for all your help
... but after one year of struggle I completely ditched this design!
... and, since the help I had on this matter wasn't enough to even understand what's the source of this issue... I cannot be sure that my future designs will stay untouched by this problem!
So, I ditched any of the XMOS chips too!
I saw Thesycon are doing a good job in building their own hardware receiver called U-Hear so I'll go on that path with my future projects! What I can be certain is that they are more responsive than XMOS!

Kind regards,
L

[akp]

Since it plays perfectly with Mac your hardware must be fine. It's almost definitely in the code, possibly your feedback endpoint or associated descriptors. Can you post your code and schematic since you're ditching the design? Presumably it has no further interest to you commercially.

[Lorien]

Hello,
I just saw my three posts in a row! I'm really sorry about that and I'll contact the admin to delete the one from Sat Apr 07, 2018 2:05 pm and Sat Apr 07, 2018 8:23 pm. I just updated my text without knowing the consequences!
@ akp: As for my schematic and firmware, I'll gladly do it privately since I know what this means to share it in public. It's okay if I'll use the contact form from your Xcore account?
Kind regards,
L

[akp]

Please do, thanks.

[infiniteimprobability]

Do you have inputs enabled too? If so, do you have UAC_FORCE_FEEDBACK_EP set to 1 in the Makefile?
MACOS is OK without this (it uses the implicit feedback from the input stream) but Win and increasingly Intel/Linux needs this too.. Otherwise rate calculation will be wrong..

Perhaps post your customdefines.h and Makefile?