• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

JCallyJM20/Savitech/CS43131 playback - very choppy from Raspberry Pi/Beaglebone/MPD

R

RogersCompactMonitorFan

Member
Joined
Mar 8, 2023
Messages
21
Likes
16
I'm posting this as I think it deserves a separate thread to the other CS43131 threads. I know there have been reports in other threads of 'clicks' when using some of the CS43131 dongles but I think this is a different problem (or perhaps not!).

TLDR - My JC20 dongle seems to not be happy with a Raspberry Pi/Beaglebone and using 'mpd'. Maybe this information sheds light on some of the glitches people have reported with Windows PCs - or maybe it's a totally different problem - I don't know. But as far as I can tell - be careful if buying one of these devices to use it with a Raspberry Pi Zero or Beaglebone - the sound is glitchy to the point of being unusable. I don't have any of the "faster" Raspberry Pis to hand to test - I don't know if anyone else has success with this.

Details.........

I noticed that the JCally JC20 dongle I recently purchased occasionally glitched with my Android Pixel 6a phone- particularly during the change of track during 'gapless' playback but at other times - but mostly is usable.

I tried using the Raspberry Pi Zero that I've been using successfully with an Apple USB-C Headphone Dongle, and it mostly plays but glitches often enough to be unlistenable.

This machine hasn't been updated for quite a while, so thought perhaps the kernel (5.15.32+ #1538 Thu Mar 31 19:37:58 BST 2022 armv6l GNU/Linux) was old. I tried a Beaglebone black using the latest Debian image and this is far, far worse - unlistenable. The sound goes "Brrr-brrr-brrr" as though the dongle isn't receiving data quickly enough. The dongle seems to work OK on a desktop Linux machine running Ubuntu however so I don't think it's simply a Linux problem.

I don't really have a huge amount to add in posting this, other than to post my experiences in the hope perhaps it sheds light on some of these problems - or to warn anyone using a Raspberry Pi or Beaglebone that it doesn't seem to work "out of the box".

I sadly don't have enough Linux ALSA debugging knowledge, but perhaps someone out there finds this and a bulb lights up!

Further information provided in case it is useful...

I notice the reported 'packet size' is much smaller on the JC20 than the Apple device so I don't know if this a clue or not.

The device appears like this:

lsusb
Bus 001 Device 005: ID 262a:18c8 SAVITECH Corp. CS43131 HIFI Audio

with kernel...

uname -a
Linux BeagleBone 6.12.28-bone26 #1 PREEMPT Thu May 29 17:50:58 UTC 2025 armv7l GNU/Linux

The other devices I have - Apple USB-C headphone adapter and "Labrodie" branded cheap dongle play fine.

Bus 001 Device 007: ID 05ac:110a Apple, Inc. USB-C to 3.5mm Headphone Jack Adapter
Bus 001 Device 008: ID 3302:29c4 TTGK Technology USB-C Audio

On the working Apple device:

cat /proc/asound/card1/stream0
Apple, Inc. USB-C to 3.5mm Headphone Jack A at usb-musb-hdrc.1-1, full speed : USB Audio

Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 288
Momentary freq = 48000 Hz (0x30.0000)
Interface 1
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 0x02 (2 OUT) (SYNC)
Rates: 48000 - 48000 (continuous)
Bits: 0
Channel map: FL FR
Interface 1
Altset 2
Format: S16_LE
Channels: 2
Endpoint: 0x02 (2 OUT) (SYNC)
Rates: 48000 - 48000 (continuous)
Bits: 0
Channel map: FL FR

and

cat /proc/asound/card1/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 6000
buffer_size: 24000

...but on the JC20 device:

cat /proc/asound/card1/stream0
Shenzhen CBHT Technology Co., Ltd CS43131 HIFI Audio at usb-musb-hdrc.1-1, high : USB Audio

Playback:
Status: Running
Interface = 2
Altset = 2
Packet Size = 54
Momentary freq = 44320 Hz (0x5.8a41)
Feedback Format = 16.16
Interface 2
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x03 (3 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Bits: 16
Channel map: FL FR
Sync Endpoint: 0x84 (4 IN)
Sync EP Interface: 2
Sync EP Altset: 1
Implicit Feedback Mode: No
Interface 2
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 0x03 (3 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Bits: 24
Channel map: FL FR
Sync Endpoint: 0x84 (4 IN)
Sync EP Interface: 2
Sync EP Altset: 2
Implicit Feedback Mode: No
Interface 2
Altset 3
Format: S32_LE
Channels: 2
Endpoint: 0x03 (3 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Bits: 32
Channel map: FL FR
Sync Endpoint: 0x84 (4 IN)
Sync EP Interface: 2
Sync EP Altset: 3
Implicit Feedback Mode: No
Interface 2
Altset 4
Format: SPECIAL
Channels: 2
Endpoint: 0x03 (3 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Bits: 32
DSD raw: DOP=0, bitrev=0
Channel map: FL FR
Sync Endpoint: 0x84 (4 IN)
Sync EP Interface: 2
Sync EP Altset: 4
Implicit Feedback Mode: No

cat /proc/asound/card1/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050


It's playing using mpd with the config below. mpd is reported by 'top' as using about 5% CPU on the Beaglebone so I don't think it's a CPU limitation.

cat /etc/mpd.conf
audio_output {
type "alsa"
name "CS43131 Dongle"
device "hw:1,0"
# DSD stuff from https://help.nativedsd.com/en/articles/6948867-playing-dsd-files-on-linux
#auto_resample "no"
#auto_channels "no"
#auto_format "no"
# dop "yes" # Don't enable DoP unless you know you need it
}
 
  • Like
Reactions: MCH
Following this up: I noticed a post at https://www.diyaudio.com/community/...de-meizu-hifi-dac-hiccups.378954/post-6839491 which helped. This post says that these devices use synchronous USB, so need a processor interrupt every 125us - and had a theory that the single core Pi might be missing some interrupts.

I tried using the Raspberry Pi Zero 2W I had, with its four cores. This copes much better than the Zero W with the single core.

It's still not perfect - it drops a bit if I try to play a file with 192kHz sample rate - but I'm not a bat with ultrasonic hearing so shouldn't think I will need to do this often. I haven't done a huge amount of testing but it seems to be OK at 44.1kHz.

Hopefully this proves useful if someone is searching for it with this problem.
 
  • Like
Reactions: MCH
Hey there, I am who had that issue. Ended up using the rpi4 for that task. Even infrequent dropouts aren't acceptable in the long term. Other dongles were trouble free too.
 
Oh - thanks for replying. Was the RPI4 OK with this dongle or did it also have the dropouts? I've not tried the Zero 2W for a huge amount of time, but it did seem to be OK.

Maybe the dropouts just make it sound like a vinyl record, with the occasional clicks...This is the DAC to bring the digital and analogue people together ;-)
 
Yes I think the rpi4 was ok. I have the dongle disassembled as of now but if I assemble it again I can give it a try
 
I'll have to try it. I have a Zero 2W that I'm using LMS/Squeezelite and a Tempo Tec dongle. I'll set up a card with MPD. Squeezelite works fine. I know Moode and Volumio don't perform well with the Zero W but I think the problem is in the UI. For vanilla MPD I generally use MALP on my phone or tablet as a front end. My experience is that LMS/Squeezelite works best with the smallest amount of computing power on the Pi. Vanilla MPD has worked OK, but I'm lazy about doing the setup. I finally made a copy of a working mpd.conf on my desktop machine that I use for configuration help. Old age is terrible. I remember doing config.sys memory configuration from memory in the '90s. Now I have to look stuff up.
 
RogersCompactMonitorFan said:
...but on the JC20 device:

cat /proc/asound/card1/stream0
Shenzhen CBHT Technology Co., Ltd CS43131 HIFI Audio at usb-musb-hdrc.1-1, high : USB Audio

Playback:
Status: Running
Interface = 2
Altset = 2
Packet Size = 54
Momentary freq = 44320 Hz (0x5.8a41)
Click to expand...
The sample frequency is wrong? (44320 Hz)

Are you setting the sample rate anywhere in mpd.conf

Here's (part of) my mpd.conf (this is on an X86 box though that doesn't make any difference).

Some parameters may not work on your version (I've built mine from source).

I also use this same config on a Pi (v4 IIRC) and it works flawlessly with several DACs (in fact I usually have up to 3 DACs configured at any one time, and all 3 work flwalessly at the same time).

I have set buffer sizes etc. as my internet is relatively slow and when playing one specific aac stream (JB radio) the stream would sometimes falter when there were traffic spikes on my connection.

mpd -V
Music Player Daemon 0.23.16 (0.23.16)


audio_output {
type "alsa"
name "Cambridge Audio 851D"
device "hw:0,0"
auto_resample "no"
auto_format "no"
auto_channels "no"
buffer_time "200000"
period_time "5084"
replay_gain_handler "none"
mixer_type "disabled"
}

input_cache {
size "1 GB"
}

replaygain "off"
filesystem_charset "UTF-8"
auto_update "yes"
auto_update_depth "4096"

connection_timeout "60"
max_connections "50"
max_playlist_length "18222"
max_command_list_size "2277"
max_output_buffer_size "131072"
audio_buffer_size "8192"
 
The sample frequency is wrong? (44320 Hz)
Click to expand...
barrelhouse solly - I know what you mean about configurations. I've been using mpd with MALP for the last while and it's just worked. Maybe I need to edit config.sys to set the IRQ and DMA channel of the USB driver, and perhaps load a TSR to reprocess the audio sample rate, then add mpd into my autoexec.bat Those were the days ;-)

audio_tony - Oh - good spot. I'm not sure what happened there. I just checked and it reports 44100Hz on the track I'm playing on the Pi Zero 2W.

I've added the settings you suggested and will see how things go. I'll then try with the original Zero and see if they help.

Thank you.
 
Finally got around to setting up a vanilla MPD instance on my Zero 2 W. Using a SMB share on my NAS it appears to work fine with a 43131 dongle. I tried it for several hours connected to a powered speaker. I need to get my JCally one out of the car. Slightly OT: I made the mistake of using Bookworm. Bookworm doesn't have the "wait for network on boot" option in raspi-config. I ended up mounting the share manually after spending several hours fooling with alternatives. MPD as a service starts before the disk automounts via fstab.
 
Barrelhouse Solly said:
Slightly OT: I made the mistake of using Bookworm. Bookworm doesn't have the "wait for network on boot" option in raspi-config. I ended up mounting the share manually after spending several hours fooling with alternatives. MPD as a service starts before the disk automounts via fstab.
Click to expand...
You need to edit mpd.service and add a requirement for the SMB mount path:
Code: 
RequiresMountsFor=/path/to/smp/mountpoint
See the systemd.unit man page for details.
 
I'm using a micro SD card (Amazing how much music can fit on such a tiny thing!) which made things a bit easier.

I've been using mpd with Raspian and this dongle for a few days now and it seems fairly OK. It's not perfect (there is still the odd glitch) but it's fairly usable. I'm amazed how you get good sound from a tiny thing!
 
You must log in or register to reply here.
Back
Top Bottom