Distorted USB audio with Tinker Board and DietPi

There is a thread discussing this matter but not from a DietPi perspective, so i thought i’ll reach out to @Dan_Knight for some assistance.

DietPi install is just fine and Roon Bridge installs like a charm. But, USB audio out is heavily distorted and stops afte a couple minutes.

I found some thread discussing some parameters for this within another distribution;
dwc_otg.fiq.lpm_enable=0
dwc_otg.fiq_enable=1
dwc_otg.fiq_fsm_enable=1
dwc_otg.fiq_fsm_mask=0x3
dwc_otg.fiq_split_enable=0
dwc_otg.sped=1

The one in bold was reported to be the culprit if i understod correctly, which is not sure at all… :wink:
These should go in /boot/cmdline.txt, right? It seems no changes are allowed in config.txt anymore.

Any clues to what might be suitable?

Hi,

The available file for command line boot options is:

/boot/hw_intf.conf

However, i’am unsure as to whether the dwc commands will be supported/applied. Needs testing.

There are some kernel updates for the ASUS TB, that may improve USB audio quality, but i’ve not been able to get round to testing yet. Its on my list :slight_smile:

Thank you for the input Dan, unfortunately this didn’t help the USB Audio…
Actually i cannot get any audio out of the 3.5mm headphone jack either.

aplay -l

gives this:

**** List of PLAYBACK Hardware Devices ****
card 0: Dragon [Black Dragon], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 2: USB Audio [USB Audio #2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: rockchipminiarm [rockchip,miniarm-codec], device 0: ff890000.i2s-i2s-hifi i2s-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Having a look at JustBoom and the Alsa Mixer gives this, for each available output (Black Dragon, USB Audio and Rockchip)

I dont know if this is of any help, but i’ll will gladly tinker around if i can be of any service.
Oh, and i got audio to work through USB when i tried Volumio’s image for the Tinkerboard. However i dont like that very much.

Most likely updated kernel (ours is a few months old now). I’ll make a note to update our image with latest, see if that helps resolve.

1 Like

@Mikael_Ollars

I’ve updated our ASUS TB image:
http://dietpi.com/downloads/images/DietPi_AsusTinkerBoard-armv7-(Stretch).7z

Contains updated kernel (based on TinkerOS 2.0.1 beta image):

root@DietPi:~# uname -a
Linux DietPi 4.4.71+ #1 SMP Thu Aug 17 00:28:01 CST 2017 armv7l GNU/Linux

Please let us know if this improves USB audio.

Thank you for the swift response Dan!

And the new image improved audio a LOT! Now it is completely listenable. However, there are still ticking noises in the audio stream, worse when increasing samplerates :frowning_face:
Previously i couldn’t get any info on the currently playing audiostream but in this version i can, got this when playing some redbook material:

DietPi-JustBoom
─────────────────────────────────────────────────────
Mode: ALSA Output Info
Please wait…

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 551
buffer_size: 1102

Does the period and buffer size look reasonable? There are way different figures when looking at my Raspberry Pi 2B with Audiophonics SabreDAC:

DietPi-JustBoom
─────────────────────────────────────────────────────
Mode: ALSA Output Info
Please wait…

access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 882
buffer_size: 1764

For comparison, my nanoPi Neo (Which works beautifully with DietPi!):

DietPi-JustBoom
─────────────────────────────────────────────────────
Mode: ALSA Output Info
Please wait…

closed
closed
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 882
buffer_size: 1764

Period and buffer look the same as the Pi 2B but format matches the Tinkerboard

Yep buffer seems a little low.

Normally we can increase buffer size with asound.conf, however, Roon ignores this file and attaches directly to the hardware device.

Have you tried increasing the buffer size in Roon? It may have an effect on the ALSA buffer size, although, not sure.

Another option is to increase NRpacks:

  • Edit /etc/modprobe.d/nrpacks.conf
  • Add options snd-usb-audio nrpacks=20
  • reboot

Can check size of current NRpacks with:
cat /sys/module/snd_usb_audio/parameters/nrpacks

Thanks once again Dan for your support!
I have played a bit with the buffer size in Roon audio settings and it seems to affect the amount of ticks in the audiostream, less buffer (25ms) more ticks, more buffer (500ms) fewer ticks.
With the buffer set to 500ms and playing back RedBook material there are hardly any ticks at all and it sounds really nice! If i activate upsampling to “PCM, power of 2” the ticks become really annoying and way more freqent than if i lower the buffer to 25ms.

Not sure the nrpacks did anything really? And i cannot cat anything for your suggested path, there are no “nrpacks” available (after reboot)

The buffers seem to have been increased though, but these are directly related to the set buffer size in Roon Audio setup for the device:

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 11025
buffer_size: 22050
closed
closed

Hi Dan,

I’m experiencing a similar issue (small pops and clicks) using the Asus Tinker Board, DietPi 1.55 with the 4.4.71+ kernel, and a Chord Mojo, streaming into RoonBridge.
If I try to convert in Roon to 768KHz or DSD64 it becomes unlistenable.
I’ve also played around moving everything to the first 2 cores except RoonBridge, to which I’ve left the last two; this didn’t help.

A couple of hours ago I’ve set up a RPi3B which worked without issue; the only difference was the hardware.

Any ideas?

@Mikael_Ollars

Appears the Roon buffer has a direct impact on ALSA stream buffer and period size:

100ms
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 882
buffer_size: 1764
---------------------------
500ms:
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 11025
buffer_size: 22050

Yep, appears this value does not exist, unsure why at the moment.

Believe the otg options need to go into /boot/extlinux/extlinux.conf

[    0.000000] Kernel command line: earlyprintk quiet splash plymouth.ignore-serial-consoles console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init dwc_otg.fiq_split_enable=0 nrpacks=20 uboot_version=2017.07-gf7b0e94
[    2.280237] usb usb1: Manufacturer: Linux 4.4.71+ dwc2_hsotg
[    2.560653] usb usb2: Manufacturer: Linux 4.4.71+ dwc2_hsotg

Try editing /boot/extlinux/extlinux.conf to match:

label kernel-4.4
    kernel /zImage
    fdt /rk3288-miniarm.dtb
    append  earlyprintk quiet splash plymouth.ignore-serial-consoles console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init dwc_otg.fiq_split_enable=0 nrpacks=20

Hi Dan,

I have just tried this (see below) and the pops and clicks are still present unfortunately.
I’ve also tried with nrpacks=40, which seemed to be worse, and 10, which seemed to not make much difference from the baseline, but these observations are pretty subjective.
@Mikael_Ollars, did you have a different experience with this?
Btw, the /sys/module/snd_usb_audio/parameters/nrpacks does not show up after adding nrpacks to the kernel command line.

Please let me know if there are other things I could try!

root@asus:~# dmesg | grep -i otg
[ 0.000000] Kernel command line: earlyprintk quiet splash plymouth.ignore-serial-consoles console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init dwc_otg.fiq_split_enable=0 nrpacks=20 uboot_version=2017.07-gf7b0e94
[ 2.279797] dwc2 ff540000.usb: DWC OTG Controller
[ 2.280293] usb usb1: Product: DWC OTG Controller
[ 2.280307] usb usb1: Manufacturer: Linux 4.4.71+ dwc2_hsotg
[ 2.560293] dwc2 ff580000.usb: DWC OTG Controller
[ 2.560694] usb usb2: Product: DWC OTG Controller
[ 2.560708] usb usb2: Manufacturer: Linux 4.4.71+ dwc2_hsotg

Also:

root@asus:~# dmesg | grep -i dwc
[ 0.000000] Kernel command line: earlyprintk quiet splash plymouth.ignore-serial-consoles console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init dwc_otg.fiq_split_enable=0 nrpacks=20 uboot_version=2017.07-gf7b0e94
[ 2.279906] dwc2 ff540000.usb: DWC OTG Controller
[ 2.279955] dwc2 ff540000.usb: new USB bus registered, assigned bus number 1
[ 2.280006] dwc2 ff540000.usb: irq 47, io mem 0x00000000
[ 2.280404] usb usb1: Product: DWC OTG Controller
[ 2.280418] usb usb1: Manufacturer: Linux 4.4.71+ dwc2_hsotg
[ 2.559647] dwc2 ff580000.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM
[ 2.560412] dwc2 ff580000.usb: DWC OTG Controller
[ 2.560458] dwc2 ff580000.usb: new USB bus registered, assigned bus number 2
[ 2.560507] dwc2 ff580000.usb: irq 48, io mem 0x00000000
[ 2.560799] usb usb2: Product: DWC OTG Controller
[ 2.560813] usb usb2: Manufacturer: Linux 4.4.71+ dwc2_hsotg
[ 2.669631] usb 1-1: new high-speed USB device number 2 using dwc2
[ 3.472719] dwhdmi-rockchip ff980000.hdmi: Detected HDMI TX controller v2.00a with HDCP (DWC MHL PHY)

Yep, i saw the same thing and corrected my previous post.

I performed the suggested change to extlinux_conf and rebooted

My experience is shared wih @Radu_Popescu, that is no clear difference in amount of ticks…

I am experiencing;
A few pops and ticks @44.1Khz & 250/500ms buffer. Say one audible tick every 20-30sec?
A lot more if i upsample to PCM (power of 2, usually 352.8 or 384Khz) or DSD64/128, were talking pops and ticks every second. Unlistenable.

Thanks to both of you for your input on this! I am using an Audiobyte Black Dragon which is very stable on its USB input. Where my Chord Mojo pops and stutters on DSD and sometimes on PCM >700Khz (on all Bridges i have tried, but more on my SBC’s) rates the Black Dragon is exeptionally stable.

Oh, i forgot to mention;
Very subjectively i have a feeling that when playing back @44.1Khz through the Tinker Board the audio result is a bit “jittery” or nervous. I hear somewhat spotlit sibilances and similar “digital” artefacts that are mostly invisible on Raspberry Pi2/3 and Nano Pi Neo.
Other than that the audio is detailed and dynamic, seemingly very good potential for this board if we can figure this out!

Thanks for the update Mikael.
When connected to my laptop, my Mojo has never had any issues with playback of anything including DSD. On the RPi3 I have only tried standard resolution yesterday, as soon as I get another micro SD I will be able to switch between the two SBCs more easily.
Just in case this was not clear: the onboard audio works just fine on the Asus, tested with the same music, same headphones.
@Mikael_Ollars, does Volumio not show these issues?

Which audio output do you select in Roon to get audio directly? I havent been able to retrieve anything from the built in 3.5mm jack…

And no, i didn’t hear any pops and clicks with Volumio, but on the other hand i; 1. did not upsample anything 2. Didnt actually listen to one whole song before i got fed up with the interface…

And, like you i havent got a spare microSD to test simultaneously… :confused:

I don’t know anything about Volumio, I thought you ran RoonBridge on it as well?
Here is the headphone out setup, see images.
Weird how 88.2 is missing, isn’t it?

Hi guys,

Thanks for testing.
The only thing I can suggest is to try adding all of these to kernel command line options.

eg:

label kernel-4.4
    kernel /zImage
    fdt /rk3288-miniarm.dtb
    append  earlyprintk quiet splash plymouth.ignore-serial-consoles console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init dwc_otg.fiq.lpm_enable=0 dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3 dwc_otg.fiq_split_enable=0 dwc_otg.sped=1 nrpacks=20

Failing that, its most likely a case of waiting for kernel related fixes from ASUS, to improve USB stack.

Appreciate your efforts @Dan_Knight!

There was no change in behaviour with the other otg-instructions.

I wanted to have a look at what Volumio could offer so i installed the Roon Bridge on the Volumio image. It is an older Kernel in use on this image, 4.4.16…

But, with the Roon Bridge installed i can upsample all i want and there are NO ticks and pops at all… Not with PCM352.8/384 or DSD64/128…

I’ll gladly report any data from the streams if this can be of any help in getting this to work on DietPi?

Hi Dan,

Unless I’m mistaken, these dwc_otg parameters are for a kernel module, right? If that’s the case, lsmod shows just the Realtek wifi module loaded (8723bs), and all of these parameters are not making any difference? To wit, the fiq_split_enable=0 should summon a line to appear in the kernel log, which it definitely does not; in fact, there’s no FIQ related stuff in my dmesg output.

Anyway, I have very interesting news!
I’ve used dietpi-config to set the cpufreq governor to ‘performance’, and the clicks and pops stopped. I’ve enabled DSP in Roon to see how much it can take and it can do DSD64, 128 and for a while 256; this last one I think is limited by the network bandwidth over wifi, and I’m sure it would work just fine over a wired connection (playback just stops, isn’t scratchy or glitchy).
At this point, the CPU frequency was shown to be 1800MHz.
For some reason the CPU reached 64C and then I think some frequency scaling kicked in, and it went to 1608MHz. At this point, the clicks and pops returned when playing even 16/44100.
I proceeded to install cpufrequtils, and created /etc/default/cpufrequtils with the contents:

GOVERNOR=“performance”

and rebooted. I did all this because I’ve no idea how dietpi-config sets the governor and how/if it’s persisted after reboot.

I’ve got a basic plastic case for the RPi3, and had placed the provided heatsink on the SOC.
With the case top off, it stays at 53-55C, 1800MHz playing 16/41000 without any issues; cpufreq-info reports it’s been at 1800MHz for 99.56% of the time, so no throttling to speak of.

Very interesting: I’ve manually dropped the frequency to 1608 MHz, and it still plays fine… I’ve further reduced it to 1GHz, and finally 408MHz, and it still plays fine… even DSD128, as in the attached image.

So whatever the CPU frequency governor “performance” does, it does well, and the frequency isn’t the key; it’s a power state setting, or something else that affects latency.

1 Like