Bugzilla – Bug 980
Very high dropout rate when playing back on 10.4
Last modified: 2008-08-18 10:53:41 UTC
When starting playback of a new song, I get a couple of seconds of music, and a couple of seconds of silence. Lather, rinse, and repeat. Sometimes if I power down the Squeezebox, let it sit for a minute, and then power it up again, it's OK, other times it's not. The problem seems reproducible whenever I start a new song, as well. The server machine is a Power Mac G5, dual 2-GHz, 2GB of RAM, serial ATA hard drives, serving AIFF files to a Squeezebox1 (firmware 40) over 100mbps Ethernet. This configuration worked fine before I installed 10.4 on this machine. Just in case it's something related to the Perl install on 10.4: [BoomBox:~] siegel% perl -V Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=darwin, osvers=8.0, archname=darwin-thread-multi-2level uname='darwin b35.apple.com 8.0 darwin kernel version 7.5.0: thu feb 10 14:22:14 pst 2005; root:xnuxnu-517.99.10.obj~1release_ppc power macintosh powerpc ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing - I/usr/local/include', optimize='-Os', cppflags='-no-cpp-precomp -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno- strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1809)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under darwin Compiled at Feb 20 2005 21:31:51 @INC: /System/Library/Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .
got a copy of 10.4 to test with? what is the status of 10.4? I'm reading typical end user crap that is always speculation. as such, it could be crippled with debug flags for now (this is my OS/2 experience talking) ot: hi again rich, was nice meeting you :)
Yes, I have a 10.4 release from about a week ago. However, because SS6 is going to be released before Tiger is, we're going to focus on this bug later. :)
Need to fix this for 6.0
Rich - I just installed 8A393 in an attempt to reproduce, and am unable to. Streaming FLAC from a firewire drive, over wireless on a Powerbook G4 1.5Ghz. What type of format were you streaming? SB1 or SB2? Thanks.
I'm streaming to an SB1 with revision 40 firmware. (I will try to get my SB2 set up tonight and will report results if there is any difference.)
I finally got a chance to hook up my SB2 beta unit; I've also updated my 10.4 installation to 8A414 (the build that just got seeded yesterday) and the latest SlimServer 6.0 build. The SB2 works perfectly, I suspect owing to its much larger playback buffers, but the SB1 still exhibits the same behavior. (Incidentally, to answer your previous question which I missed, I am streaming AIFF files.)
Just an additional data point: I was able to reproduce the same behavior in my office, on a different 10.4 (8A414) machine, but with the same configuration and the same set of music files playing through a SqueezeBox 1 with revision 40 firmware.
Rich - I'm looking at this more - streaming FLAC (turned to PCM, no transcoding) from the Powerbook over wireless to an SB1. Mostly no drop outs - one or two, but I attribute that to wireless. Running at 5.6% CPU, 36M resident. Number of open files, faults, etc looks reasonable. You don't specify - wired or wireless?
In my initial report, I wrote: > over 100mbps Ethernet That's wired. :-)
Created attachment 380 [details] tcpdump output Dean asked me for a tcpdump of the skipping; it is attached. The player is at 204.107.232.196.
Tiger's TCP stack appears to be broken. Open the capture in Ethereal, right click on a port 9000 packet, and select "Follow TCP stream". Look at packet #191 at 1.2257 seconds. This is the first of three successive duplicate acks coming from the receiver, indicating that the packet with seq 164980 was lost, but the subsequent packets that were in flight were received. At this point the sender is supposed to invoke "fast retransmit" which means that the missing packet is retransmitted immediately instead of waiting for a timeout. It doesn't happen - the sender waits 1.3 seconds before retransmitting, and only then does the stream resume. There's nothing we can do to work around this from our end - Apple needs to fix it. Rich, what OS build number are you running?
I am running build 8A420 (it's the latest build available to developers, released late last week). I have filed a bug with Apple: the Radar reference number is 4070627 and I will try to get someone to look at it - if you have any contacts inside of Apple, you should probably ask them to as well.
Waiting for a new tiger to verify that this is an issue on Apple's side.
Fixed in latest tiger GM build. Dump from nanian looks fine.
Confirmed: playback is fine using 10.4 8A428.