Bugzilla – Bug 1541
AAC files "hiccup" during playback.
Last modified: 2011-03-16 04:18:48 UTC
AAC files "hiccup" during playback; i.e., there are intermittent moments when the sound cuts out. Also happens when searching the playlist. No other processing is occuring in computer at the time, since the G4 Titanium laptop is dedicated to slimserver. This was not a problem in 6.0.1.
Is this with a Squeezebox1 or 2? Wired or wireless? Are you bitrate limiting?
In response to ------- Additional Comments From dan@slimdevices.com 2005-06-01 09:58 ------- Is this with a Squeezebox1 or 2? Wired or wireless? Are you bitrate limiting? This is a Squeezebox 1. Wired (ethernet). Not sure what you mean by bitrate limiting. The skips in sound (2-3 skips in a row) appear to coincide with any change in the menu (i.e., when song list updates between songs). Thus the preponderance of skips at the start of songs. These are Apple Lossless files that are set to "AIFF " decoding in "File Types." NOT wireless.
I also had sound corruptions after browser refreshes when streaming mp3s to xmms or itunes clients. The stream is being trashed by the browser fetching status_head.html, as this invokes the Slim::Player::HTTP::power method which calls Slim::Web::HTTP::clearOutputBuffer() on the stream. Here's a snippet of d_http log output: (note the browser is on a different box from the player, and I've added a few extra d_http msg's) 2005-06-23 21:35:12.9207 Streamed 2896 to 192.168.1.3 2005-06-23 21:35:13.0189 sendstreaming response begun... 2005-06-23 21:35:13.0197 metadata bytes: 9145 2005-06-23 21:35:13.0203 sent incomplete chunk, requeuing 6623 bytes 2005-06-23 21:35:13.0208 Streamed 2896 to 192.168.1.3 2005-06-23 21:35:13.0517 reading request... 2005-06-23 21:35:13.0523 HTTP request: from 192.168.1.10 (HTTP::Daemon::ClientConn=GLOB(0x960a91c)) for GET HTTP/ 1.1 /status_header.html?player=192.168.1.3&start=&refresh=1 2005-06-23 21:35:13.0533 HTTP parameter player = 192.168.1.3 2005-06-23 21:35:13.0539 HTTP parameter start = 2005-06-23 21:35:13.0544 HTTP parameter refresh = 1 2005-06-23 21:35:13.0556 processURL Clients: 192.168.1.3:32873 2005-06-23 21:35:13.0565 Generating response for (htm, text/html) status_header.html 2005-06-23 21:35:13.0571 generating from include.html 2005-06-23 21:35:13.0585 finished include.html 2005-06-23 21:35:13.0594 path status_header.html matches a page function: CODE(0x8f63500) 2005-06-23 21:35:13.0607 Slim::Player::HTTP::power called 2005-06-23 21:35:13.0613 clearOutputBuffer on HTTP::Daemon::ClientConn=GLOB(0x98801e8) 2005-06-23 21:35:13.0664 generating from status_header.html 2005-06-23 21:35:13.0707 End request: keepAlive: [23] - waiting for next request on connection = keep-alive 2005-06-23 21:35:13.0718 More to send to 192.168.1.10 2005-06-23 21:35:13.0730 No more messages to send to 192.168.1.10 2005-06-23 21:35:13.0744 No segment to send to 192.168.1.10, waiting for next request.. 2005-06-23 21:35:13.1189 sendstreaming response begun... 2005-06-23 21:35:13.1200 (audio: 32768 bytes) 2005-06-23 21:35:13.1206 metadata bytes: 12041 2005-06-23 21:35:13.1210 splitting message for metadata at 20727 2005-06-23 21:35:13.1215 sent incomplete chunk, requeuing 17831 bytes 2005-06-23 21:35:13.1220 Streamed 2896 to 192.168.1.3 Editing Slim/Player/HTTP.pm power() sub to remove the call to clearOutputBuffer seems to have cleared my problem. Not sure if thats the right or best thing to do, but it seems to be mostly harmless. This may be affecting all clients that use the HTTP stream. I suspect AAC files are less tolerant of this than mp3's, making the corruption more noticeable. Hope thats useful. regards, Greg.
Thanks - this has been fixed as of subversion change 3532.