Bug 110 - AIFF to MP3 transcoding to SLIMP3 has problems
: AIFF to MP3 transcoding to SLIMP3 has problems
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: unspecified
: Macintosh All
: P2 normal (vote)
: ---
Assigned To: Blackketter Dean
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-23 22:29 UTC by Blackketter Dean
Modified: 2008-09-15 14:37 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Blackketter Dean 2003-12-23 22:29:31 UTC
From: 	Rich Siegel
	Subject: 	Playback problems, *again*
	Date: 	December 19, 2003 8:24:44 PM PST

While I'm waiting for the spare time to appear so that I can hardwire my
Squeezebox networking and enjoy uncompressed AIFF playback, I figured I
could at least enjoy my SLIMP3. Unfortunately, the software doesn't want
to cooperate. I've been wrestling with it on and off for a couple of
weeks now.

When I try to play, what happens is that the server appears to start
'lame' (to transcode the AIFF to MP3); lame then proceeds to putter
along using 20% or so of CPU, and then after about ten seconds lame's
CPU usage drops to zero, and lame never quits. On the playback side,
this correlates to about ten seconds of very glitchy sound on the
SLIMP3, then silence.

If I invoke lame from the command line on the same AIFF, with the same
options as the server (--silent --b 320), lame takes up 90+ percent of
CPU (which is OK, because I have a dual-processor machine and 90% is
about half of its capacity), and then exits when it has converted the
file.

After some fiddling around I discovered "convert.conf", and I hardwired
the AIF->MP3 conversion bitrate to 192, and that helped a great deal.
Playback is much better, with only the occasional glitch.

At this point, I sat back to ponder. Why, all of a sudden, was my SLIMP3
playback broken? Upon reflection, I realized that I hadn't listened to
my SLIMP3 in the bedroom since I installed SlimServer 5.0.1 (when I got
my Squeezebox). I also thought back on any environmental changes that
might be causing problems. The network hasn't changed (and in any case,
320kbps worth of MP3 data wouldn't saturate an 802.11b). The machine's
been updated to 10.3, then 10.3.1, then 10.3.2, but none of these
updates had any effect (positive or negative).

Just for the hell of it, I downloaded and installed version 4.2.6 of the
server. And it works! Perfectly. At 320kbps. No playback glitches. lame
is still only using about 20% CPU as I write this, but it doesn't
matter; full-res MP3 is flying through the airwaves and coming out of my
speakers. (Of course, I can't drive my Squeezebox with 4.2.6, but that's
not an immediate problem.)

So: I think there might be a problem with transcoded playback in more
recent versions of SlimServer. (I was also able to reproduce it in
today's nightly build.) I don't think it's saturating the network;
instead, it seems like there's a problem getting data out of lame fast
enough for smooth playback. Since I don't really know anything about the
innards of the server software, I don't feel competent to make a
diagnosis. But let me know if there's any debugging gear I can enable,
or other diagnostic information I can generate.
Comment 1 KDF 2005-02-09 13:46:24 UTC
Dean,
is Rich still having this problem given the advances in LAME/iTunes LAME over
the year?
Comment 2 Blackketter Dean 2005-03-11 13:22:32 UTC
This apparently isn't a problem anymore
Comment 3 Chris Owens 2006-06-16 14:40:08 UTC
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.