ADCs and DACs for audio instrumentation applications

[phofman]

Have you checked the rate synchronization feedback from the device to the host and host reaction to the feedback actually work (implicit or explicit)?

 

[syn08]

How would I check this?

Anyways, meantime my XTAG3 adapter decided to stop working, it is recognized as an USB device running on an XMOS driver, but XTimeComposer and XTools no longer detect it. A classic problem that was never addressed by XMOS, nobody knows if this is a hardware or software issue. I'll get another adapter tomorrow (thanks God, they are not expensive) and see where this is going.

 

[bohrok2610]

If you test without add-on drivers you could check it from Windows UAC driver logs: https://matthewvaneerde.wordpress.c...gs-for-microsofts-usb-audio-2-0-class-driver/

Here is an excerpt of Windows UAC log (USB FS in this case). Packet numbers indicate that every other feedback was accepted.

...
[0]0000.0000::08/25/2021-16:49:33.241 [USBAudio2](0x01): COMPL OUT buf 1 CurrenLinearPosition=10560 EVENT
[9]59D0.80DC::08/25/2021-16:49:33.241 [USBAudio2](OUT): packetNumber=12 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 0 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 2 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 4 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 6 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 8 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 10 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 12 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.243 [USBAudio2](0x01): buf 0 feedback packet 14 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.251 [USBAudio2](0x01): COMPL OUT buf 2 CurrenLinearPosition=11520 EVENT
[9]59D0.80DC::08/25/2021-16:49:33.251 [USBAudio2](OUT): packetNumber=13 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 0 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 2 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 4 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 6 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 8 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 10 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 12 has invalid packet length 0, ignoring packet
[0]0000.0000::08/25/2021-16:49:33.259 [USBAudio2](0x01): buf 1 feedback packet 14 has invalid packet length 0, ignoring packet

But I doubt your errors are caused by feedback packets. IME it is possible to run without any feedback packets for several minutes or even hours before buffer under/overruns.

 

[phofman]

But I doubt your errors are caused by feedback packets. IME it is possible to run without any feedback packets for several minutes or even hours before buffer under/overruns.

It really depends on the USB clock vs. master clock difference. RTX6001 (also XMOS based) uses implicit feedback. Before implicit feedback was enabled for RTX6001 in the linux usb-audio driver, one PC -> RTX6001 setup experienced buffer underruns every 10 seconds.

Implicit feedback ignored:
Incoming USB packets: 931,484 48-bytes long, 684 40-bytes long => relative samplerate 47,994.1298 Hz
Outgoing USB packets: 932,168 48-bytes long

Implicit feedback respected (running on a different PC):
Incoming USB packets: 712,393 48-bytes long, 479 56-bytes long
Outgoing USB packets: 712,393 48-bytes long, 479 56-bytes long

Another setup with a different PC and different RTX6001 experienced the glitches spaced several minutes apart. Enabling the implicit feedback in the driver fixed them completely.

 

[syn08]

How would I check this?

Anyways, meantime my XTAG3 adapter decided to stop working, it is recognized as an USB device running on an XMOS driver, but XTimeComposer and XTools no longer detect it. A classic problem that was never addressed by XMOS, nobody knows if this is a hardware or software issue. I'll get another adapter tomorrow (thanks God, they are not expensive) and see where this is going.

At least for me, it was software. After another few hours of futzing around the setup the culprit was the installation of the XTools 15.0.1. I installed this version of XTools and unfortunately I also enabled installing the JTAG drivers (which were already installed with XTimeComposer. The new XTools do not overwrite the XTimeComposer tools, and I though they will be automatically upgraded - they are not. Moreover, the XTools 15.0.1 are NOT compatible with W10 x64, they complain and refuse to install if the .inf is used manually. Solution was to backup the code, scrap everything, clean the computer (including the shadow USB devices) and start from scratch.

Of course, the compatibility between the new XTools and the Eclipse based XTimeComposer is not addressed/discussed anywhere. As usual, the XMOS documentation is everywhere and nowhere at the same time.

 

[syn08]

It really depends on the USB clock vs. master clock difference. RTX6001 (also XMOS based) uses implicit feedback. Before implicit feedback was enabled for RTX6001 in the linux usb-audio driver, one PC -> RTX6001 setup experienced buffer underruns every 10 seconds.

View attachment 1032285

Implicit feedback ignored:
Incoming USB packets: 931,484 48-bytes long, 684 40-bytes long => relative samplerate 47,994.1298 Hz
Outgoing USB packets: 932,168 48-bytes long

Implicit feedback respected (running on a different PC):
Incoming USB packets: 712,393 48-bytes long, 479 56-bytes long
Outgoing USB packets: 712,393 48-bytes long, 479 56-bytes long

Another setup with a different PC and different RTX6001 experienced the glitches spaced several minutes apart. Enabling the implicit feedback in the driver fixed them completely.

I see you addressed this on the host side: https://patchwork.kernel.org/projec...0f20-1886-6884-a6b2-d11c685cbafa@ivitera.com/

Unfortunately this is Windows, so I don't know what to do on the XMOS side. The native WIN10 UAC2 driver doesn't support implicit feedback https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers (don't know about the Thesycon 4.1.13 driver).

Otherwise, the XMOS documentation states:

The sending of feedback to the host is also handled in the USB buffering core via an explicit feedback IN endpoint. If both input and output is enabled then the feedback is implicit based on the audio stream sent to the host.

so it appears implicit feedback is the default in my case.

 

[phofman]

I would assume that the UAC_FORCE_FEEDBACK_EP flag mentioned in your previous posts would force the XMOS firmware to create the explicit feedback EP. A number of devices mark their EP IN as implicit feedback provider AND generate explicit feedback EP IN at the same time, letting the host driver use whatever feedback mode it accepts. That's why I have not considered the missing implicit feedback support in the stock Win10 UAC2 driver as a major deficiency.

E.g. https://www.xcore.com/viewtopic.php?t=6806

 

[syn08]

A new board version solved all problems. I implemented all suggestions above, and then some:

• XE216 XMOS chip plus a 8Mb flash mmory
• Replaced the 24.576/22.5792MHz synthesizer (starting from a 24MHz clock) with two Crystek CCHD oscillators
• Used MMCX I/O connectors (got them from China, not expensive).
• Changed the USB connector to a Type B.
• Fixed the solder mask bug

Not sure, but I suspect the clock synthesizer was at the root of all troubles. Frequency much different from the PC could lead to buffer under/overflow. I'll check the exact frequencies on the old board. Anyway, UAC2 transfers @192kHz ran perfectly overnight, in a digital loop, no crashes.

Now, on to the next phase, integrating the ADC and DAC.\

 

[syn08]

The silk screen double LRCK_ADC is still there

 

[InspectorGadget]

Nice one, those MMCX connectors dont make half bad headphone cable connectors either. Better than some of the proprietary stuff out there. Pity about the silkscreen bug persisting

 

[chris719]

MMCX is fine but doesn't hold up as well as you might think over lots of insertion cycles. It's much worse than MCX and SMA in practice even if the datasheets don't show it. I had a lot of problems at work with intermittent high data rate connections that turned out to be the MMCX connectors. I'm sure it could go unnoticed in audio, though.

 

[bohrok2610]

The locking in MMCX connectors is initially quite tight (too tight IMO). They will loosen up after some insertion cycles but even then disconnecting them requires that the connector is not even slightly tilted. Due to the tight locking it is quite probable they won't reach their promised number of insertion cycles before something breaks.

BTW I'm using Bedea RG174 PE coated cable which is much more flexible than the teflon coated (clear) cables.

 

[InspectorGadget]

Oh sure, but is ANY of this stuff designed to be plugged and unplugged a bunch of times? its for inter-PCB/inter-IC connection, not for connecting box to box. Same as with its use in headphones, solid connection, swivels well without causing intermittent connection, but its for the headphone cup/IEM end connection, not the amplifier end. I wouldnt recommend it for that.

 

[bohrok2610]

MMCX specs state minimum 500 mating cycles which is the same as SMA or SMB.

 

[InspectorGadget]

Well there you go. I wouldnt dream of using any of them close to that many cycles before replacing. If i'm using MMCX/SMA/SMB, i'm connecting them 1-20 times MAX

 

[chris719]

Well there you go. I wouldnt dream of using any of them close to that many cycles before replacing. If i'm using MMCX/SMA/SMB, i'm connecting them 1-20 times MAX

I only brought it up because you mentioned using them for headphones.

 

[chris719]

MMCX specs state minimum 500 mating cycles which is the same as SMA or SMB.

Maybe the Amphenol connector I used was bad, but we had terrible results at less than 100 cycles despite what the datasheet claims. This was over maybe 200 pieces. I'm sure they are overall fine, just a warning.

 

[syn08]

I find hand extracting the MMCX connectors very difficult, I'd rather unscrew SMAs. I'll try MCXs next time.

And yes, RG316 is too rigid for MMCX, cables may even snap out when moved around. RG174 is much better. I miss the U.FL 1mm thin coax.

 

[bohrok2610]

IME straight MMCX cable connectors are slightly easier to disconnect than the right-angle ones. I do a "break-in" with my MMCX patch cables by repeating the mating cycle few times which loosens up the locking.

U.FL is not suited for repeated re-connects (specced only for 30 mating cycles). There is also no way to make your own patch cables.

 

[Ultima Thule]

Perhaps an MMCX assist tool may help.

https://www.head-fi.org/threads/fin...echanger-for-stubborn-mmcx-connectors.946294/

https://www.aliexpress.com/item/1005003647650896.html