[GH-ISSUE #153] Airplay1/RAOP stutter

kerem commented

2026-02-27 19:28:19 +03:00

Owner

Originally created by @jurajs5 on GitHub (Feb 8, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/153

sound is very fragmented, spotify not playing at all

lox-audioserver-logs-2026-02-08T13-16-01-517Z.txt

Originally created by @jurajs5 on GitHub (Feb 8, 2026). Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/153 sound is very fragmented, spotify not playing at all [lox-audioserver-logs-2026-02-08T13-16-01-517Z.txt](https://github.com/user-attachments/files/25161356/lox-audioserver-logs-2026-02-08T13-16-01-517Z.txt)

kerem commented

2026-02-27 19:28:19 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 8, 2026):

Could you try re-adding your spotify account? Your log is full of failed login attempts for the spotifyconnect instances

@rudyberends commented on GitHub (Feb 8, 2026): Could you try re-adding your spotify account? Your log is full of failed login attempts for the spotifyconnect instances

kerem commented

2026-02-27 19:28:19 +03:00

Author

Owner

@Holzmusik commented on GitHub (Feb 8, 2026):

lox-audioserver-logs-2026-02-08T17-15-51-739Z.txt

Unfortunately, the same problem occurs here; the music, regardless of the source, constantly stutters. Spotify doesn't work at all for me with the songs I tested. But now there's Radio Paradise, which is amazing!!!! It stutters too, though 🙈

I've completely removed Spotify, but the dropouts are still happening, unfortunately 😔

@Holzmusik commented on GitHub (Feb 8, 2026): [lox-audioserver-logs-2026-02-08T17-15-51-739Z.txt](https://github.com/user-attachments/files/25163100/lox-audioserver-logs-2026-02-08T17-15-51-739Z.txt) Unfortunately, the same problem occurs here; the music, regardless of the source, constantly stutters. Spotify doesn't work at all for me with the songs I tested. But now there's Radio Paradise, which is amazing!!!! It stutters too, though 🙈 I've completely removed Spotify, but the dropouts are still happening, unfortunately 😔

kerem commented

2026-02-27 19:28:19 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 8, 2026):

The audio server has a fairly complex signal path (input source → audio engine → output), and without the right context it’s extremely difficult to troubleshoot. Most issues are highly setup-specific.

For that reason, I wouldn’t release a new radio feature if it wasn’t 100% dropout-free in my own testing.

Beta5 is primarily tuned for performance. All debug and test code has been removed, and playback startup across all sources is now almost instant. To achieve this, buffering has been reduced significantly. This improves responsiveness, but it also means the system is more sensitive to network quality and hardware performance.

With a slow or unstable network, or on underpowered hardware, the buffer can drain very quickly, which may result in dropouts. Fast startup inherently comes at the cost of having less margin for poor network or hardware conditions.

After startup, audio still goes through the full audio engine and is routed to the selected output. I cannot test every output type, as I don’t have access to all hardware. I have done extensive testing on my own setup and can guarantee hours of uninterrupted playback there. However, a setup that works perfectly for me may still behave differently in other environments.

Spotify is currently difficult to validate as well. I don’t use Spotify myself and created a test account specifically for the audio server, but due to recent Spotify changes (which seem to affect new accounts), I’m currently unable to test it.

If you are experiencing issues, please make sure you are running the latest beta (beta5), and then provide:

The exact input source (Radio, TTS, Bell, Spotify, AirPlay, Cast, Local, etc.)
The exact output type and device
Whether the issue occurs with all inputs (if so, this strongly points to an output-side issue)
SPAM-level logs starting from the beginning of playback, so the full setup and routing context is available

preferably In separate issues. I understand that the symptoms may look similar, but given the different outputs you are using, I highly doubt this is the same underlying problem. Keeping them separate will make it much easier to investigate and avoid mixing unrelated root causes.

@rudyberends commented on GitHub (Feb 8, 2026): The audio server has a fairly complex signal path (input source → audio engine → output), and without the right context it’s extremely difficult to troubleshoot. Most issues are highly setup-specific. For that reason, I wouldn’t release a new radio feature if it wasn’t 100% dropout-free in my own testing. Beta5 is primarily tuned for performance. All debug and test code has been removed, and playback startup across all sources is now almost instant. To achieve this, buffering has been reduced significantly. This improves responsiveness, but it also means the system is more sensitive to network quality and hardware performance. With a slow or unstable network, or on underpowered hardware, the buffer can drain very quickly, which may result in dropouts. Fast startup inherently comes at the cost of having less margin for poor network or hardware conditions. After startup, audio still goes through the full audio engine and is routed to the selected output. I cannot test every output type, as I don’t have access to all hardware. I have done extensive testing on my own setup and can guarantee hours of uninterrupted playback there. However, a setup that works perfectly for me may still behave differently in other environments. Spotify is currently difficult to validate as well. I don’t use Spotify myself and created a test account specifically for the audio server, but due to recent Spotify changes (which seem to affect new accounts), I’m currently unable to test it. If you are experiencing issues, please make sure you are running the latest beta (beta5), and then provide: - The exact input source (Radio, TTS, Bell, Spotify, AirPlay, Cast, Local, etc.) - The exact output type and device - Whether the issue occurs with all inputs (if so, this strongly points to an output-side issue) - SPAM-level logs starting from the beginning of playback, so the full setup and routing context is available preferably In separate issues. I understand that the symptoms may look similar, but given the different outputs you are using, I highly doubt this is the same underlying problem. Keeping them separate will make it much easier to investigate and avoid mixing unrelated root causes.

kerem commented

2026-02-27 19:28:19 +03:00

Author

Owner

@Holzmusik commented on GitHub (Feb 8, 2026):

Hello,

I'm fully aware that you tested the software and didn't encounter this problem. The error message here isn't meant to be offensive!

The problem I'm currently experiencing, even after testing with the latest beta version, affects my player when it's configured as a Squeezelite player. I can rule out network issues, as it works perfectly fine outside of Lox Audio Server. The player is also connected to a Gigabit LAN. Attached is a log file for the situation with a TuneIn low-resolution stream, which normally runs without problems.

lox-audioserver-logs-2026-02-08T18-10-47-922Z.txt

@Holzmusik commented on GitHub (Feb 8, 2026): Hello, I'm fully aware that you tested the software and didn't encounter this problem. The error message here isn't meant to be offensive! The problem I'm currently experiencing, even after testing with the latest beta version, affects my player when it's configured as a Squeezelite player. I can rule out network issues, as it works perfectly fine outside of Lox Audio Server. The player is also connected to a Gigabit LAN. Attached is a log file for the situation with a TuneIn low-resolution stream, which normally runs without problems. [lox-audioserver-logs-2026-02-08T18-10-47-922Z.txt](https://github.com/user-attachments/files/25164183/lox-audioserver-logs-2026-02-08T18-10-47-922Z.txt)

kerem commented

2026-02-27 19:28:19 +03:00

Author

Owner

@jurajs5 commented on GitHub (Feb 8, 2026):

Fully understand your point, however i really thing that streaming issues are really not based on HW or interent connection issue.

internet setup 250/250mbit - stable and under constant monitoring, latency is 3-5ms
testing tunein and spotify
testing in two environments:
- VMware virtual machine 2cores, 4GB RAM, 16GB disk, DietPi OS
- RPI 4, same DietPi. OS

I have same issues on both systems. I have "old" virtual music server on another virtual machine and stream is perfect without any issues. They are on same HW with same config and in same VLAN.

@jurajs5 commented on GitHub (Feb 8, 2026): Fully understand your point, however i really thing that streaming issues are really not based on HW or interent connection issue. - internet setup 250/250mbit - stable and under constant monitoring, latency is 3-5ms - testing tunein and spotify - testing in two environments: - VMware virtual machine 2cores, 4GB RAM, 16GB disk, DietPi OS - RPI 4, same DietPi. OS I have same issues on both systems. I have "old" virtual music server on another virtual machine and stream is perfect without any issues. They are on same HW with same config and in same VLAN.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@anlx-sw commented on GitHub (Feb 9, 2026):

is your spotify app pointing to the new callback url?

@anlx-sw commented on GitHub (Feb 9, 2026): is your spotify app pointing to the new callback url?

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 10, 2026):

Hello,

I'm fully aware that you tested the software and didn't encounter this problem. The error message here isn't meant to be offensive!

The problem I'm currently experiencing, even after testing with the latest beta version, affects my player when it's configured as a Squeezelite player. I can rule out network issues, as it works perfectly fine outside of Lox Audio Server. The player is also connected to a Gigabit LAN. Attached is a log file for the situation with a TuneIn low-resolution stream, which normally runs without problems.

lox-audioserver-logs-2026-02-08T18-10-47-922Z.txt

Thanks for clarifying. No worries at all — I didn’t take it as offensive in any way.

The point I was trying to make is that it really helps to keep separate problems in separate issues. Even if the symptoms look similar on the surface, mixing them makes troubleshooting very difficult.

In the case of jurajs5, the problem is clearly related to the AirPlay output. Even though I can’t reproduce it locally yet, the issue is very clearly visible in the logs.

In your case, if you’re seeing the problem with all inputs and only when the player is configured as Squeezelite, then this points to a Squeezelite-specific issue, not the same AirPlay problem. Let’s continue investigating that under the existing Squeezelite issue, so we can focus on it properly.

Spotify is a separate topic again. For that, let’s use #155, so we don’t mix different root causes in one thread.

This separation will make it much easier to diagnose and fix each issue correctly.

@rudyberends commented on GitHub (Feb 10, 2026): > Hello, > > I'm fully aware that you tested the software and didn't encounter this problem. The error message here isn't meant to be offensive! > > The problem I'm currently experiencing, even after testing with the latest beta version, affects my player when it's configured as a Squeezelite player. I can rule out network issues, as it works perfectly fine outside of Lox Audio Server. The player is also connected to a Gigabit LAN. Attached is a log file for the situation with a TuneIn low-resolution stream, which normally runs without problems. > > [lox-audioserver-logs-2026-02-08T18-10-47-922Z.txt](https://github.com/user-attachments/files/25164183/lox-audioserver-logs-2026-02-08T18-10-47-922Z.txt) Thanks for clarifying. No worries at all — I didn’t take it as offensive in any way. The point I was trying to make is that it really helps to keep separate problems in separate issues. Even if the symptoms look similar on the surface, mixing them makes troubleshooting very difficult. In the case of jurajs5, the problem is clearly related to the AirPlay output. Even though I can’t reproduce it locally yet, the issue is very clearly visible in the logs. In your case, if you’re seeing the problem with all inputs and only when the player is configured as Squeezelite, then this points to a Squeezelite-specific issue, not the same AirPlay problem. Let’s continue investigating that under the existing Squeezelite issue, so we can focus on it properly. Spotify is a separate topic again. For that, let’s use #155, so we don’t mix different root causes in one thread. This separation will make it much easier to diagnose and fix each issue correctly.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 12, 2026):

@jurajs5 @Holzmusik

Do you have spotify connect enabled on the zones? Could you try disabling spotify connect for every zone and see if you can reproduce the issue?

@rudyberends commented on GitHub (Feb 12, 2026): @jurajs5 @Holzmusik Do you have spotify connect enabled on the zones? Could you try disabling spotify connect for every zone and see if you can reproduce the issue?

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 12, 2026):

Hi, i also noticed the stuttering. Disablibg Spotify connect doesn't solve it.

@p4co86 commented on GitHub (Feb 12, 2026): Hi, i also noticed the stuttering. Disablibg Spotify connect doesn't solve it.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 12, 2026):

Hi, i also noticed the stuttering. Disablibg Spotify connect doesn't solve it.

It's disabled on all zones? There are no more spotify connect messages in the logs? Also what output are you using?

@rudyberends commented on GitHub (Feb 12, 2026): > Hi, i also noticed the stuttering. Disablibg Spotify connect doesn't solve it. It's disabled on all zones? There are no more spotify connect messages in the logs? Also what output are you using?

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 12, 2026):

Yes, disabled on all zones. total 4 zones, wich are outputed to squeezelite players. there are no spotify connect messages in the log.

This is the only message i get about spotify, every zone of my 4 zones the same message: [2026-02-12T20:08:37.721Z][INFO][Output|Factory] [zoneId=13] Spotify Connect output skipped; offload is false

@p4co86 commented on GitHub (Feb 12, 2026): Yes, disabled on all zones. total 4 zones, wich are outputed to squeezelite players. there are no spotify connect messages in the log. This is the only message i get about spotify, every zone of my 4 zones the same message: [2026-02-12T20:08:37.721Z][INFO][Output|Factory] [zoneId=13] Spotify Connect output skipped; offload is false

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 12, 2026):

then clear the log, put it on spam level, play a song reproducing the stutter and supply the entire spam log.

@rudyberends commented on GitHub (Feb 12, 2026): then clear the log, put it on spam level, play a song reproducing the stutter and supply the entire spam log.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 12, 2026):

This is the log, i only play from NAS source local in my network. Playing Spotify does not work, no sound and stops after 2 seconds.

lox-audioserver-logs-2026-02-12T20-32-31-750Z.txt

@p4co86 commented on GitHub (Feb 12, 2026): This is the log, i only play from NAS source local in my network. Playing Spotify does not work, no sound and stops after 2 seconds. [lox-audioserver-logs-2026-02-12T20-32-31-750Z.txt](https://github.com/user-attachments/files/25273127/lox-audioserver-logs-2026-02-12T20-32-31-750Z.txt)

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 12, 2026):

Thanks for the log — that’s exactly what I needed. It clearly shows the Squeezelite issue.

I’ve pushed a fix to the testing branch. You can either check out that branch and test it locally, or run the testing container if that’s easier for you.

ghcr.io/lox-audioserver/lox-audioserver:testing-20260212210218

@rudyberends commented on GitHub (Feb 12, 2026): Thanks for the log — that’s exactly what I needed. It clearly shows the Squeezelite issue. I’ve pushed a fix to the testing branch. You can either check out that branch and test it locally, or run the testing container if that’s easier for you. ghcr.io/lox-audioserver/lox-audioserver:testing-20260212210218

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 12, 2026):

tested it, it is as smoth as i expected it, great work thanks. Everytime i do docker compose up -d, all settings are gone, any ideas how to fix this. i always have to readd the netowrk share.

@p4co86 commented on GitHub (Feb 12, 2026): tested it, it is as smoth as i expected it, great work thanks. Everytime i do docker compose up -d, all settings are gone, any ideas how to fix this. i always have to readd the netowrk share.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 12, 2026):

Thanks for testing. Great to hear playback is smooth now.

All settings are stored in /app/data (including config.json), so you need to mount that folder to the host.

Add this to your docker-compose.yml service:

services:
  loxoneaudioserver:
    # ...
    volumes:
      - ./data:/app/data

Then run:

mkdir -p data
docker compose up -d --force-recreate

This creates/uses a local directory on your host (./data) and makes it available inside the container at /app/data.

@rudyberends commented on GitHub (Feb 12, 2026): Thanks for testing. Great to hear playback is smooth now. All settings are stored in /app/data (including config.json), so you need to mount that folder to the host. Add this to your docker-compose.yml service: ``` services: loxoneaudioserver: # ... volumes: - ./data:/app/data ``` Then run: mkdir -p data docker compose up -d --force-recreate This creates/uses a local directory on your host (./data) and makes it available inside the container at /app/data.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 12, 2026):

that worked, thanks!

@p4co86 commented on GitHub (Feb 12, 2026): that worked, thanks!

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@Holzmusik commented on GitHub (Feb 12, 2026):

Hi,

Wow, you really have to be quick here 🤣
I just read that a log file was still needed and was about to upload it when I saw there's already a fix. I immediately tried the testing branch and playback works perfectly for me too. Thanks a lot!

@Holzmusik commented on GitHub (Feb 12, 2026): Hi, Wow, you really have to be quick here 🤣 I just read that a log file was still needed and was about to upload it when I saw there's already a fix. I immediately tried the testing branch and playback works perfectly for me too. Thanks a lot!

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 13, 2026):

Hi,
the stuttering, fragmenst are gone as i said. But sometimes i get a little pause from ca. 200ms. Then Playback plays smooth.

Dont know if it has something to do with mit NAS, but connection ist Gbit. Later i will post a log. Does anyone else noticed such behaviour.

@p4co86 commented on GitHub (Feb 13, 2026): Hi, the stuttering, fragmenst are gone as i said. But sometimes i get a little pause from ca. 200ms. Then Playback plays smooth. Dont know if it has something to do with mit NAS, but connection ist Gbit. Later i will post a log. Does anyone else noticed such behaviour.

kerem commented

2026-02-27 19:28:20 +03:00

Author

Owner

@p4co86 commented on GitHub (Feb 13, 2026):

The error accours most at the beginning, first 3-15s.

Heres the log. Error occurs on 15:21:33 and something arround 15:21:45. Log is filling too fast.

lox-audioserver-logs-2026-02-13T15-21-54-725Z.txt

Also here at the end. Something around 15:31:52.

lox-audioserver-logs-2026-02-13T15-32-05-100Z.txt

It also stutters when controlling the loxone app, eg. volume up or down

Here is another log, this message is spaming the log: [2026-02-14T05:29:12.381Z][WARN][Audio|@lox-audioserver/node-librespot] [scope=librespot_core::session source=connect_host] Try another access point...

when this happens, the is no sound, song plays normal in the app.

lox-audioserver-logs-2026-02-14T05-29-20-143Z.txt

disabling spotify connect on first page and on all zones fixed it complete. playpack starts immediatly. no stutter, no cuts. App runs even smoother eg. scroling thru the library or change volume.!

@p4co86 commented on GitHub (Feb 13, 2026): The error accours most at the beginning, first 3-15s. Heres the log. Error occurs on 15:21:33 and something arround 15:21:45. Log is filling too fast. [lox-audioserver-logs-2026-02-13T15-21-54-725Z.txt](https://github.com/user-attachments/files/25294782/lox-audioserver-logs-2026-02-13T15-21-54-725Z.txt) Also here at the end. Something around 15:31:52. [lox-audioserver-logs-2026-02-13T15-32-05-100Z.txt](https://github.com/user-attachments/files/25294899/lox-audioserver-logs-2026-02-13T15-32-05-100Z.txt) It also stutters when controlling the loxone app, eg. volume up or down Here is another log, this message is spaming the log: [2026-02-14T05:29:12.381Z][WARN][Audio|@lox-audioserver/node-librespot] [scope=librespot_core::session source=connect_host] Try another access point... when this happens, the is no sound, song plays normal in the app. [lox-audioserver-logs-2026-02-14T05-29-20-143Z.txt](https://github.com/user-attachments/files/25310586/lox-audioserver-logs-2026-02-14T05-29-20-143Z.txt) disabling spotify connect on first page and on all zones fixed it complete. playpack starts immediatly. no stutter, no cuts. App runs even smoother eg. scroling thru the library or change volume.!

Rows
Columns

[GH-ISSUE #153] Airplay1/RAOP stutter #84