mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-25 22:35:53 +03:00
[GH-ISSUE #138] Huge delay in v4.x (Spotify) #76
Labels
No labels
bug
enhancement
pull-request
released
released on @beta
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lox-audioserver#76
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mr-manuel on GitHub (Jan 25, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/138
I made some tests between v4.x (direct Squeezelite and Sendspin output tested) and v3.x (Music Assistant 2.6 with Squeezelite). When I start a song from Spotify on v4.x it takes 7 seconds until I can hear the song. With v3.x it took less then 1 second and it was nearly instant.
The Lox AudioServer have plenty of ressources available (tested with 2 CPU and 2 GB RAM, but also 8 CPU and 16 GB RAM).
Do only I have this problem, because of all my tests or do also others see this issue?
@rudyberends commented on GitHub (Jan 25, 2026):
What is your source? Native spotify, or MA?
@mr-manuel commented on GitHub (Jan 25, 2026):
Both cases native Spotify.
v4.x native Lox Audio Server Spotify
v3.x naive Music Assistant Spotify
The tracks are always selected via the Loxone app. Same playlist, same song.
@rudyberends commented on GitHub (Jan 25, 2026):
That’s a bit strange. In all tests I’ve done, we easily outperform Music Assistant. That’s not because its engine is necessarily slower, but because MA intentionally plays it very safe by using large buffers and long lead-in times. That’s the main reason I no longer recommend using MA as the primary backend.
When you say native in 4.x, you do mean that you added a Spotify account directly to lox-audioserver right?
If you use MA as a bridge and play Spotify through it, you will immediately introduce a delay of roughly 4 seconds. That’s because:
• we receive the stream over a Sendspin connection,
• MA applies a ~4-second buffer on that stream,
• we then process the stream,
• and finally the client applies its own lead-in and buffering.
All of that easily adds several more seconds.
To set expectations correctly: around 4–5 seconds of startup delay is acceptable for me for internet streaming services.
To rule out any other issues, please test with an audio file in the local library and do not route it through MA.
Playback from the local library should start almost instantly. If it doesn’t, then something else is going on.
@Re4DeR commented on GitHub (Jan 27, 2026):
I have about a 5–6s delay (spotify directly to lox-audioserver), which is acceptable for music playback. However, the doorbell delay is under 1 second, which is awesome and important for me.
@benleut commented on GitHub (Feb 4, 2026):
I can confirm it. Also have huge delay with sonos and beta v4, beta v3 also. tunein in lox-audioserver directly, approx 5 sek. Most of the time, i have to toggle between radio stations to get the stream working.
@mr-manuel commented on GitHub (Feb 20, 2026):
I made further tests and have now two parallel setups, which doesn't see each other:
Lox Audio Server 4.x feels really slow and cuts off audio files before really playing. Things that don't happen with LAS 3.x and MA 2.6.x or also complete separate Lyron Music Assistant.
Issues like https://github.com/lox-audioserver/lox-audioserver/issues/156 are reproducable with all audio playback, when the zone is not already playing. Made tests with Sendspin, Snapcast and Squeezelite clients. The cutoff is always identical for each player, but differs between player type and is between 200 - 400 ms. It feels like LAS don't wait for the ready signal of the player, if something like that exists.
Start playing a song from Spotify via the Loxone app (zone was off), takes 5-7 seconds with LAS 4.x and with LAS 3.x with MA 2.6.x it takes 1 second.
@mr-manuel commented on GitHub (Feb 20, 2026):
Now I tried also Lox Audio Server 4.x with Music Assistant 2.7.x. Unfortunately I was not able to add a Music Assistant player as output (https://github.com/lox-audioserver/lox-audioserver/issues/170) therefore I made some other tests.
@benleut commented on GitHub (Feb 20, 2026):
I have also the same exprerience, when i use v4. I had the best experience with v3 and MA 2.6, with some bugs (bell, alarm sounds, stopping players)
i have tried music assistant 2.7 without lox-audio - connect sonos speakers and everything works fine and smooth.
Same issues when connecting to sonos speakers via airplay?
@rudyberends commented on GitHub (Feb 20, 2026):
The latest beta includes a debug feature that shows exactly where the startup delay is coming from. If you can share a full SPAM log of a playback attempt, we can pinpoint the exact source of the delay.
That said, beta 5 and later are tuned for fast starts. Local playback should be instant, and streaming services should typically start within ~3 seconds.
As mentioned earlier: when using Music Assistant, there’s an immediate additional delay of about 4,5 seconds, which is on the Music Assistant side.
If you’re seeing “huge delays” with anything other than Music Assistant, please include a full SPAM log and we’ll trace where it’s coming from.
@mr-manuel commented on GitHub (Feb 21, 2026):
Thanks for your patience!
What does instant mean for you? For me instant is that audio starts playing in the exact same moment I press the button. Everything slower then 20 ms is noticable for the human ear. Anyway everything under 1 second feels good.
Radio stations start within one second, but why does Spotify takes so long?
I cannot confirm that. With Lox AudioServer 3.x and Music Assistant 2.6.x the delay of every action was always within 1 second. Anyway, this is not the way you want to go, so we have to find the problem in Lox Audio Server to get it also that fast.
Logs: play local track with sendspin client. starts immediately, but the audio is cutoff by about 1.45 s.
Sometimes a radio stream does not start at all. This happens, when you pause the stream and resume playing by pressing on the radio station again instead of the play button.
Spotify song taking 7 seconds to start playing, MA makes it in under 1 second. Stopping a song is instant.
I noted also that sometimes the tone and speed of the stream changes, but was not able to capture this behavior yet.
@rudyberends commented on GitHub (Feb 22, 2026):
If “instant” means audio starts at the exact same moment the button is pressed, then we need to be realistic about what that implies technically.
A hard 20 ms threshold is simply not realistic in a server-based audio architecture. The moment you introduce:
• A request/response cycle
• Process scheduling
• Decoder startup (ffmpeg)
• Buffer allocation
• IPC / stream piping
you are already operating above that range. Even highly optimized native systems rarely guarantee sub-20 ms from command to first decoded audio byte in a modular architecture.
To move this away from theory, I measured it in my own setup using a local album as benchmark. Local files are our reference point because they represent pure engine performance, without NAS latency, streaming services, network variability, or protocol buffering.
Test conditions:
• Album: Queen – Greatest Hits I (local album)
• Format: MP3 320 kbps
• Measurement: command received → ffmpeg first chunk
• Commands: play + repeated queueplus
Measured latencies (18 consecutive tracks):
42, 31, 28, 38, 36, 33, 26, 37, 36, 23, 34, 36, 43, 36, 33, 36, 35, 36 ms
• Average: 34.4 ms
• Min: 23 ms
• Max: 43 ms
So under local conditions, the engine consistently starts output in the 30–40 ms range. You will have an aditional buffer specific latency, but we are certainly not talking one second here. It really is fast enough for that "instant" feeling.
One extra note: there was burst protection logic in the skip path (next/prev) that effectively added ~150 ms to every queue skip. I’ve adjusted that logic so this fixed delay is no longer there — that change is already in the dev branch (
97edcfb). But even with that extra 150 ms, local track switches are still nowhere near 1 second.If you want to compare objectively and rule out setup-specific issues, please run the same test with a local album and share the deug log so we can measure command received → ffmpeg first chunk. If your numbers are significantly higher, then we have something concrete to investigate. If they are in the same range, then the engine startup time itself is not the issue.
@rudyberends commented on GitHub (Feb 22, 2026):
I’ve measured this, and what you’re seeing matches my results. The main reason radio starts in roughly ~1 second is that we use a fixed target lead to build a stable and safe buffer before playback begins.
That delay is intentional. It guarantees stability and prevents dropouts.
If we really want to, we can reduce that target lead and bring radio startup down to ~500 ms. That is technically possible. However, that would directly reduce buffer safety and increase sensitivity to network instability.
Radio is not a skip-heavy interaction. You tune in and typically listen for a longer period. In that context, a stable ~1 second startup is acceptable, especially when it guarantees smooth playback.
Can we agree that prioritizing stability over shaving startup time on radio startup is the correct choice here?
@rudyberends commented on GitHub (Feb 22, 2026):
Currently I am not able to test Spotify myself because of the changes Spotify made to their API, which seems to affect only “newer” accounts for now. This makes it hard for me to optimize it, and because Spotify did not allow app creation at the time I released the first versions, users are only now starting to use Spotify.
Your log is the first I’ve seen for this performance issue, and it helps a lot. Based on this log we can tell there is a very specific issue with Spotify (which uses an audio pipe).
I’ve now added a targeted fix for that path: Spotify pipe sources no longer use ffmpeg input pacing (-re). Librespot already outputs in real time, so this extra pacing could delay the first audio frame significantly. With this fix, startup should be much faster and closer to other services.
The fix is included in commit:
d231202fix(spotify): disable ffmpeg -re pacing for librespot pipe sources
If you can share one new log after updating, I can verify immediately whether the startup delay is resolved end-to-end.
@rudyberends commented on GitHub (Feb 22, 2026):
You can confirm it — even the title of this thread is “Huge delay in 4.x”.
It’s on the Music Assistant side, specifically in their SendSpin connector path that we have to use to register our players in MA. You won’t see this delay when you only test MA with its own native players. We might be able to tune it (and MA may also have changed things in the meantime), but my current focus is not on optimizing Music Assistant integration.
I understand the desire to compare 3.x vs 4.x, but that comparison is misleading and doesn’t lead to anything actionable. In hindsight I should have started a new project name, because they are not comparable in any meaningful way:
• Lox AudioServer 3.x was essentially a remote control for Music Assistant. It did not run an audio pipeline. It just forwarded commands to MA.
• Lox AudioServer 4.x is a full audio server (comparable to Music Assistant). In this architecture, MA doesn’t add much value anymore except for very specific use cases — and in most setups it only adds latency and complexity.
What I’m seeing a lot is users trying to configure 4.x exactly like they did with 3.x (i.e. MA-first). That is not the intended setup. Removing MA from the default path prevents people from building a 4.x setup on top of a dependency that only makes things slower and harder to support.
@rudyberends commented on GitHub (Feb 22, 2026):
I’m not trying to be arrogant here — my goal is simply to create the best possible setup. Everything is open for discussion, and if you can convincingly explain the value of keeping this in, I’m willing to do so.
That said: implementing this project has already been a lot of work (and I really do mean a lot). And it doesn’t stop at implementation — it also needs to be maintained and supported long-term. For me to keep doing that, the overall system needs to stay as simple as possible.
So the rule is straightforward: any component that doesn’t add clear value, or that unnecessarily complicates the setup, needs to go.
@mr-manuel commented on GitHub (Feb 22, 2026):
Thanks for clarification. If startup/interaction takes up to 1 second is perfectly fine. If it begins to take more then two seconds then it's beginning to feel sluggish.
Did you find something about the cutoffs?
It's perfectly fine like it is now for radio. I mentioned it just for completeness. Yes I agree, prioritizing stability here is the key.
Now I got it what you mean, thanks!
Loxone command send to Lox Audio Server to start song -> Lox Audio Server sends command to Music Assistant -> Music Assistant starts song on SendSpin player that lives on Lox Audio Server (here is the delai you mentioned) -> Lox Audio Server plays song finally on the hardware player.Loxone command send to Lox Audio Server to start song -> Lox Audio Server sends command to Music Assistant -> Music Assistant starts song on hardware player.That is exactly what I tested.
Since you do not support anymore the old configuration (set a MA player as LAS output) no further action needed here. Better to focus then to improve the remaining issues.
No problem it's fully understandable. I was only trying to make comparisons in some way, but obviously I was trying to compare apples with pears 🙈 I also maintain a few open source project and I exactly know how much time consuming it can be, Big thanks again for all your work and I would still be open to make some donations!
@rudyberends commented on GitHub (Feb 22, 2026):
You are using a very small audio file. It reports totalBytes=631296 PCM. At 44.1kHz, 16-bit, stereo (176400 bytes/s) that is about 3/4 seconds of decoded audio.
I can confirm playing real music will never give you these cutoffs. From the log I do see your issue, but this is more in line with people reporting their bell, or TTS does not work. This has to do with short audio segments and there are very specific fixes for this in the code, but they are only active when an audio file is marked as an alert.
@mr-manuel commented on GitHub (Feb 22, 2026):
Unfortunately there is no improvement here. In further details it takes 2 seconds, that the metadata is shown in the sendspin-cli player and further 5 seconds that the audio is hearable, which means the progress counter in the sendspin-cli is already on 00:05 when I start hearing something.
Logs
Now I was able to catch some logs, while the audio got slower/faster and the pitch deeper/higher. Also when stopping that song there was a static beep instead of silence:
Logs
While testing I found a few other issues, but opened separate issues for it, since this one is only for the delay I'm experiencing.
@rudyberends commented on GitHub (Feb 22, 2026):
This is how sendspin (and also snapcast) works. They play audio using a reference clock. When they are not on that clock they compensate by either slowing down, or speeding up playback. When the offset is big you will be able to hear this.
This is probably a byproduct of the spotify pipe issue. Under normal circumstances clock sync is near perfect, and you will never get a deviation where it is audible. I put a lot of effort into this as it is my main output protocol. Just make sure you are on the latest sendspin cli as they also improved a lot in their latest releases
I will get back to you on the delay. We might need a couple more commits as I cannot test it myself
@mr-manuel commented on GitHub (Feb 22, 2026):
Indeed this are custom recorded TTS audios which I want to play as overlay, when triggered through a Loxone logic. The file size is 28.6 KB and it's 4.8 s long.
I tested it also with Spotify songs and there I have also the first seconds cutoff . I don't know if the reason is another or the same as for local files.
@mr-manuel commented on GitHub (Feb 22, 2026):
But even if there is only one player and no group?
Everything is updated.
What would you need to be able to test it yourself?
@rudyberends commented on GitHub (Feb 22, 2026):
Yes, it always syncs up to the master clock. But don't focus on this too much, it is not an issue under normal circumstances. This is triggered by your spotify issues. This delay is probably also what the client is trying to make up for.
@rudyberends commented on GitHub (Feb 22, 2026):
An old (older) spotify account that is not affected by the new API limitations. Every librespot based implementation is effected by this. But we will get there, the issue is clearly visible in the logs.
Try this one:
ef745fbIf it does not resolve the issue, please submit the log again.
If you are running dev it should also contain a potential fix for the pause issue and also a version that adheres to the new Spotify api limitation for apps.
@mr-manuel commented on GitHub (Feb 22, 2026):
My Spotify Account is quite old and should not be limited. Can you write me on Discord or give me any contact details, then I can send you the credentials.
Edit: Seems like the restrictions are also applied to older accounts after 6th March 2026: https://developer.spotify.com/blog/2026-02-06-update-on-developer-access-and-platform-security
@mr-manuel commented on GitHub (Feb 22, 2026):
Now it took even longer.
Logs
@rudyberends commented on GitHub (Feb 22, 2026):
try this one:
7d22088Also there is an update for node-librespot which might improve start time. However the real fix needs to come from the audioserver so test that first.
For the new npm;
npm install @lox-audioserver/node-librespot@0.3.4
@mr-manuel commented on GitHub (Feb 23, 2026):
The startup delay is now much shorter!
EDIT: The more tests I made the more it gets interesting. When Lox Audio Server is freshly started it works for a bit, but then the more tests I make the more I have very strange behaviors. At beginning it starts very fast until a while then it takes again 4-5 seconds to start. Sometimes also a old song plays 4-5 seconds before the clicked one starts.
This doesn't seemed to change much on startup time. Maybe this could be related to the tone variations in the first seconds of playback, since sendspin tries to sync something?
@benleut commented on GitHub (Feb 24, 2026):
Same here, tested with sonos and beta 7. Music starts with a constant delay of 4-5 seconds. Log is attached.
lox-audioserver-logs-2026-02-24T10-16-43-882Z.txt
@rudyberends commented on GitHub (Feb 24, 2026):
Yes, the issue is clear. It's a general issue with spotify.
If you want to help investigate:
• Update to the latest dev patches.
• Reproduce the issue.
• Provide a full debug/spam log from the moment playback is triggered.
Otherwise wait for the next beta where this will be addressed.
@benleut commented on GitHub (Feb 24, 2026):
It’s not spotify, i have tested with radio stations.
@rudyberends commented on GitHub (Feb 24, 2026):
Please create a separate issue specifically for Radio + Sonos.
The Spotify delay is a different problem with a different code path. Mixing both in the same thread will only cause confusion and make troubleshooting harder.
In the new issue, include:
• Exact source (e.g. TuneIn, custom stream, etc.)
• Zone/output configuration
• Whether the delay is constant or variable
• A full debug/spam log from playback start
That keeps both issues clean and easier to track independently.