Raspberry Pi Zero W sound crackles every few seconds

[heinzgruber]

hi, I'm using a Raspberry Pi Zero W with Raspian Lite, Raspotify and Shairport-sync (AirPlay) connect via USB to a DAC (RME ADI-2 DAC) and playing music via WLAN.

Unfortunately during playback with Raspotify or Airplay sound crackles every few seconds. Anyone has an idea? Maybe the Zero is too weak for playback?

Here some stats via bcmstat.sh:

same installation working on a Raspi 3 without crackles.

thanks

[JasonLG1979]

A couple questions?

1. Have you overclocked the Pi Zero? If not I would advise it. The Pi Zero is not thermally limited. Meaning that even if you overclock it and force turbo to disable frequency scaling and force it to always run at it's max clock speed it will never overheat.

I always run my Pi Zero with these setting in /boot/config.txt

gpu_mem=16
arm_freq=1100
over_voltage=8
core_freq=500
sdram_freq=500
force_turbo=1

Your results may vary if you notice any instability just lower the freq numbers until it's stable. Also please note that this will more than likely void the warranty on your Pi Zero.

2. Do you do any upsampling? The Pi Zero (unless overclocked) is not powerful enough to resample audio reliably. I would avoid resampling at all costs.

[JasonLG1979]

It might also help to completely disable Bluetooth if you're not using it.

[heinzgruber]

Thanks!

I'll try you advices and give feedback.

In alsa config I've changed samplerate from 48000 to 44100 because that's Spotify's native format. So this down sampling is to much for the Zero?

You using Raspotify on your Zero without Problems? Maybe the running Airplay client besides Spotify Connect is too much for the zero?

[JasonLG1979]

In alsa config I've changed samplerate from 48000 to 44100 because that's Spotify's native format. So this down sampling is to much for the Zero?

It really depends on what resampling algorithm you use and how much CPU Shairport-sync uses during idle. If it's set to 44.1 it's not resampling librespot so it shouldn't be using any extra CPU. Librespot should only be using like 20% CPU during normal use and maybe 50% spikes when it's caching a song. Librespot also shouldn't be affecting Shairport-sync as it doesn't really use any CPU at all when it's idle. i'd be looking really hard at Shairport-sync.

You using Raspotify on your Zero without Problems? Maybe the running Airplay client besides Spotify Connect is too much for the zero?

Yep. The Pi Zero is librespot's official "potato" (lowest spec target device) I've done reasonably extensive non-scientific testing though this whole release cycle to make sure librespot will run on a Pi Zero without a problem. I don't run any other services on the Pi Zero though. It's basically just a Spotify Connect appliance. The general idea being that a Pi Zero isn't really a multitasking device.

[JasonLG1979]

Here's an example of basically a default Raspberry Pi OS install (overclocked) running raspotify with the librespot binary replaced with a binary I compiled to test a PR branch. Since librespot is the only thing making noise I bypass dmix because I don't need software mixing. Bypassing dmix also means that no resampling is ever done. Notice that the CPU is at 12.4% and librespot is only using a little over 10%. Pausing causes librespot to go to under 2%.

[heinzgruber]

How do you bypass dmix?

Spotify Connect playing (see screenshot). In the moment i switch on my DAC (RME ADI-2 DAC) cpu goes from 35 to 100% (mostly about 40%) and it crackles. When the DAC is off and it's still playing CPU is about 10%.

Raspian Lite is up to date. Configuread the DAC in Alsa config defaults.ctl.card 1 defaults.pcm.card 1. DAC is USB Class Compliant. Any idea to get this fixed? Thanks.

Edit: Tried another DAC (Quedelix 5K) CPU from 25-35% no crackles.

It's crazy how much CPU raspotify uses when a DAC is connected. Maybe someone can optimize the code?

[JasonLG1979]

How do you bypass dmix?

You'll need dmix for the software mixing if you have both Shairport-sync and librespot making noise. Otherwise when you switch between the 2 there's a chance that one will crash. Without software mixing generally only one app at a time can play audio, and switching between audio services without a mechanism to make sure 1 has fully given up control of the DAC before the other tries to grab it is asking for something to crash.

Spotify Connect playing (see screenshot). In the moment i switch on my DAC (RME ADI-2 DAC) cpu goes from 35 to 100% (mostly about 40%) and it crackles. When the DAC is off and it's still playing CPU is about 10%.

Raspian Lite is up to date. Configuread the DAC in Alsa config defaults.ctl.card 1 defaults.pcm.card 1. DAC is USB Class Compliant. Any idea to get this fixed? Thanks.

Edit: Tried another DAC (Quedelix 5K) CPU from 25-35% no crackles.

It's crazy how much CPU raspotify uses when a DAC is connected. Maybe someone can optimize the code?

Let's go ahead and disable Shairport-sync and bypass dmix to make 100% sure no resampling is being done. 1st disable sharepoint. I have never used it so you'll have to figure that out. I would assume it runs as a systemd service but again I don't know.

Add --device hw:1,0 (inside the "" with the rest of the args for that section) to one of the uncommitted sections of /etc/default/raspotify It really doesn't matter which one, the args are parsed as just a long string. The sections are just a convenience to more logically group the args so it's not one huge list of args.

Now restart the raspotify service with sudo systemctl restart raspotify. Dmix should now be completely bypassed.

[heinzgruber]

Let's go ahead and disable Shairport-sync and bypass dmix to make 100% sure no resampling is being done. 1st disable sharepoint. I have never used it so you'll have to figure that out. I would assume it runs as a systemd service but again I don't know.

Add --device hw:1,0 (inside the "" with the rest of the args for that section) to one of the uncommitted sections of /etc/default/raspotify It really doesn't matter which one, the args are parsed as just a long string. The sections are just a convenience to more logically group the args so it's not one huge list of args.

Now restart the raspotify service with sudo systemctl restart raspotify. Dmix should now be completely bypassed.

killed sharpoint-sync and put --device hw:1,0 in raspotify config. Alsamixer says DAC is connected but the DAC gets no audio signal. Maybe I've to alter Alsa config (defaults.ctl.card 1 defaults.pcm.card 1)?

[JasonLG1979]

killed sharpoint-sync and put --device hw:1,0 in raspotify config. Alsamixer says DAC is connected but the DAC gets no audio signal. Maybe I've to alter Alsa config (defaults.ctl.card 1 defaults.pcm.card 1)?

The ALSA config doesn't really mean anything when address the hardware directly with the --device arg. Try --device hw:1,1 Otherwise show me the outputs of aplay -l and aplay -L.

[heinzgruber]

--device hw:1,1 no sound too.

aplay -l List of PLAYBACK Hardware Devices card 1: DAC58580301 [ADI-2 DAC (58580301)], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0

abplay -L null Discard all samples (playback) or generate zero samples (capture) default:CARD=DAC58580301 ADI-2 DAC (58580301), USB Audio Default Audio Device sysdefault:CARD=DAC58580301 ADI-2 DAC (58580301), USB Audio Default Audio Device front:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio Front speakers surround21:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio 2.1 Surround output to Front and Subwoofer speakers surround40:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio 4.0 Surround output to Front and Rear speakers surround41:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio IEC958 (S/PDIF) Digital Audio Output dmix:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio Direct sample mixing device dsnoop:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio Direct sample snooping device hw:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio Direct hardware device without any conversions plughw:CARD=DAC58580301,DEV=0 ADI-2 DAC (58580301), USB Audio Hardware device with all software conversions

[JasonLG1979]

OK. Show me the output of: aplay -Dhw:CARD=DAC58580301,DEV=0 --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav

It will most likely fail to play anything because it's a mono file but it should tell us the capabilities of the DAC as far as the driver reports it.

As an example the output for my cheap little dac hat is this:

 --------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE S24_LE S32_LE
SUBFORMAT:  STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [8000 192000]
PERIOD_TIME: (166 8192000]
PERIOD_SIZE: [32 65536]
PERIOD_BYTES: [256 524288]
PERIODS: [2 4096]
BUFFER_TIME: (333 16384000]
BUFFER_SIZE: [64 131072]
BUFFER_BYTES: [256 524288]
TICK_TIME: ALL
--------------------

[JasonLG1979]

Next we will do a speaker test that plays pink noise at 16 bit 44.1 to see if we get crackles.

speaker-test -Dhw:CARD=DAC58580301,DEV=0 -c2 -r44100 -FS16_LE

This is at 80% scale so turn your amp/stereo down.

To stop it press Ctrl + c to kill it.

[heinzgruber]

OK. Show me the output of: aplay -Dhw:CARD=DAC58580301,DEV=0 --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav

ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 64 CHANNELS: 2 RATE: [44100 768000] PERIOD_TIME: [125 1486078) PERIOD_SIZE: [8 65536] PERIOD_BYTES: [64 524288] PERIODS: [2 1024] BUFFER_TIME: (20 2972155) BUFFER_SIZE: [16 131072] BUFFER_BYTES: [128 1048576] TICK_TIME: ALL

aplay: set_params:1339: Sample format non available Available formats:

• S32_LE

[heinzgruber]

Next we will do a speaker test that plays pink noise at 16 bit 44.1 to see if we get crackles.

speaker-test -Dhw:CARD=DAC58580301,DEV=0 -c2 -r44100 -FS16_LE

This is at 80% scale so turn your amp/stereo down.

speaker-test 1.1.8

Playback device is hw:CARD=DAC58580301,DEV=0 Stream parameters are 44100Hz, S16_LE, 2 channels Using 16 octaves of pink noise Sample format not available for playback: Invalid argument Setting of hwparams failed: Invalid argument

it doesn't work: no sound

EDIT: speaker-test -Dhw:CARD=DAC58580301,DEV=0 -c2 -r44100 -FS32_LE

is working: no crackles

It seems that ma DAC is only operating with 32 Bit. Now I need a way to configure rapsotify with 32 bit.

[JasonLG1979]

is working: no crackles

It seems that ma DAC is only operating with 32 Bit. Now I need a way to configure rapsotify with 32 bit.

The pink noise is synthesized AFAIK meaning it's native 32 bit. The version of librespot currently used by raspotify is 16 bit only. Dmix should be able to convert 16 to 32 without any problems. That shouldn't be costly CPU wise. I'm not sure what's going on there? The latest release has native 32 bit support but that doesn't really help you with Shairport-sync though?

[heinzgruber]

I don't know whats going on. only the speaker test plays without crackles. Raspotify still crackles. No matter what I do.

Later I'll delete the SD card an do a clean install.

[heinzgruber]

okay. i give up!

clean installation only raspian lite an raspotify, default settings, bluetooth deactivated, overlocked to 1,1 GHz: sound crackles.

I guess the raspberry pi zero w don't work with my DAC. so I'm switching to my Raspi 3 for raspotify. works like a charm.

[JasonLG1979]

I guess the raspberry pi zero w don't work with my DAC. so I'm switching to my Raspi 3 for raspotify. works like a charm.

I'm at a loss? Like I said converting from 16 bit to 32 bit shouldn't use really any CPU, it's just basically padding the bottom 16 bits with silence.

When raspotify updates librespot you'll get native 32 bit from librespot so that may well solve your problems?

[heinzgruber]

When raspotify updates librespot you'll get native 32 bit from librespot so that may well solve your problems?

Yes well see.

Thanks for your help. Much appreciated.

[JasonLG1979]

Yes well see.

Thanks for your help. Much appreciated.

They have some fresh blood and development is starting to move much more rapidly. They are getting ready to release 0.3.0 I am compiling it to use and test on my Pi Zero. If you would like I could provide you a link to that binary that you can use to test to and see if native 32 bit fixes your issue. If it does it's pretty simple to replace the librespot binary with that version in the meantime until 0.3.0 is officially released and rapsotify is updated to that version.

[heinzgruber]

Yes. Send me a link please.

I'm a Linux newbie and wonder how I install the deb. Currently the raspotify 0.16.0 is installed.

I wonder too which parameter I've to set in raspotiy config. Maybe FORMAT="S32" Output of my DAC shows S32_LE

[JasonLG1979]

Yes. Send me a link please.

I'm a Linux newbie and wonder how I install the deb. Currently the raspotify 0.16.0 is installed.

I wonder too which parameter I've to set in raspotiy config. Maybe FORMAT="S32" Output of my DAC shows S32_LE

OK I'm compiling a PR branch right now. If it works as expected I will provide you a link to download the binary and write a quick tutorial on how to test it tomorrow and if all goes well with the test I can also provide instructions on how to replace the binary used by raspotify as a stop gap in the meantime until 0.3.0 is released.

[JasonLG1979]

Here you go @heinzgruber I've complied a couple binaries for testing purposes instructions are here.

[heinzgruber]

Here you go @heinzgruber I've complied a couple binaries for testing purposes instructions are here.

Great thanks. Will try it later. Can I install it on a raspian with Raspotify already installed? Or only On a fresh raspian?

[JasonLG1979]

Great thanks. Will try it later. Can I install it on a raspian with Raspotify already installed? Or only On a fresh raspian?

It's a binary. You don't need to install anything. Just download it, make it executable and run it in a terminal. Just to rule everything out I'd start with a fresh install of Raspberry Pi OS Lite. Headless (no UI) is the way to go with a Pi Zero.

Here are the args I use with librespot:

./librespot -n "PiZero" -b 320 --format S32  --enable-volume-normalisation --normalisation-pregain 3 --normalisation-gain-type track --initial-volume 100 --volume-ctrl fixed --device hw:0,0 --disable-audio-cache --autoplay

• -n "PiZero" is the name of the device. It can be pretty much whatever you want.

• -b 320 is the bitrate of the music, as in 320 kbps vorbis.

• --format S32 tells librespot to output S32_LE (32 bit).

• --enable-volume-normalisation --normalisation-pregain 3 This matches Spotify's default auto volume leveling (ReplayGain).

• --normalisation-gain-type track Tells librespot to use track mode for ReplayGain volume normalisation.

• --initial-volume 100 --volume-ctrl fixed Sets the volume to 100% and disables volume control (I use the knob on my receiver)

• --device hw:0,0 Tells librespot to use my DAC directly. You would need to change that to --device hw:CARD=DAC58580301,DEV=0.

• --disable-audio-cache Tells librespot not to download tracks to the SD card, just buffer them into memory.

• --autoplay Tells librespot to keep playing similar songs after a playlist is over.

If you don't want volume leveling you can just leave out all of the related args. No normalisation, fixed volume at 100%, direct into your DAC at 32 bit is as close as you're going to get to "bit-perfect" from Spotify until they fully roll out their HiFi lossless tier. Although all internal audio processing in the dev branch (so the binary I provided) is done in 64 bit floating point and then converted to 32 bit right before your DAC so assuming the source audio prior to encoding into vorbis was 16 bit you're looking at around 96dB of digital volume attenuation until any bits are "thrown away". So software volume control and volume normalisation shouldn't be detrimental to sound quality.

[heinzgruber]

Thanks for your feedback. I'm using your binary with

./librespot -n "PiZero" -b 320 --format S32 --initial-volume 100 --volume-ctrl fixed --device hw:1,0 --disable-audio-cache --autoplay

but sound crackles are still there. :( As I said with my other DAC (Quedelix 5K) everything is perfect with the actual Raspotify release.

with --format F32 it crashes S16 no sound. I don't know if this help but speaker-test worked with -FS32_LE flawlessly without crackles.

[Nuke142]

I can confirm. I have zero W and Creative Sound Blaster G6 as DAC. I hear cracking sound. Update above not helped (file was downloaded and replaced - see librespot 0.2.0 33c07f0 (Built on 2021-06-02, Build ID: CNFDrudt) in log) No cracks when i do white noise test. Cracks persist when play spotify.

pi@raspberrypi:~ $ aplay -Dhw:CARD=G6,DEV=0 --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
HW Params of device "hw:CARD=G6,DEV=0":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S32_LE S24_3LE
SUBFORMAT:  STD
SAMPLE_BITS: [24 32]
FRAME_BITS: [48 64]
CHANNELS: 2
RATE: [44100 48000]
PERIOD_TIME: (166 1981429)
PERIOD_SIZE: [8 87381]
PERIOD_BYTES: [64 524288]
PERIODS: [2 1024]
BUFFER_TIME: (333 3962858)
BUFFER_SIZE: [16 174762]
BUFFER_BYTES: [96 1048576]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S32_LE
- S24_3LE

--format S32_LE not working for me:

pi@raspberrypi:~ $ /usr/bin/librespot --name rasp --device-type speaker --backend alsa --bitrate 320 --volume-ctrl linear --initial-volume :1,0 --format S32_LE
[2021-06-03T15:46:05Z INFO  librespot] librespot 0.2.0 33c07f0 (Built on 2021-06-02, Build ID: CNFDrudt)
thread 'main' panicked at 'Invalid output format: ()', src/main.rs:448:53

I also have other DAC - SMSL sk10, but can test it only few days latet (don't have cables). I guess it will have same problems

pi@raspberrypi:~ $ aplay -Dhw:CARD=S10th,DEV=0 --dump-hw-params /usr/share/sounds/alsa/Front_Right.wav                                     Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
HW Params of device "hw:CARD=S10th,DEV=0":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S32_LE SPECIAL DSD_U32_BE
SUBFORMAT:  STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: [44100 384000]
PERIOD_TIME: [125 1486078)
PERIOD_SIZE: [8 65536]
PERIOD_BYTES: [64 524288]
PERIODS: [2 1024]
BUFFER_TIME: (41 2972155)
BUFFER_SIZE: [16 131072]
BUFFER_BYTES: [128 1048576]
TICK_TIME: ALL
--------------------
aplay: set_params:1339: Sample format non available
Available formats:
- S32_LE
- SPECIAL
- DSD_U32_BE

[JasonLG1979]

S32_LE isn't a valid value for format try just S32.

[Nuke142]

with --format S32 it's working but crackles still persist. I found that crackles much more just after song start. If i pause it after start and wait 5 seconds (Zero W can do 2-3MB/s via WiFi), then resume - crackles almost gone, but not 100%. I wonder if Pi Zero W cpu so bad for song listening.. I see 60-70% cpu load when song downloading and playing, and 20-35% when playing only.

[heinzgruber]

it seems like libresport on the Raspi zero has problems with devices which only do 32 bit. as I said my other DAC (Qudelix 5K) is 16 Bit and plays perfect with my Raspi zero.

[Nuke142]

One of my devices can 16 bit too: https://us.creative.com/p/sound-blaster/sound-blasterx-g6 but aplay shows support only of 24 and 32

[Nuke142]

Well, i have same problems with Moode Audio, so..

[JasonLG1979]

I see 60-70% cpu load when song downloading and playing, and 20-35% when playing only.

That's not horrible. The Pi Zero isn't a multi-tasking beast or anything but I've never had any problems. librespot should run just fine so long as that's basically all the Pi Zero is doing.

it seems like libresport on the Raspi zero has problems with devices which only do 32 bit. as I said my other DAC (Qudelix 5K) is 16 Bit and plays perfect with my Raspi zero.

My DAC HAT is 32 bit and it runs just fine. It really shouldn't matter so long as your DAC supports whatever you're telling librespot to output. There's very little overhead when you bypass dmix. librespot is basically talking directly to the DAC.

One of my devices can 16 bit too: https://us.creative.com/p/sound-blaster/sound-blasterx-g6 but aplay shows support only of 24 and 32

Well, i have same problems with Moode Audio, so..

If I had to guess it's probably a hardware quirk. AFAIK, in theory as long as a USB DAC is compliant with the USB audio spec it should just work, in reality just like any other spec not all hardware manufacturers follow them to the letter. Not to mention that Raspberry Pi OS is based off of Debian stable which tends to lag a far bit behind the bleeding edge. Have either of you tried your DACs on a X86_64 desktop Linux distro?

I've used a Pi Zero with raspotify and bare librespot for a while now on 2 different USB DACs and a DAC HAT and never had any problems.

It's a bummer but it looks like you guys just have the bad luck of owning 2 different DACs that just don't play well with others.

[heinzgruber]

It's a bummer but it looks like you guys just have the bad luck of owning 2 different DACs that just don't play well with others.

yes but it's strange that the same installation and problematic DAC works flawlessly on my Raspi 3. So the Raspi Zero is part of the problem. Also the DAC is Class Compliant and works without problems under Ubuntu.

[JasonLG1979]

yes but it's strange that the same installation and problematic DAC works flawlessly on my Raspi 3. So the Raspi Zero is part of the problem. Also the DAC is Class Compliant and works without problems under Ubuntu.

The Pi Zero is an ARMv6 chip where as the Pi 3 is a ARMv8 chip so off the top they are different architectures (sub-architectures?)

The only other Pi I have is a Pi 4 running 64 bit Raspberry Pi OS Lite so I can't test this for sure but I want to say that the 32 bit version of Raspberry Pi OS is dual ARMv6/ARMv7? As in programs are compiled for v6 because v6 binaries will run under a v7 kernel but what kernel you get depends on what Pi you're booting on.

I could very well be mistaken of that but you can test it out by running uname -a on both your Pi Zero and Pi 3 to see if they're running the same kernel. If they aren't that could be the reason that the DAC works fine on one and not the other since drivers live in the kernel.

[JasonLG1979]

There's also the fact that the Pi 3 is many orders of magnitude more powerful than a Pi Zero. All other things being equal, a task that would cripple a Pi Zero might not be a problem to a Pi 3. Basically the bug could still exist when using a Pi 3 but you don't notice it because 100% CPU on the Pi Zero might only be 20% on a Pi 3.

[Nuke142]

Please ignore my problems here. All of this because of usb power-board that was attached to second-hand rpi i bought (https://www.elecrow.com/usb-hub-powermanager-for-rpi-zero-v1-0.html) Disconnected it and used simple pc usb hub via micro usb port on rpi zero w. No crackles or other sound issues. Works like a charm.

[dromeo79]

I have been able to reproduce audio crackling when skipping to next song for the first few seconds of the next song. Using an Orange Pi Zero LTS with audio and USB hat. It was related to under-powered USB. Changed power source and crackles went away.

It is worth noting the crackles only happened when manually advancing to next song. Letting songs play from a playlist did not induce any crackling when the next song would play.

[JasonLG1979]

@dromeo79 what you're hearing is the sink opening and closing. Not related and in fact I may have already fixed it upstream in librespot when I basically rewrote the alsa backend a while back.

Anyway no matter what both issues are upstream issues.

[bverkron]

...my other DAC (Qudelix 5K) is 16 Bit and plays perfect with my Raspi zero.

@heinzgruber did you have to do anything special to get your Qudelix to work? Mine is extremely choppy (if I can get it to play at all which is hit and miss) and cuts in/out rapidly. Headphone jack directly on the Pi works fine. Running on a Pi 3 b v1.2

[JasonLG1979]

@heinzgruber did you have to do anything special to get your Qudelix to work? Mine is extremely choppy (if I can get it to play at all which is hit and miss) and cuts in/out rapidly. Headphone jack directly on the Pi works fine. Running on a Pi 3 b v1.2

I would start by running it though a powered hub to rule out the possibility of under-powered USB from the Pi.

I would then run librespot in debug mode and see if it sheds any light on what's going on with librespot -v.

[bverkron]

Thanks for the response and advice @JasonLG1979. After making the comment I found this in the troubleshooting section for shairport-sync which is what I'm actually using. https://github.com/mikebrady/shairport-sync/blob/master/TROUBLESHOOTING.md#stuttering-audio-on-certain-usb-dacs-such-as-the-creative-soundblaster-mp3

I should have looked there first but it was eerily similar to another issue I was having with the Qudelix elsewhere and I got down a search rabbit hole.

[JasonLG1979]

Thanks for the response and advice @JasonLG1979. After making the comment I found this in the troubleshooting section for shairport-sync which is what I'm actually using. https://github.com/mikebrady/shairport-sync/blob/master/TROUBLESHOOTING.md#stuttering-audio-on-certain-usb-dacs-such-as-the-creative-soundblaster-mp3

I should have looked there first but it was eerily similar to another issue I was having with the Qudelix elsewhere and I got down a search rabbit hole.

Buffer settings was going to be my next suggestion. Looks like you hopefully found the issue.

[bverkron]

Looks like you hopefully found the issue.

Forgot to specifically say so but it worked :)

[JasonLG1979]

Good deal.