Bugzilla – Bug 11283
audio stuttering occurs
Last modified: 2012-03-29 06:46:29 UTC
See this tread: http://forums.slimdevices.com/showthread.php?t=60117 Sorry for not getting a more clear bug description. But if you read my tread you some things i found was. *Network test on the SBC with speeds >500 oveloads the controller. *It's not network related no buffering what i can see. * Screen saver and "locking keys" enhances the problem. * It's seems to be cpu speed related. I did some testing in last post. And there is a log from the SBC in one of the first posts.
Agree with > 500 kbps network test problem, didn't try screensaver/keylock part yet. Tested on SC 7.4-25192/Windows.
Unchanged with Jive r4824.
Just cross-checking Jive 7.3 r4842 against this, using SC 7.4-25680. First results: 1. Network Test still won’t show "good" results above 500 kbps. 2. No stuttering audio problems anymore (!), neither when using screensaver nor when display goes blank. 3. Interestingly, even plays FLAC (no transcoding) between 834 and 986 kbps without stuttering now.
Mine still stutters especially when it's shifting state screen goes blank. For me this bug is not fixed, it worked with the older firmware ? so what now. testing as usual 1m from the router. No clear pattern regarding flac vs low bitrate mp3
If one does the network test from SC it shows that the only reliable rate would be 64kbps ? 1 meter from the same router that can stream 24/48 flac to my SB3 or SBR , yes i don't play on the other players while i'll test this. from 128kbps test on SBC not in charching cradle: < 10 : 1 : 1% < 20 : 0 : 0% < 30 : 0 : 0% < 40 : 1 : 1% < 50 : 1 : 1% < 60 : 0 : 0% < 70 : 0 : 0% < 80 : 1 : 1% < 90 : 0 : 0% < 95 : 2 : 1% < 100 : 0 : 0% >=100 : 169 : 97% ################################################ max : 100.000000 min : 9.090909 avg : 98.567100 And now 320kbps when it in the cradle ? < 10 : 0 : 0% < 20 : 0 : 0% < 30 : 0 : 0% < 40 : 0 : 0% < 50 : 0 : 0% < 60 : 0 : 0% < 70 : 0 : 0% < 80 : 0 : 0% < 90 : 0 : 0% < 95 : 0 : 0% < 100 : 0 : 0% >=100 : 134 :100% ################################################## max : 100.000000 min : 100.000000 avg : 100.000000 500kbps in cradle: < 10 : 0 : 0% < 20 : 0 : 0% < 30 : 0 : 0% < 40 : 0 : 0% < 50 : 0 : 0% < 60 : 0 : 0% < 70 : 0 : 0% < 80 : 0 : 0% < 90 : 0 : 0% < 95 : 0 : 0% < 100 : 0 : 0% >=100 : 196 :100% ################################################## max : 100.000000 min : 100.000000 avg : 100.000000 500kbps out of cradle, look at this: < 10 : 24 : 13% ###### < 20 : 2 : 1% < 30 : 9 : 5% ## < 40 : 19 : 10% ##### < 50 : 22 : 12% ##### < 60 : 16 : 9% #### < 70 : 5 : 3% # < 80 : 0 : 0% < 90 : 2 : 1% < 95 : 0 : 0% < 100 : 0 : 0% >=100 : 87 : 47% ####################### max : 100.000000 min : 0.000000 avg : 64.284169 after a certain time when screen is black only the 10 -60% markers advance no more 100% same after some more minutes: < 10 : 42 : 14% ###### < 20 : 6 : 2% < 30 : 36 : 12% ##### < 40 : 46 : 15% ####### < 50 : 55 : 18% ######## < 60 : 27 : 9% #### < 70 : 7 : 2% # < 80 : 1 : 0% < 90 : 2 : 1% < 95 : 0 : 0% < 100 : 0 : 0% >=100 : 87 : 28% ############## max : 100.000000 min : 0.000000 avg : 51.613177 if I lift the SBC and starts to shake it the >=100% comes to life again ? consequently it stutters less when it in the cradle thats an improvement, before 7.4: 4824 it was no difference
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
Updated from jive r4842 to r5226: Problem was *almost* gone with r4842, is back with r5226. When display switches off or other (assumingly) "throttling" actions happen, heavy audio stuttering occurs.
(In reply to comment #7) > Updated from jive r4842 to r5226: > > Problem was *almost* gone with r4842, is back with r5226. When display switches > off or other (assumingly) "throttling" actions happen, heavy audio stuttering > occurs. This problem is really annoying and seems to still be happening is there any fix coming for this? It stutters even with no screensaver playing 128Kb mp3s. It never did this before.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
*** Bug 13777 has been marked as a duplicate of this bug. ***
Moving target to 8.0 as this is not an advertised feature of the 7.4 release. This is a Controller only bug, Other SP based devices function properly
Richard, I heavily protest to putting this on 8.0 ! As written on bug 13777 with jive 7.3.3FW6038 I don't have ANY stutters at all! You can read in the forums that many people use the controller to listen to music. With 7.4, FW7330 there were some stutters, but it was sort of acceptable (with a lot of goodwill). I can confirm what dr_joerg_mueller@web.de recently wrote in bug13777: with FW7571 it got really worse. Regular stutters now every 5 seconds ! The function now renders useless, I didn't trust my ears this evening. I really doubt that this is a hardware issue when it changes that drastically from one firmware version to another ! With putting out the radio (which I actually wanted to buy) you are forcing your customers to upgrade to 7.4. But in the same turn you take away a feature of the controller which - although it was beta and never advertised - worked quite good so far. Please reconsider your decision.
On todays latest 7.4 7571 firmware the stuttering is back with a vengeance. It's no longer sligthly clicking as it was a while. Just a data piont.
this is not the case for every one my controller stutters on 7.3.3FW6038 even with mp3 but mostly with flac .
As I wrote in bug 13777, my SBC stutters heavily with MP3 or FLAC on 7.4 and never stutters with MP3 or FLAC on 7.3.4 SqueezePlay doesn't stutter on 7.3.4
(In reply to comment #15) > SqueezePlay doesn't stutter on 7.3.4 What I meant was SqueezePlay doesn't stutter on _7.4_
Controller audio playback needs to be fixed to be at least as good as 7.3.
Did the 7.4 update today as advised by the generic email that was sent out to registered users. Now my controller that played back perfectly on the previous release is horrendously choppy.Not happy that it is seemingly not being addressed as a priority as "it is not an advertised feature". Poor show.
== Auto-comment from SVN commit #7807 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=7807 == Bug #11283 Fix audio playback on jive (still in beta). To get good audio playback the process needs to be realtime, but don't call mlock() on jive. We need to test for regression of bug #13693.
The fix I just checked in improves audio playback on jive a lot. It's not perfect all the time, and I've only tested mp3 and flac, but it's certainly usable as a 'beta' again. Ross, I'm assigning to you as we need to verify regression on Bug #13693 once the build is available. I have been testing all day (both the reset out of sleep and the audio playback), and it looks good to me. Thanks.
I had posted Bug 14410 but as I can see this bug is already being discussed here. I had written: I found that audio playback locally through Headphone Jack on Squeezebox Controller is scratchy with frequent interruptions (little breaks of a second or so) when playing music from my collection on a ReadyNAS NV+. I am running Squeezebox Server 7.4.0 on my ReadyNAS. The playback remained scratchy even I after I went close to my wi-fi router (Linksys Range Plus WRT110). Most of my content is Flac.
(In reply to comment #20) > The fix I just checked in improves audio playback on jive a lot. Richard, can you give a hint if this fix should turn up in the nightly builds ? I just downloaded the latest 7.4.x nightly (SqueezeboxServer-7.4.1-28715.exe) but this still 'only' embeds r7790 of the firmware. What is the easiest way to get a jive >7807 (even http://update.slimdevices.com/update/firmware/7.4.1/) doesn't give a new one ?
*** Bug 14410 has been marked as a duplicate of this bug. ***
(In reply to comment #22) There was a problem with the build system, which is now fixed. The jive firmware is there now, feel free to download an load to your Controller to verify this fix. Then report back in this bug if the new firmware resolves the issue for you or not. jive_7.4.1_r7817.bin is there as of the time of this post.
(In reply to comment #24) > (In reply to comment #22) > There was a problem with the build system, which is now fixed. The jive > firmware is there now, feel free to download an load to your Controller to > verify this fix. > > Then report back in this bug if the new firmware resolves the issue for you or > not. > > jive_7.4.1_r7817.bin is there as of the time of this post. I'm new to this bug. So, I've a few questions. I'd been running the 7.4 betas on my Windows Home Server via Michael Herger's beta builds. I, too, experienced the "stuttered" Controller playback w/7.4, but, not w/7.3.3. As a result, I rolled back to 7.3.3. I'd like, however, to continue using 7.4 and Michael's add-in build for Windows Home Server. From the post to which I'm replying, it seems that the stuttering can be corrected by using the jive firmware. How is that installed in the Controller? Am I correct that it involves more than by simply downloading the latest beta of 7.4? Thanks.
With r7817 this is quite a bit better, but still stutters especially at the beginning of playback.
Some rare stutters here and there but music can be enjoyed again, thanks a lot Richard! For anyone not wanting to use 7.4.1 Beta yet, I extended my Headphone-Plugin getting roughly the same results on 7.4.0 as well. http://forums.slimdevices.com/showthread.php?p=464814#post464814
I've been listening through the controller all morning with the update installed. It has improved, but I am still getting stutters every 30s or so. I'm not convinced that the issue is solved at all.
ewanpperry, what format music are you listening too?
I'm listening to mp3s at 256. I'm also using the BBC iplayer plugin for radio. Having done some more listening, the mp3s seem to be stuttering a little at the beginning of the track. Stuttering is much worse when listening to radio via the iplayer.
1. I thought the debug feature did not work, because I didn't see any numbers! I just found out that choosing another wallpaper makes the numbers visible. Because the numbers are always displayed in black, there are only a few wallpapers that make the numbers visible. (Could someone fix this?) 2. This lead to a probably interesting discovery: the problem is at least connected to what the controller has to do besides playing Audio. Normally my screen saver is the Now Playing screen. As a test I took a flac-file of 7.28 minutes. With the Debug screen in front of me, I heard glitches exactly 12 times (still too many). When I switched to the Now Playing screen, I had 14 glitches within the first minute. 3. I ssh'ed into the controller and started top. On the now playing screen the CPU% idle was always below 30%. On the debug screen it was between 60% and 70%. 4. As a next experiment I set the Now Playing screen saver to off with the shortest delay (10 secs). After 15 seconds I heard more than 7 minutes play with only 1 glitch! I hope this helps make things better. BTW, the debug screen show the decoding buffer mostly at 100%, lowest I saw is 97% (except at the start and end of the track of course). The output buffer is mostly around 97%. This does not seem to have influence on the glitches. Teus
Teus, I tried your suggestion of switching off the screensaver and it does indeed prevent stuttering (with mp3s and radio streams). Stutters return when the screen is activated by moving the controller. This is a workable solution, but ideally playback should be glitch free whether the screen is on or not - I hope that Logitech are going to address this issue properly in a future update. Thanks for your fix in the meantime though!
(In reply to comment #32) [snips] > BTW, the debug screen show the decoding buffer mostly at 100%, lowest I saw is > 97% (except at the start and end of the track of course). The output buffer is > mostly around 97%. This does not seem to have influence on the glitches. I am running the 7.4r0 nightly SqueezePlay from October 20, 2009, and I also see similar issues. I play WMA (192kpbs) files with SqueezeBox Server set to convert WMA to MP3 and limit the rate for the SqueezePlay client to 192kbps. SqueezePlay reports receiving an MP3 stream, with a Decode buffer generally full or close to full. It also reports the same for the output buffer. Nonetheless, there is noticeable stutter for some tracks, although the music plays fairly well and continuously. The stutter is almost constant (I write "constant" because it sometimes gets "drowned out" by the music) and a number of clicks can be heard when at high volume. In other words, there seems to be no stutter for some tracks, but stutter for others. I use the "Now Playing" screensaver when playing (none when stopped, if this matters). Delay is set to 30 seconds. My "skin" is set to WQVGA Small Print Skin. The Wallpaper is set to the standard wallpaper. At times, apparently unrelated to the stuttering, the decode buffer load decreases to a low enough value for the playback to stop momentarily, although my network access speed is high and the network load is low. I hope this helps in resolving the stuttering issue. Do let me know if you would like me to turn on some trace logs. Cheers, PP
Someone in the duet forum suggested to stream FLAC as WAV so the controller doesn't have to do the FLAC decoding. This happends to work very well: even if I don't use my screen saver trick (just leaving the controller on Now Playing), the playback is almost completely flawless. FLAC decoding is not a very heavy task, so this result is quite surprising to me. This narrows the main issues down to the decoder in the controller, I think. Is there a bug in the controller decoder or is there something with the decoder task (too low priority/protection)? I hope these comments help repairing this. Teus
(In reply to comment #35) > Someone in the duet forum suggested to stream FLAC as WAV so the controller > doesn't have to do the FLAC decoding. This happends to work very well: even if > I don't use my screen saver trick (just leaving the controller on Now Playing), > the playback is almost completely flawless. > > FLAC decoding is not a very heavy task, so this result is quite surprising to > me. This narrows the main issues down to the decoder in the controller, I > think. Is there a bug in the controller decoder or is there something with the > decoder task (too low priority/protection)? > > I hope these comments help repairing this. > > Teus When I change my conversion to WMA to FLAC (instead of WMA to MP3, as explained in a previous post) I get more stuttering and the decode buffer never gets full. It is basically unusable. I also get a lot of stutter (in the WMA to MP3 case) if my WMA is somehow recorded at a rate below 192 kbibit/s. Is the information reported through Debug Playback accurate? Thsi is what I have been relying upon in my testing. PP
We don't have access to Richard any more to fix this bug, and (to me) the future of the controller audio streaming function seems pretty cloudy at the moment. Thanks for your votes, though, and they will insure we keep an eye on this bug.
In simple terms for us nonprogrammers what is the problem, it's squeezeplay so it should benefit from all other development in this area should it not? For me it looks like that the controller does not really have the cpu power to stream fast enough and /or decode flac at the same time for example. My crude measurments shows cpu very close to 100% and the ability to stream is less than the bitrate of most flacfiles ? Is the new-UI and apps eating all performance just say so, sure things can always be optimized to be a little faster, but is it enough ? Are we close to what actually can be done on this hardware ? With your new licensing terms sure some third party dev can help, but only if it is possible at all. That said I'm testing for the first time in a very long time. the streaming test still shows problem at 500k but now stutter is only occasional 1-5 times per song ? so something has gotten better by itself ? it mostly stutters on track changes and such and sometimes when using the UI to do other things, so it shows improvement. I shall now test if bitrate limiting via sbs works with 7.5 on the controller, with some older revisions bitrate limiting the controller player did not really help. But it might do now, maybe thats the solution only stream mp3 to the controller. I'll test this weekend. The headphone chip is not fantastic so mp3 is good enough for it I think.
Ok my mp3 test, with the latest 7.5 fw and bitrate limiting my flac to 192kbp/s .I've got rather stable playback, enough for beta status. A occasional click now and then once every 3'rd song or similar. This bug is a rather big thing to sweep under the carpet, it makes a rather big bump ;)
Unassigned bugs cannot have a priority.
i don't know if the SBC and SP are the same, or even getting developed anymore, but has this bug been tested to see if it still exists under 7.7.2? if it still exists, its a valid bug, but is there any legitimate hope of it actually getting fixed?
I understand that some people would really like to see some work here but it is pretty much guaranteed that it is not going to happen. Despite the presence of a headphone jack, and some discussion during the beta period of having audio available that way, it turns out that this has a heap of problems and these are simply not going to be fixed. It is one of those (rare) beta features that never made it to product release. If it works sufficiently well for you then great. Otherwise I am afraid that you are out of luck.