sorry, I didn't see your post, ALC4050 is purely junk with low-end specs, I had interest to use that ONLY like USB bridge 32/384 $1/chip.
ESS combos USB/DAC/HPA practically worse than Cirrus Logic DAC+HPA CS43131 and similar. For example, chi-fi simply copy-pastes specs from the ESS datasheet to the product page but ASR measurements are always 10x times worse.
Zorloo Ztella MQA Phone Headphone Adapter Review | Audio Science Review (ASR) Forum
you can buy and take a look closer to that combo for $20-30
1pcs Type C Adapter ES9280C Pro HIFI 32 bit/384K DSD Output 2Vrms|Plug & Connectors| - AliExpress
As you can see, there is just no way to make layout mistake because the only 1 chip and 10-20 caps surrounding that. Anyway, THD+N result is way worse than ESS promises, in fact, ES9281 pro has the same junk-rnge of specs as ALC4050, and much worse vs CS43131.
BTW, maybe I told here about the "stuttering" issue of CT7601 but finally, the issue is solved and the root cause was some "experimental" registers setting to fix DSD256 noise with Foobar2000, which Comtrue sent to me. That setting didn't solve DSD noise but created the stuttering with USB3 hosts! The register named "USB timeout" value was reduced 8 times, and USB2 hosts were fine with that but USB3 start the stuttering. Actually, I noticed not all USB3 had such problem but only such of them which sends audio-packets in nonperiodical(burst) manner. USB2 is always had some particular rate of packets(100uS for PCM 32/44.1), hence, reduced 8x times timeout wasn't problem.
PS: one more example of ES9281 real performance Earmen Sparrow Review (Portable DAC & Amp) | Audio Science Review (ASR) Forum
PS: one more example of ES9281 real performance Earmen Sparrow Review (Portable DAC & Amp) | Audio Science Review (ASR) Forum
Last edited:
IIUC the sparse specs available on internet CT7601 is a USB2 device. Even when connected to a USB3 port/controller, it should use the internal but separate USB2 path (USB2 controller -> USB2 wires -> USB2 hub -> USB2 device) internals-image which has no isochronous bursts available. I do not understand where USB3 transmission is involved. usb - How many isochronous USB2.0 devices can a USB3.0 Hub enumerate? - Stack Overflow
Of course an internal USB2 controller of a USB3 controller xHCI can behave differently from a standalone USB2 controller, also depending on the actual model. There are many incompatibilities of xHCI USB2 functions reported. This seems to be a very relevant post about workarounds USB 2.0 device (scanner) does not work with xhci_hcd on USB 3.0 system - Ask Ubuntu.
Of course an internal USB2 controller of a USB3 controller xHCI can behave differently from a standalone USB2 controller, also depending on the actual model. There are many incompatibilities of xHCI USB2 functions reported. This seems to be a very relevant post about workarounds USB 2.0 device (scanner) does not work with xhci_hcd on USB 3.0 system - Ask Ubuntu.
I have similar stuttering issues with Meizu Hifi CS43131(non-Pro) dac too. Interestingly, this stuttering issue appears only on 44.1-kHz related content. I 'm upsampling to 48kHz to avoid this. My PC is a AMD Ryzen platform which is quite new.
I sent email to Meizu support in order to get any fw upgrade but I got no reply.
I sent email to Meizu support in order to get any fw upgrade but I got no reply.
After reading elsewhere, you might try putting a USB2 (not USB3) hub between the computer and the dac. Then the dac will be running from a different USB controller and that might fix the problem. Obviously, make sure the firmware and drivers for your computer are up to date too, maybe the first thing to try.
Probably.. but I bought this after seeing your own measurements on ASR.
There's only one female Type-C connector on PC and laptop. They're both USB3.0. And I don't have a Type-C to Type-A adapter in order to use with different ports and devices. It seems I should have one immediately.
I don't think there has yet been any mention of this product in the thread:
miniDSP MCHstreamer
It has an Xmos based USB interface.
Is this not what the OP is looking for? Cost is only US$115
miniDSP MCHstreamer
It has an Xmos based USB interface.
Is this not what the OP is looking for? Cost is only US$115
Well it's kind of expensive and the opposite of compact. There are similar products from other companies, most of them are based on XMOS. As was already said, the big downside of XMOS implementations is that you need fairly many external components and that it is not really that power efficient compared to other solutions.
Pretty sure OP designs audio equipment and wanted a chip-down design for a dongle or similar. XMOS chips have atrocious power consumption and the entire software paradigm is annoying, not to mention the driver situation on Windows.
Last edited:
The situation around USB audio-bridges a bit more strange than could be. USB and UAC2 is a well-documented protocol, it is a standard, and WTF we have practically?? I had stuttering with Comtrue(because they gave me such bad config but anyway), I know people have stuttering with savitech, you have the same with Cirrus Logic bridge.. Why it so difficult to follow the standard and avoid such issues?
About 10 years ago I met some people from Intel who were a part of USB-IF. We were working on an unrelated protocol, but it was a similar industry working group and design-by-committee lead by Intel. The spec ended up being an overcomplicated disaster, incredibly annoying to implement, and still has never seen wide adoption because of this. When I read the USB Device Class specifications I get some of the same feelings. I have never tried to implement UAC 2.0, but I suspect it has a lot of corner cases. If it were easy to implement then you wouldn't have a situation where Microsoft decided to license a 3rd party driver and most of the solutions on the market are half baked.
When you try to design something that is all things to all people, it rarely turns out clean.
Sometimes I am surprised USB itself works as well as it does. Take a look at the number of "quirks" in the Linux kernel host controller drivers.
When you try to design something that is all things to all people, it rarely turns out clean.
Sometimes I am surprised USB itself works as well as it does. Take a look at the number of "quirks" in the Linux kernel host controller drivers.
Last edited:
Just yesterday, I loaded some Intel Bluetooth drivers onto a laptop, and of course, issues with stuttering began immediately after, only when loading another large program.
That is with the new Bluetooth feature turned off, just that something was switched in the bios that allowed a perfectly operating setup to go off the rails a bit.
That is with the new Bluetooth feature turned off, just that something was switched in the bios that allowed a perfectly operating setup to go off the rails a bit.
Run LatencyMon and see what you get with it enabled in the BIOS and then disabled. This is not abnormal with PC hardware. There are many drivers out there that, under certain conditions, use too much kernel time and cause these types of problems. Windows is predisposed to this more than Linux due to the driver model and just the fact that most of these drivers are closed source and no one is going to tear you apart on a mailing list if you write bad code.
Last edited:
Thanks for the tip, am on a network that’s pretty locked down for upgrades.
I did do some digging after your post had prompted me to look into it, unfortunately after a bios update, and some optimization software aimed at the offending program, the problem persists. Is aggravating that I’m not allowed to rollback the Bluetooth driver install that revealed this new issue.
At least it only when starting and ending, and not when the program is up and running!
I did do some digging after your post had prompted me to look into it, unfortunately after a bios update, and some optimization software aimed at the offending program, the problem persists. Is aggravating that I’m not allowed to rollback the Bluetooth driver install that revealed this new issue.
At least it only when starting and ending, and not when the program is up and running!