PDA

View Full Version : Squeezebox3 stutter/skip



moby_uk
2006-02-19, 08:16
Hi,
I've got the following configuration:

- Suse 10.0 server running slimserver 6.2.2 - 6245
- Squeezebox 3 running firmware version 33
- Squeezebox is running wireless, server is wired, but both are connected to the same router (D-Link DI-624).

I am getting near constant skips/stutters from mp3's. The squeezebox buffer is showing very low levels (10-0%).

A top on the server side indicates the box is essentially idle (it's a 3.2GHz intel with 2Gb ram). Traceroute shows the following:

traceroute to 192.168.0.101 (192.168.0.101), 30 hops max, 40 byte packets
1 192.168.0.101 0.976 ms 1.191 ms 1.161 ms

Wireless signal strength is good (usually 100%).

There is no stutter if I play the same tracks on the server.

Can anyone help?

Thanks,
Phil

Malor
2006-02-20, 01:55
Have you tried hooking up the Squeezebox in wired mode, for testing?

If the buffer never fills, it's probably not getting data fast enough. My assumption would be that there's something amiss with your wireless network. The fact that it's working at all means you're connected, but the dropouts would seem to indicate that it's unreliable.

Do you have any laptops to test the wireless with? If so, how does Softsqueeze behave over the same wireless link?

moby_uk
2006-02-20, 14:51
Thanks for the reply. I notice there are a few threads on this issue and I have tried most of the suggestions.

- If I connect using wired, I get 100% buffer and no stutters.
- At the time of testing my server was wired to the router as well. I have tested my wireless connection using my server and am right at this moment getting 620K/s downloads from the internet. So it is not the router itself (though I am using a wireless adapter from D-Link, so it may be a compatability issue)
- There are only two devices connected to my router - my squeezebox and my server
- I've tried everything I can think of on the router - turning off the turbo mode, changing the frag and beacon settings etc.

The very most I can get in terms of buffer when using wired is around 30-40%. But after a few seconds, the buffer starts to empty - it does not seem to recover once it hits zero.

As you can see below, the server is not loaded at all.

Given that I get a perfect high speed wireless connection from my server and that other people seem to be reporting similar issues, could it (dare I say) be a bug in the Squeezebox?

Hope someone can help as its unusable as it is.

Thanks,
Phil

Triode
2006-02-20, 15:04
Could I suggest you install the NetTest plugin:
http://wiki.slimdevices.com/index.cgi?PluginDiagnostics

This should allow you to measure the sustainable data rate between the server and player. You can then move your SB3 around to see if you get better performance closer to the access point or monitor when it drops [due to interference etc]

moby_uk
2006-02-20, 15:23
I've installed the nettest and have the following results:

I have 100% average all the way up to 3000kbps, then:

3000kbps - 100%
4000kbps - 84%
5000kbps - 68%
6000kbps - 55%

I'm streaming at the moment and my buffer was immediately at 0%. Here is a top from the server:

top - 22:23:16 up 11 min, 4 users, load average: 0.07, 0.24, 0.21
Tasks: 98 total, 1 running, 97 sleeping, 0 stopped, 0 zombie
Cpu(s): 12.0% us, 2.8% sy, 0.0% ni, 85.0% id, 0.0% wa, 0.0% hi, 0.2% si
Mem: 2074856k total, 623552k used, 1451304k free, 76576k buffers
Swap: 1052216k total, 0k used, 1052216k free, 332664k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5705 root 15 0 151m 26m 4232 S 15.6 1.3 0:12.23 X
7741 root 15 0 81188 41m 22m S 7.6 2.0 0:18.19 firefox-bin
7684 root 15 0 26124 13m 10m S 2.0 0.7 0:01.35 kwin
7688 root 15 0 29184 16m 12m S 2.0 0.8 0:03.07 kicker
7701 root 15 0 28660 15m 11m S 1.3 0.7 0:01.35 konsole
7660 root 15 0 28356 14m 11m S 0.7 0.7 0:01.01 kded
8546 slimserv 15 0 57956 53m 2852 S 0.3 2.6 0:11.74 slimserver.pl
8554 root 16 0 2112 1004 768 R 0.3 0.0 0:00.11 top

Cheers,
Phil

Triode
2006-02-20, 15:37
That would tend to suggest the wireless network was OK during the test. [The plugin does not stream data so is not doing exactly the same thing as streaming. It does rapid screen refreshes to achieve the same data rate.]

What does netstat -t show while streaming?

If you enable --d_http --d_source while playing what debug messages does the server give?

moby_uk
2006-02-20, 15:47
This is netstat while running a 3000kbps test:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:22729 localhost:cslistener ESTABLISHED
tcp 0 0 localhost:22728 localhost:cslistener ESTABLISHED
tcp 0 0 localhost:cslistener localhost:22729 ESTABLISHED
tcp 0 0 localhost:cslistener localhost:22728 ESTABLISHED
tcp 0 13140 192.168.0.10:cslistener 192.168.0.101:21031 ESTABLISHED
tcp 0 11340 192.168.0.:slim-devices 192.168.0.101:21028 ESTABLISHED


This is netstat while streaming:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:22729 localhost:cslistener ESTABLISHED
tcp 0 0 localhost:22728 localhost:cslistener ESTABLISHED
tcp 0 0 localhost:cslistener localhost:22729 ESTABLISHED
tcp 0 0 localhost:cslistener localhost:22728 ESTABLISHED
tcp 0 18980 192.168.0.10:cslistener 192.168.0.101:21032 ESTABLISHED
tcp 0 0 192.168.0.:slim-devices 192.168.0.101:21028 ESTABLISHED

Log output with the debug as requested (wasn't sure how much to paste so this is an extract). I can see some requeues but not sure if they are a problem..


2006-02-20 22:44:26.6297 generating from include.html
2006-02-20 22:44:26.6312 generating from playlist.html
2006-02-20 22:44:26.6388 End request: keepAlive: [15] - waiting for next request on connection = keep-alive

2006-02-20 22:44:26.6395 More to send to 127.0.0.1
2006-02-20 22:44:26.6401 No more messages to send to 127.0.0.1
2006-02-20 22:44:26.6407 No segment to send to 127.0.0.1, waiting for next request..
2006-02-20 22:44:46.0426 sendstreaming response begun...
2006-02-20 22:44:46.0431 sent incomplete chunk, requeuing 6160 bytes
2006-02-20 22:44:46.0433 Streamed 8760 to 192.168.0.101
2006-02-20 22:44:46.0705 sendstreaming response begun...
2006-02-20 22:44:46.0709 Streamed 6160 to 192.168.0.101
2006-02-20 22:44:46.3225 sendstreaming response begun...
2006-02-20 22:44:46.3231 (audio: 32768 bytes)
2006-02-20 22:44:46.3233 sent incomplete chunk, requeuing 24328 bytes
2006-02-20 22:44:46.3235 Streamed 8440 to 192.168.0.101
2006-02-20 22:44:47.5945 sendstreaming response begun...
2006-02-20 22:44:47.5949 sent incomplete chunk, requeuing 17028 bytes
2006-02-20 22:44:47.5951 Streamed 7300 to 192.168.0.101
2006-02-20 22:44:47.6134 sendstreaming response begun...
2006-02-20 22:44:47.6137 sent incomplete chunk, requeuing 6808 bytes
2006-02-20 22:44:47.6139 Streamed 10220 to 192.168.0.101
2006-02-20 22:44:49.2911 sendstreaming response begun...
2006-02-20 22:44:49.2915 Streamed 6808 to 192.168.0.101
2006-02-20 22:44:49.9305 sendstreaming response begun...
2006-02-20 22:44:49.9310 (audio: 32768 bytes)
2006-02-20 22:44:49.9312 sent incomplete chunk, requeuing 22056 bytes
2006-02-20 22:44:49.9314 Streamed 10712 to 192.168.0.101
2006-02-20 22:44:49.9705 sendstreaming response begun...
2006-02-20 22:44:49.9709 sent incomplete chunk, requeuing 13296 bytes
2006-02-20 22:44:49.9711 Streamed 8760 to 192.168.0.101
2006-02-20 22:44:50.6242 sendstreaming response begun...
2006-02-20 22:44:50.6245 sent incomplete chunk, requeuing 4536 bytes
2006-02-20 22:44:50.6247 Streamed 8760 to 192.168.0.101
2006-02-20 22:44:50.8465 sendstreaming response begun...
2006-02-20 22:44:50.8468 Streamed 4536 to 192.168.0.101
2006-02-20 22:44:50.8875 sendstreaming response begun...
2006-02-20 22:44:50.8879 (audio: 32768 bytes)
2006-02-20 22:44:50.8882 sent incomplete chunk, requeuing 21244 bytes
2006-02-20 22:44:50.8884 Streamed 11524 to 192.168.0.101
2006-02-20 22:44:52.3723 sendstreaming response begun...
2006-02-20 22:44:52.3726 sent incomplete chunk, requeuing 12484 bytes
2006-02-20 22:44:52.3728 Streamed 8760 to 192.168.0.101
2006-02-20 22:44:53.8624 sendstreaming response begun...
2006-02-20 22:44:53.8628 sent incomplete chunk, requeuing 3724 bytes
2006-02-20 22:44:53.8630 Streamed 8760 to 192.168.0.101
2006-02-20 22:44:55.7624 sendstreaming response begun...
2006-02-20 22:44:55.7627 Streamed 3724 to 192.168.0.101
2006-02-20 22:44:55.7631 sendstreaming response begun...
2006-02-20 22:44:55.7638 (audio: 32768 bytes)
2006-02-20 22:44:55.7640 sent incomplete chunk, requeuing 24812 bytes
2006-02-20 22:44:55.7642 Streamed 7956 to 192.168.0.101
2006-02-20 22:44:56.1961 sendstreaming response begun...
2006-02-20 22:44:56.1965 sent incomplete chunk, requeuing 17512 bytes
2006-02-20 22:44:56.1966 Streamed 7300 to 192.168.0.101
2006-02-20 22:44:56.4000 reading request...
2006-02-20 22:44:56.4003 HTTP request: from 127.0.0.1 (HTTP::Daemon::ClientConn=GLOB(0xa76b728)) for GET HTTP/1.1 /log.txt
2006-02-20 22:44:56.4019 processURL Clients: 192.168.0.101:21032
2006-02-20 22:44:56.4022 Generating response for (txt, text/plain) log.txt
2006-02-20 22:44:56.4024 generating from include.html

Triode
2006-02-20, 16:15
That all looks OK to me... Not sure what more to suggest.

Clutching at straws, do you have a wav file you could try playing? It should use more of the link bandwidth so should stutter more? (but exercise a different codec in the player)

moby_uk
2006-02-21, 03:06
I've also discovered that I have the same problem with Internet radio on the Squeezebox. These are stations that stream flawlessley on my server and when the box is connected to the wired network.

I'll give the wav a try, but given the evidence above, it seems that the problem is specifically related to wireless usage. If I wire the thing up, I have no problems at all. Unfortunately a bought the SB3 specifically for wireless use (lucky I didn't buy all 4 at the same time).

I've sent an email to tech support to see if they can help and will let you know how it goes.

Thanks for your help Triode.

dean
2006-02-22, 18:06
There's a new firmware version in the nightly releases, version 35, which should address some TCP throughput issues which can lead to stuttering.

Please try the latest nightly release and post your experience.

moby_uk
2006-02-24, 01:12
Thanks Dean. Kevin from support has been helping with this.

I upgraded to yesterday's nightly inc. firmware 35 and the situation does seem to have improved, though it seems to still be running with a low buffer. The couple of tracks I played played without a skip.

I'll be testing extensively this weekend and will post back my experiences.

Best regards
Phil

moby_uk
2006-02-27, 06:52
I've been off the air while a build a dedicated slimserver box. It looks like this issue may be resolved - I downgraded to firmware 28 and slimserver 6.2.1 5194 and the player is running with a 100% buffer and playing like a dream.

Just to confirm, I upgraded to the latest nightly and the problem re-occured with a vengence.

I have a running dialogue with support on this, so will keep the forum updated.

moby_uk
2006-03-08, 01:20
Bug has been raised. See this post for latest details.

http://forums.slimdevices.com/showthread.php?p=92767&posted=1#post92767

ChrisOwens
2006-03-08, 10:18
We're having a hard time reproducing this bug reported by not only message board users, but by users calling Kevin on the phone for support as well. We'd really like to release a new firmware version, but this issue is too important to release with it still in the firmware.

The symptoms I'm interested in are these:

After upgrading your firmware to a version higher than 28, you experienced brief pauses, "breakups", or "stuttering" in your audio. Putting firmware 28 or earlier back on your Squeezebox fixed the problem.

If you've experienced this, it would be very helpful if you'd visit the bug at http://bugs.slimdevices.com/show_bug.cgi?id=3125 and give some information about your system.

I'll take whatever information you can remember; I'm not picky, but ideally I'd like to know:

Description of the symptom
* Does it happen immediately upon playing?
* Does it happen every time, or does it come and go?
* Does it only happen with wireless networking?

Squeezebox
* What firmware version did you experience the problem with?
* What wireless signal strength was it reporting?

WAP/Router
* What Manufacturer and model of WAP or router are you using?
* What firmware version does your WAP or router have installed?
* Is your Squeezebox connected via wireless or with a cable?
* How heavy is your network traffic?
** Wireless?
** Wired?
** Anything else unusual about your network?
* What kind of wireless security are you using?
** WPA Personal (TKIP)
** WPA2 Personal
*** AES
*** TKIP + AES
** WEP
*** 64 bit
*** 128 bit

Server
* What version of Slimserver?
* What oS?
* What kind of CPU?
* How much RAM?
* Is the PC heavily loaded?
* What kind of PC network card are you using to connect to the WAP/router? (if built-in, what kind of PC?)
* What format(s) are you using? Did you notice any difference between formats?
** Lossless Formats
*** Apple Lossless
*** FLAC
*** WMA Lossless
** Uncompressed formats
*** AIFF
*** WAV
*** PCM
** Compressed formats (MP3, AAC, ogg Vorbis, MP2, MusePack, WMA)
*** MP3
*** VBR
*** CBR
*** AAC
*** Ogg
*** MP2
*** MusePack
*** WMA
** What format are you streaming in? (you can tell this by going to the slimserver -> server settings -> file types, and noting the first "stream format" checked for each "file format"
*** PCM
*** MP3
*** FLAC

Thanks for any information you can provide!

moby_uk
2006-04-19, 01:39
Hoorah! Just installed firmware v.41 and the problem is resolved. Thanks guys!

ChrisOwens
2006-05-02, 09:14
Just to tie this thread off.

We had been trying to reproduce the stuttering problem for a long time. It was delaying the release of 6.2.2! Finally, our RMA technician, Enrico noticed a couple units stuttering.

I loaded firmware 28 on them as many users had reported and the problem went away! Only a small fraction of SB3s turned out to have this symptom, and all the effected the units worked great with firmware 28.

I soldered on a header to allow Richard Titmuss in the UK to debug the hardware and shipped it to him. After some investigating, he discovered that a new SDK from one of our suppliers had a different default value for bus timing. He set it back to the old default, and the problem was cured.

The changes were put into firmware 45, and were officially released in firmware 48, currently available as part of the Slimserver 6.2.2 download at http://www.slimdevices.com/su_downloads.html