I wasn't aware of the Unison. I don't follow Schiit much. In the pre-Unison world it did look like Schiit was using Amanero. At least their boards showed a set of ICs by the USB port that looked an awful lot like an Amanero board integrated onto the Schiit main board.
Schiit competes on cost so it would make perfect sense that they chose to develop their own solution. That way there's no licensing fees to pay. No risk of some third party vendor going out of business. And they can claim their solution is special and has the blessing of Mike Moffat, which will make the marketing guys happy.
Tom
Schiit competes on cost so it would make perfect sense that they chose to develop their own solution. That way there's no licensing fees to pay. No risk of some third party vendor going out of business. And they can claim their solution is special and has the blessing of Mike Moffat, which will make the marketing guys happy.
Tom
With STM32F7/H7 you could build something like this:
I2S output + input (full-duplex) at 768k/32, DSD512 output.
All outputs isolated (including I2C and GPIO).
NZ2520SDA clocks.
External MCK possible.
Uses MMCX connectors (better than U.FL)
Connectors for displays (I2C, HD44780), encoder, GPIO pin header
No Windows driver needed (DSD native in Linux only).
I2S output + input (full-duplex) at 768k/32, DSD512 output.
All outputs isolated (including I2C and GPIO).
NZ2520SDA clocks.
External MCK possible.
Uses MMCX connectors (better than U.FL)
Connectors for displays (I2C, HD44780), encoder, GPIO pin header
No Windows driver needed (DSD native in Linux only).
I'm 99.9999 % sure that the USB solution used by Schiit before they developed their own was indeed the Amanero circuit. It certainly looked to be the same circuit from a quick glance on Schiit's pictures of the internals. Same large uC, same oscillators, etc. Now, I'm going by memory here. I didn't trace out the circuit or de-cap the ICs. I didn't even look at part numbers. I just remember looking at Schiit's boards and going, "oh! Amanero! Cool!" and moving on.
The newer Unison USB solution is not the Amanero. Again, judging by the pictures. I doubt it's any better (or worse) than Amanero/XMOS/CT7601. It's just different Schiit. I'm sure one can concoct some marketing verbiage around "two person-years, special, blessed by the second-in-line to Gawd, BitPerfect™, etc. Not that I'm cynical about these things...
Tom
Ofically you pay, of course:
https://www.usb.org/getting-vendor-id
https://www.usb.org/developers
"Unauthorized use of assigned or unassigned USB Vendor ID Numbers is strictly prohibited."
https://www.usb.org/getting-vendor-id
https://www.usb.org/developers
"Unauthorized use of assigned or unassigned USB Vendor ID Numbers is strictly prohibited."
Don't know about XMOS or ComTrue but STM offers sublicensing for PIDs under their VID. I believe it is free of charge. For purely DIY purposes VID and PID are mostly relevant in Linux as it has quirks for DSD playback based on those ids.
I2S input side is basically same as this:
https://www.diyaudio.com/community/threads/uac2-i2s-input-on-stm32f723e-disco.393702/
https://www.diyaudio.com/community/threads/uac2-i2s-input-on-stm32f723e-disco.393702/
My USB-I2S board has some nifty features not found in other boards AFAIK. One such feature is UAC2 async feedback indicator leds (upper left corner in picture above). These 4 traffic lights show if host is too slow or too fast compared to device. So if feedback is operating correctly only middle green led is lit with occasional flashes of slow (yellow) or fast (blue) leds. If for some reason feedback fails to keep host and device in sync, eventually the red indicator for buffer over/underrun is lit.
This feature has proven useful e.g. when for some unknown reason a Win10 update last year altered the async feedback in Windows USB base drivers (but not directly in UAC2 driver). This resulted in buffer over/underruns at start of play as host did not handle feedback properly. Only cure was to increase buffer sizes in my device.
These feedback indicators can also show the difference in Windows vs. Linux UAC2. Windows UAC2 can work without async feedback for several hours. Linux UAC2 can only work some minutes without feedback before buffer over/underrun occurs.
I'm not sure how XMOS or Amanero deals with async feedback but I have pondered if these subtle feedback issues are the reason why many complain about noise or other issues with UAC2.
This feature has proven useful e.g. when for some unknown reason a Win10 update last year altered the async feedback in Windows USB base drivers (but not directly in UAC2 driver). This resulted in buffer over/underruns at start of play as host did not handle feedback properly. Only cure was to increase buffer sizes in my device.
These feedback indicators can also show the difference in Windows vs. Linux UAC2. Windows UAC2 can work without async feedback for several hours. Linux UAC2 can only work some minutes without feedback before buffer over/underrun occurs.
I'm not sure how XMOS or Amanero deals with async feedback but I have pondered if these subtle feedback issues are the reason why many complain about noise or other issues with UAC2.
Are you sure the difference was not caused by your win vs. linux machine having different USB clock? If no sync feedback is received, linux fills the packets according to the nominal samplerate. I.e. for 48kHz and bInterval=8 (1ms) 48 frames each packet, for 44.1kHz 44 frames for 9 packets and 45 frames for the 10th packet. Basically identical to adaptive mode. I have checked that several times on various occasions, trivial with wireshark. I believe windows do the same as it's the only logical way.
Same host and same device with same clocks. I use relatively small buffers on my USB-I2S boards which may explain the behaviour with Linux.