Sonos - Starting playback takes very long time to start #517
Comments
Click to expand - Log `1.7.0` for airupnp (log level all=debug)You will also find another log file from another user in the latest comment in the other issue if you need further infos please let me know. I currently have not tested other audio formats or content length settings for airupnp. |
|
Can you try 1.7.1 (it's not a release yet, you have to take the zip directly). I might have found an explanation but I'm not 100% sure and there might be side effects to the change I've made |
|
thanks, ok, tested 1.7.1. Speakers are found, can be connected, playback starts but I do not hear anything. After about 1 minute it will switch back to the integrated speakers and the connection to the Sonos speaker is lost. debug log in next comment. Click to expand - Log (Loglevel Info): |
Click to expand - Log (Loglevel DEBUG): |
|
Argh... got it thanks, that's the side effect I was referring to but I know what to do now. Will do that tomorrow, it's getting really late here |
|
BTW, what is the airplay controller you are using? |
At the moment my MacBook Pro for playback. Same problem with iphone and ipad (didn't tested with 1.7.1). Edit: On my iphone it does not connect at all (1.7.0), i can select the Speaker, it shows that the speaker is connected but it directly plays on my internal iphone speakers. But this could also be a problem on my phone, didn't test it for a while edit2: ok, on the iphone of my wife i have the same behaviour than on my macbook (starting playback takes about 15 seconds). So on my phone this is another problem, not related to this issue |
|
right... I've decided that it was time to rethink my approach to flush/first packet management (I did that a very long time ago and it was not pretty). I've refactored that in 1.8.0 (there will probably be a few iterations...) but let me know if it works better for you. On my iTunes (Win) and iPhone iOS 17.x it works now. They are very different way to handle this problem and my response was not ideal, to say the least. |
|
grrr... had to do another build b/c I realized that freaking iOS sends every resend requested frame twice and also, contrary to before and to iTunes Windows, when paused, it does a flush and send start sending silence frame. iTunes, and others, and iOS previously, just send a flush and stopped sending anything. At least the good thing is that it forced me to do a broader validation. |
|
Ok, thanks! Sounds good. I'll test the new version after breakfast :-) |
|
Ok, tried 1.8.1. Same behavior as before, about 10-15 seconds delay. Tested on iPad Pro and MacBook Pro
First Example: Click to expand - From MacBook Pro using Spotify App - 1.8.1 Log (Loglevel DEBUG):Second Example: Click to expand - From iPad Pro using Apple Music App - 1.8.1 Log (Loglevel DEBUG):Edit: |
|
Okay, there is something else then because it's only a few seconds for me on my iPhone 13 to my old Sonos PLAY:3 |
|
The only explanation I can have is a change of buffering strategy from sonos. They want to have a large amount of data before starting to stream |
|
Thanks! Hmm... strange. I will troubleshoot it a bit more and try to test if I can identify if it is related to the installation location (Synology NAS). Since more people at the Airconnect-Synology repository have the same problem, I do not think that this is a local network related problem (streaming to airplay devices natively supported is working). Could it have something to do with the bitrate setting in the streaming clients? I always stream at the highest possible bit rate from players such as Apple Music, Spotify etc. (lossless format in the case of Apple Music). I know that airupnp logically converts this itself, but could it be that this is why it takes longer to start? I have published 1.8.1 in my repo and get back to you after some more testers tried this version edit; ok, same on any YouTube video when device is connected to play:1 speaker |
|
Feedback from one tester: eizedev/AirConnect-Synology#79 (comment) |
|
I really have no idea then, except again a change of buffering policy from Sonos. As you know, upon devices rightfully like to buffer a serious amount of data before starting to play to absorb network hiccups. Sonos used to have a very low buffering. That does not work very well with AirPlay source because the source cannot send data in advance, as it is real time. Maybe one test that can be done is to use aac or mp3 encoding and see if it changes something, as Sonos players will treat that stream as a webradio then and should buffer less. But I'm quasi-sure it is not a networking issue like in router or configuration |
|
I will give it a try. Thanks |
|
updated my other issue with a comment to a workaround that is working now: eizedev/AirConnect-Synology#79 (comment) |
|
Is there a way to adapt this workaround to this plugin?
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @philippe44
This applies to versions from approximately 1.1.x. Last tests with 1.6.9 and 1.7.0.
i have a few users reporting issues in one issue in the AirConnect-Synology project about starting and (previously) stopping music that it takes very long time (10-15 seconds) until the music starts to play. We did a bit of troubleshooting but cannot recognize what's the problem. (Sonos update or airupnp update etc.).
Also something has changed in the last versions (don't know exactly from which version, didn't tried version between 1.2.x and 1.6.x), stopping playback only takes about 1 second, changing volume is instant but starting playback still takes 10-15 seconds.
Could you please check the issue linked above and the following log files from my devices if you can find any problems? I can reproduce the problem on my Synology NAS devices with the following startup command. The problem is the same with or without a config (config.xml) file for airupnp.
/volume1/@appstore/AirConnect/airupnp -b 192.168.1.10:49154 -l 1000:2000 -x "/volume1/@appstore/AirConnect/config.xml" -o "<NULL>,S1,S3,S5,S9,S12,ZP80,ZP90,S15,ZP100,ZP120,1.0,LibreWireless,Fitzwilliam,2.2.6,AllShare1.0" -z -f "/volume1/@appstore/AirConnect/log/airconnect.log" -d all=infoI was playing music on renderer "Flur" for a few seconds, changing volume and stopping playback in the logs below.
Thanks for your help,
René
Logfiles
(the log lines without the milliseconds in the timestamp are from my package):
Click to expand - Log `1.7.0` for aircast an airupnp (log level all=info)
Next log in next post (max. characters limit 65536...)
The text was updated successfully, but these errors were encountered: