Raspberry pi-Moode / Meizu Hifi DAC hiccups

Jump to Latest
M

MRamone

Member
Joined 2021
hi all,
i have been using a 24eur Meizu Hifi DAC (non pro version) for a while and it works great when plugged to my phone or my laptop.

being so cheap and small, i thought it would be perfect to use with a raspberry pi-Moode as streamer to feed an amplifier or headphones so gave it a try.

the good news is that it gives 2 volts and is perfect to feed my amplifier.

the bad news is that from time to time it makes hiccups and this is a no go... (much worse with a zero w but still noticeable with a 4b)

i really want to make it work because other than that it sounds excellent and the price and size i find it much better than a regular dac hat

does anyone have experience with this particular dongle on a pi? any suggestion to make it work without hiccups?

thanks a lot
 
M

MRamone

Member
Joined 2021
ah i didnt know they can behave differently. i have it plugged (pi 4) to the closest to the lan connection (top one)
there goes the lsusb -v

pi@moode:~ $ lsusb -v

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 5.04
iManufacturer 3
iProduct 2
iSerial 1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x001f
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0

Bus 001 Device 003: ID 2a45:0128 Meizu Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.01
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x2a45 Meizu Corp.
idProduct 0x0128
bcdDevice 0.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x010d
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 4
wTotalLength 0x0040
bmControls 0x00
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 9
bNrChannels 2
bmChannelConfig 0x00000003
Front Left (FL)
Front Right (FR)
iChannelNames 0
bmControls 0x0000
iTerminal 0
AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 2
bSourceID 1
bmaControls(0) 0x00000003
Mute Control (read/write)
bmaControls(1) 0x0000000c
Volume Control (read/write)
bmaControls(2) 0x0000000c
Volume Control (read/write)
iFeature 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0302 Headphones
bAssocTerminal 0
bSourceID 2
bCSourceID 9
bmControls 0x0000
iTerminal 0
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 9
bmAttributes 7 Internal programmable clock (synchronized to SOF)
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0006 1x 6 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bmControls 0x05
Active Alternate Setting Control (read-only)
Valid Alternate Setting Control (read-only)
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000003
Front Left (FL)
Front Right (FR)
iChannelNames 0
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 3
bBitResolution 24
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0120 1x 288 bytes
bInterval 1
AudioStreaming Endpoint Descriptor:
bLength 8
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bmControls 0x00
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bmControls 0x05
Active Alternate Setting Control (read-only)
Valid Alternate Setting Control (read-only)
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000003
Front Left (FL)
Front Right (FR)
iChannelNames 0
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 2
bBitResolution 16
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x00c0 1x 192 bytes
bInterval 1
AudioStreaming Endpoint Descriptor:
bLength 8
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bmControls 0x00
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bmControls 0x05
Active Alternate Setting Control (read-only)
Valid Alternate Setting Control (read-only)
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000003
Front Left (FL)
Front Right (FR)
iChannelNames 0
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0180 1x 384 bytes
bInterval 1
AudioStreaming Endpoint Descriptor:
bLength 8
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bmControls 0x00
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 31
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 4

Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x2109 VIA Labs, Inc.
idProduct 0x3431 Hub
bcdDevice 4.21
iManufacturer 0
iProduct 1
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.04
iManufacturer 3
iProduct 2
iSerial 1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
 
P

phofman

Member
Joined 2005
Thanks for the dump.

I really wonder how this device handles synchronization. The USB audio mode is synchronous (quite unusual for a modern USB2 device) which means the driver sends equal number of samples every USB frame, no feedback from the device is provided.

The CS46L41 feeds I2S to the CS43131 DAC. A crystal 22.5792MHz (44.1kHz multiples) is connected to XTI/MCLK. The DAC contains a fractional PLL, configurable via I2C. The CS43131 datasheet does not mention any adaptive PLL to align the internal master clock with the incoming I2S bitclock. That would suggest the USB receiver itself adaptively resamples the incoming rate (clocked by the USB host) to the CS43131 clock passed to CS46L41 by master I2S.

I have never seen a USB receiver chip to implement adaptive resampling. They either have a PLL (adaptive mode), becoming slave to the USB host and master to the DAC, or fixed clock (async mode), becoming slave to the DAC clock but master to the USB host. In this case the USB receiver is slave to the USB host and apparently a slave to the DAC which would mean having to resample between the two master clock domains.

Quite interesting.

But that does not explain why the Meizu DAC glitches on RPi4 USB3 ports (which are connected to proper USB controller VL805, unlike the USB-C port connected to the low-performance dwc2 USB host IP core), while it works flawlessly on other USB hosts (you mentioned a laptop and a mobile phone). I would understand glitches if the DAC were plugged into the RPi4 USB-C port (or ZeroW which has only the poor-performance USB controller dwc2)
 
P

phofman

Member
Joined 2005
jean-paul

jean-paul

Disabled Account
Joined 2002
Maybe I learned. Maybe I know more than you assume. I was not sarcastic but deleted my post anyway as the content was too obvious*. There was a smiley indicating that. Reacting to deleted posts is a severe kernel error asking for an immediate patch :)

* I just remembered the discussion a while ago on ready made devices that would have old kernels and therefor all kinds of assumed problems that no-one experienced and RPi being the king of the hill with regards to kernels.

Lighten up!
 
Last edited:
P

phofman

Member
Joined 2005
Interesting...but.. we still have no report as to how it behaves on the RPi4 USB2 ports... ???

The RPi4 USB3 ports may have some issues that do not affect the USB2 ports ?? ...as has been noted with some USB external Drives by the RPi team
Click to expand...
.

In general USB3 controllers have many issues for USB2 devices. The linux-usb mailing list permanently receives complaints about incompatible USB3 hosts and USB2 devices. Typically some quirk in the USB host driver for that particular USB controller fixes the issue, even though all xHCI standard controllers should behave identically. That's the same with UAC2-standard audio devices - the linux UAC2 driver is full of quirks for specific devices (which then either fail to work properly with windows UAC2 driver or require a vendor-specific driver).
 
P

phofman

Member
Joined 2005
jean-paul said:
I just remembered the discussion a while ago on ready made devices that would have old kernels (assumptions) and RPi being the king of the hill with regards to kernels.
Click to expand...

The key difference is there is a team of professional RPi devs you can talk to who permanently post patches to mainline. No hardware is void of bugs but on RPi you can upgrade to the latest kernel where the bug can be fixed. I wish the same was true for the Rockchip SoCs because they offer much better HW features internally for audio. BTW that is the main reason why CamillaDSP is not widely used on inexpensive Rock64 boards with great 8ch I2S ports, internal configurable MCLK dividers etc. These boards would be great with USB-audio gadget code, becoming USB soundcards with internal multichannel DSP.

I communicate with a few guys who are hired to backport the USB audio gadget code to older android kernels. There will always be only a subset of patches backported because it's an ugly and complicated chore. Being able to use the latest kernel is a huge advantage.
 
jean-paul

jean-paul

Disabled Account
Joined 2002
The Rockchip device in question is supposedly (according the manufacturer) fitted with customized software. I won't bother to check if that is true as it is way too buggy till now and it was introduced too early. I do the assumption that their devs also try to solve matters, well I know they do. Should be like that with commercial gear. That is what you pay for. Also to NOT have to talk to devs to solve issues :)

The pun was intended as the "opposite sides" seem to have more in common than it looks like at first glance.
 
Last edited:
P

phofman

Member
Joined 2005
I am sorry I do not share your opinion that commercial streamer vendors actively backport the many patches the USB audio driver receives basically every day to older 4.X kernels. In many cases it's not even possible as the patches use some infrastructure changes introduced in newer kernel versions.

You have many contacts, ask them. I am afraid you will be disappointed with their answer, if you get any.
 
jean-paul

jean-paul

Disabled Account
Joined 2002
Answers are rarely given, that is very true. It seems only the end users really like USB :D

The way you present it only RPi and similar popular SBC's can be well performing platforms because of fast reacting devs and fast adapted patches. This would then mean a cheap device with good support always will outperform/have less issues than a commercial device with supposedly older software. This is true in the exceptions where things don't work out OK (often with new/recent devices connected), not the majority. It really is not so extreme as many users don't experience issues as they connect older DACs, many products have internal DACs (or the user uses the reliable SPDIF to a DAC ;)) and many products have better SPDIF outputs compared to their USB outputs.... and it is fully normal nowadays to have to circumvent such issues unfortunately. Let's not pollute the thread any longer.
 
Last edited:
P

phofman

Member
Joined 2005
I am not talking about performance of the given device as is, but about support of USB devices being connected to it. E.g. look at this discussion about Motu Ultralite Mk5 ASR Open Source Streamer Project | Page 32 | Audio Science Review (ASR) Forum . The newer kernel already has enabled support for implicit feedback, making the device work correctly with well-performing USB hosts. The default implicit feedback support was added to mainline in Nov 2020 ALSA: usb-audio: Check implicit feedback EP generically for UAC2 * torvalds/linux@2e43aae * GitHub . Michael installed a newer kernel and his USB device works on the RPi VL805 USB ports out of the box. It would be glitchy on any older kernel, without this patch (and all its parents) being backported (or without the USB IDs being added to the implicit-feedback whitelist as was required before this patch). I wonder how the Mk5 fares on any streamer backed by a professional commercial vendor.

Actually I tend to think this discussion is not very off-topic here as the problem with the Meizo DAC may end up being software-based, with the VL805 chip firmware needing some tweak. Or maybe not.
 
P

phofman

Member
Joined 2005
MRamone, please can you test your DAC on the USB2 ports (the black ones, farther from the ethernet socket)?

I guess the next step would be to present the data and test results to RPi devs in their forum Troubleshooting - Raspberry Pi Forums . It's possible they would know about some VL805 issue in RPi4.

As of the Zero Pi - please can you test the dwc_otg driver instead of dwc2, as discussed here Difference between DWCOTG and DWC2 - Raspberry Pi Forums ? It's also possible the weaker-performing dwc USB host may not serve your card properly with the dwc_otg driver either. IIUC the dwc performance was one of the factors behind adding the external VL805 chip to RPi4.
 
P

phofman

Member
Joined 2005
jean-paul said:
Slowly but steady I tend to think the "all in one" devices so with internal storage and internal DAC/amplifier have the better cards.
Click to expand...

No doubt it's easier and more reliable to build a device with little external dependencies. Any non AIO forum shows that clearly - users constantly fighting the myriad of external DACs/soundcards, external sources (streaming, NAS, all sorts of network services, etc.). Users even fight with connecting analog outputs (ground loops etc.). I absolutely agree that an encapsulated AIO is a better option for a non DIYer, and the vendor too :)
 
jean-paul

jean-paul

Disabled Account
Joined 2002
Of all the digital source devices I have owned or tried out I liked the AIO also the best. AIO without amplifier that is. Since most devices are throw away consumer electronics anyway it does not make too much sense anymore to follow the multi box approach. That approach seems to create more issues than it solves. It is good money though and it is successful since the eighties when DAC chip developments were fast.

BTW you did react to a deleted post again. Patch that kernel :D I am busy patching the "posting and then deleting" kernel error.
 
Last edited:
StevenCrook

StevenCrook

Member
Joined 2019
Paid Member
It seems only the end users really like USB
Click to expand...

They don't care. They like a standard interface that provides a wide range of devices that can be plugged into a hole and mostly just work. What it is and how it works are irrelevant, and otherwise they couldn't give a <your expletive goes here>.

I'm old enough to remember things before the IBM PC reared its head. It was ugly.

Few people look at the swan's legs as it serenely floats past in the river. The legs are working really hard to maintain the effect....

It's all complex, particularly as new use cases are added to those USB must support. I had a look at the software required to implement the new protocols for the higher rated USB3 connectors. It's hair raisingly complex.
 
Last edited:
jean-paul

jean-paul

Disabled Account
Joined 2002
Just when I thought we could forget SPDIF I also found that out. Still... even today some sources perform better with SPDIF which goes to show.

Mmm don't underestimate the success of, for instance, the more recent USB-C with the general public if only because it is used on newer phones and because the plug can be plugged in either way. Analog to that many consumers absolutely hate micro USB probably because of it's highly unreliable character. When the EU got involved in phone power plugs things could only get better :)
 
Last edited:
You must log in or register to reply here.
Top Bottom