Re: [slim] Community Funded Squeezebox Replacement - Would you be interested?
On 10/10/2013 08:17 PM, Mnyb wrote: If you run debian testing ? why not run the 7.8 beta version of the server that have some fixes for the perl issues ( perl 5.18 ). if your prepared to run a beta versions of an OS Why not of the server I didn't even know there was a 7.8 beta version -- it's kept well hidden. I managed to find and install it, but it still bombs out: [13-10-18 01:55:07.8310] main::init (355) Starting Logitech Media Server (v7.8.0, 1382017549, Thu Oct 17 20:07:31 PDT 2013) perl 5.018001 [13-10-18 01:55:07.8413] main::changeEffectiveUserAndGroup (971) Warning: Logitech Media Server must not be run as root! Trying user squeezeboxserver instead. [13-10-18 01:55:08.5945] Slim::Music::TitleFormatter::init (42) Warning: Can't locate Slim/Schema/Track.pm: Permission denied at /usr/share/perl5/Slim/Music/TitleFormatter.pm line 42. Mind you, I didn't find this in the logs; I had to invoke squeezeboxserver manually to see these error messages. All I want to do is to play music on my Squeezeboxes just as I've done for years. I really shouldn't have to become a Perl hacker (or keep my system way out of date) just to do that. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
[slim] Anyone have a succinct summary of the squeezebox server situation?
I've heavily used several Squeezeboxes and Boom Boxes for years, but I'm ready to throw them all in the trash. I just wasted several hours in an unsuccessful attempt to get squeezeboxserver (or logitechmediaserver, or slimserver, or whatever it's called this week) running again on a Debian Jesse system after an apt-get upgrade broke it. I've lost track of how many times in the past my server has abruptly stopped working after I've updated some obscure library or piece of Perl on my system, and I've had to dig into the code to find out why. Users shouldn't have to be skilled programmers just to play the music in their libraries. The Squeezebox hardware is nicely designed, but it is quite frankly useless without reliable software to drive it. Perl was designed to crunch Linux system logs and generate reports, which it barely does. It's far too fragile a foundation on which to build a huge application like a music storage and retrieval system with thousands of gratuitous bells and whistles. It's also extremely slow even on fast modern hardware. Has anyone considered a simple server to drive Squeezebox hardware as a bare-bones network audio output device? I suspect I'm like most people in that I control my player from my computer, not the Squeezebox's own display and IR remote, so much of the software functionality just isn't necessary. It doesn't really need to do anything but accept a raw audio stream from a player like VLC or iTunes, possibly transcode it, and ship it over the network to the player. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community Funded Squeezebox Replacement - Would you be interested?
On 10/10/2013 06:12 PM, castalla wrote: I have LMS running on Fedora, Ubuntu and Debian - none of which are the latest and greatest - end result, rock solid systems and virtually no maintenance. That's your choice, but it's not mine. I strongly believe in updating software on a regular basis, primarily to fix security holes and bugs and only secondarily to get new features. I also use my servers for other purposes that require that they be kept up to date. Well-written applications should never break when this happens. Even when a non-backward-compatible change must be made to some module (e.g., a library) in Debian Linux, an application can specify that it needs the previous version and the package manager will handle this automatically. It can even allow multiple versions to coexist so that each application can use the one it wants. But the .deb files with the Squeezebox media server don't seem to do this -- probably because there are just far too many dependencies in the first place. I think these bit rot problems are merely a symptom of the real problem, which is that the Squeezebox media server tries to do far too much in one huge program written in the wrong language. Countless media player and library management programs with full-blown (and very complex) GUIs already exist for every OS, ranging from iTunes to the obscure, and I don't really see why I should have to use yet another one just to send audio through Squeezebox hardware. Why reinvent the wheel? What I really want is something like Apple's AirTunes or AirPlay, only with an open and unencumbered protocol specification and support for all the major codecs, including open-source ones like Ogg Vorbis and FLAC that the commercial guys refuse to support. It was this support for open codecs that attracted me to the Squeezebox in the first place. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community Funded Squeezebox Replacement - Would you be interested?
On 10/10/2013 06:50 PM, castalla wrote: That's your choice! hardware is so cheap these days that you can easily run a headless server for LMS at about 35 USD. I think you are just giving yourself unnecessary grief. Oh, I know hardware is cheap. I even bought a separate server recently to primarily host our media archive (though it cost more than $35). But I explained my main reason I keep my systems updated is to patch security holes and bugs. Perhaps that's why I've never had a detected break-in. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community Funded Squeezebox Replacement - Would you be interested?
On 10/10/2013 06:16 PM, garym wrote: You might be interested in the ickstream project. http://forums.slimdevices.com/showthread.php?98467-Pre-Announcement-ickStream-Music-Platformhighlight=Ickstream Thanks for the pointer. There is very little in the way of specifics, and a proprietary platform isn't very appealing, but any alternative to the present software is good to have. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Community Funded Squeezebox Replacement - Would you be interested?
On 10/10/2013 07:22 PM, paulster wrote: Use Debian then. I've updated mine regularly over the last 5 years and keep LMS up to date as well, and have never had a hiccup. There are more bleeding-edge distros than Debian but their security patches are up to date. That's exactly what I run -- Debian testing -- but slimserver frequently breaks during upgrades. It is now broken again and I've not been able to fix it. Usually I have to wait for another release but I haven't seen anything past 7.7.3. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Squeezeboxserver on Linux broken
My Squeezebox servers have been down for a week because of this most recent problem and I get the very definite impression that no one really understands what's wrong (I certainly don't). Perl is fine for its original purpose of running quickie, one-off scripts on text and system log files. That's how I use it. But I think it's simply the wrong platform for a large, complex and unique package like squeezeboxserver with many dependencies on a huge and only loosely standardized run-time environment that it does not and apparently cannot fully control. I understand that squeezeboxserver is an open source project that relies on volunteer contributions. That and its support for open audio formats like FLAC and Ogg Vorbis initially attracted me to it. But I've also dropped a fair chunk of change on Logitech's proprietary hardware players, and they're bricks without a working squeezeboxserver. I think Logitech owes its customers at least one working version of the server for each advertised platform that runs without constant attention from a local Perl hacker. Even when it does work, squeezeboxserver has always seemed much too slow for what it does. It seems to suffer from a serious case of feature bloat. All I've ever really wanted is a simple, fast and above all *reliable* way to play my large, multi-format music collection at home. Even a command-line interface would be enough. A barebones textual web interface would be a plus, along with the ability to stream a simple audio-over-HTTP feed. I certainly don't need RSS feeds scrolling across my player display, or dozens of other plugins and options of questionable utility. When I want to read the news I fire up Firefox on my laptop. It does a much better job. I really hate to say this but it's probably time to re-survey the network music player market for something that doesn't depend on unique client-server protocols, even when the server is open source. There's something to be said for widely implemented application protocols like HTTP even when they lack a feature you might think you could use someday. Sometimes all you really want is to play your music without first having to parse a Perl error traceback. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
[slim] Squeezeboxserver on Linux broken
I accepted the package update on both of my Linux servers, and squeezeboxserver stopped working on both. The logs showed only that the wrapper was continually restarting the daemon, so I invoked it manually and got this very cryptic message. What should I make of it? I'm not a perl hacker, I just want to play my music... Thanks. Use of inherited AUTOLOAD for non-method YAML::Syck::DumpYAML() is deprecated at /usr/share/squeezeboxserver/CPAN/YAML/Syck.pm line 65. The following modules failed to load: DBI DBD::mysql EV XML::Parser::Expat HTML::Parser JSON::XS Digest::SHA1 YAML::Syck GD Sub::Name *** NOTE: If you're running some unsupported Linux/Unix platform, please use the buildme.sh script located here: http://svn.slimdevices.com/repos/slim/7.5/trunk/vendor/CPAN/ You should never need to do this if you're on Windows or Mac OSX. If the installers don't work for you, ask for help and/or report a bug. If 7.5 is outdated by the time you read this, Replace 7.5 with the major version of Squeezebox Server you are running. *** Exiting.. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Squeezeboxserver on Linux broken
On 7/19/11 9:47 AM, aubuti wrote: You would be much more likely to get a helpful response if you indicated (a) which Linux distro and version you are using, (b) which version of SBS you are using, (c) what version of SBS was previously working on the server, (d) what method you used to install SBS, and (e) what hardware platform you are using. a) Debian testing b) 7.5.5, picked up by apt-get with sources.list line deb http://debian.slimdevices.com stable main c) Whatever was previously served through debian.slimdevices.com d) apt-get update;apt-get dist-upgrade e) x86_64, custom compiled 2.6.39.3 kernel. I see that others are having problems too, I'll just find a .deb package for a previous version that works and revert until the bugs can be fixed. Thanks. Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
[slim] GPG keys for Debian/Ubuntu packages?
Are the .deb packages for Debian and Ubuntu Linux signed with GPG/PGP keys? This is standard practice for the Debian repositories to prevent the distribution of malware should a repository be compromised. I don't see a key for the Squeezeboxserver packages distributed from debian.slimdevices.com. Should there be there? Thanks, Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
[slim] Excessive traffic to www.mysqueezebox.com
Every 5 minutes, like clockwork but sometimes even more often, the squeezeboxserver running on my Linux box opens a HTTP connection to www.myqueezebox.com and performs a GET. I've turned off all sorts of network syncing options and other features I've never used but the GETs continue. It appears to repeatedly pull down some sort of menu that never changes. I run a local server to be as self-sufficient as possible, and aside from connecting on request to external audio sources such as Sirius Radio and the Internet Archive, I see little reason for my server to ever talk to the outside world, much less every 5 minutes even when it's idle. Is there any way to turn it off, or at least knock the frequency way down? Thanks. Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/discuss
Re: [slim] Playing .m4a files?
On Thu, Oct 30, 2008 at 3:31 PM, Books [EMAIL PROTECTED] wrote: Somebody give me the low down - I am trying to play .m4a files (AAC and stuff) through SqueezeCentre (latest version). I use SqueezeCentre and then connect to the stream file with WMP at work. Is this possible, what needs to be done? What about Linux? I used to have it working after manual editing of custom-config.conf, but it broke in one of the upgrades over the past month or two. I can't even figure out where the config files are supposed to be now. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Boom aux input gain low?
I just got my Boom. Works great as a network player. I hooked my iPod up to the aux input and found that the gain is VERY low. With the iPod and Boom both cranked all the way up, I can just hear it across the room. What is the rated sensitivity of the Boom aux input? ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Boom aux input gain low?
I just found the aux gain setting in the squeezecenter config page. It was at 50%. Turning it to 100% helped, but it's still not as high as it should be. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Does anyone buy MP3s from Amazon?
On Thu, Aug 14, 2008 at 9:58 PM, Goodsounds [EMAIL PROTECTED] wrote: So, what is your take on the CD quality issue? I personally prefer vinyl to plastic based on my listening experiences, but do you think that to be unfounded? Wow. A vinyl fan who is actually open to the possibility that CDs might actually be better? I think you are the first I've ever seen. This has been a hotly debated topic ever since the CD came out in the early 80s. This is unfortunate because there's a perfectly good way to settle the issue scientifically, once and for all. My reasoning is as follows. The purpose of an audio reproduction system is to reproduce the original signal as faithfully as possible. It should not add or take away from that signal in any way. Making a recording sound good is the job of the recording engineer; it is not up to the reproduction system to modify the engineer's work product in any way. Ergo, if you can't tell the difference between the original and reproduced signal, then you can't complain about the quality of that reproduction system. So here's what you do. You start with your favorite test signal in analog form. It can be from any source you like, including a vinyl record; your choice. You produce a digital version of that signal by running it through a 44.1 kHz 16 bit/sample A/D and D/A, being careful to set the overall analog gain to exactly unity (0 dB). Now we have two analog signals, one direct from the input source and the other having been passed through the codec. Next you construct two audio switches. The first switch, the listener switch, has two positions labeled simply A and B. The second switch, the control switch, has four positions and is physically placed so that the listener can't tell its setting. The control switch affects the behavior of the listener switch as follows: 1. Positions A and B both play the analog signal. 2. Position A gives the analog signal, position B gives the digital signal. 3. Position B gives the digital signal, position A gives the analog signal. 4. Positions A and B both give the digital signal. It's important to construct the circuits so the listener has absolutely no cues as to the setting of the control switch. For example, there must be no audible switching transients or changes in gain, latency, bandwidth or phase. This means ensuring there is no perceptible latency in the A/D - D/A chain. You can see what comes next. The experimenter randomly chooses a control switch position. The listener must then determine whether the listener switch does anything. Note: the listener is NOT asked to determine which position is analog or digital, or to evaluate which one sounds better. He only has to tell if the switch does anything or not. You do this a number of times, each time setting the control switch to a random position determined by a pair of coin tosses (the experimenter should NOT choose the switch position by himself). The bottom line is simple. If the listener can't tell with better than chance accuracy whether his switch actually selects between the original and digital signal sources, then it is clear that the digital path is not modifying the signal in any detectable way. And if he can't detect the difference, he can't claim that the digital system is somehow worse. The listener may have other perfectly reasonable reasons to prefer a vinyl version of a recording over the CD. For example, the mixing and equalization on the LP might be subjectively better. But that is not something you can blame on the CD (or digital audio) per se; the fault is the recording engineer's who prepared the signal given to the CD mastering system. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] problem with ogg file playback
Mnyb wrote: I don't have any OGG files myself, so i can not experiment with this, somebody else have to chime in here. Do experiments with this, you wont damage anything, you can always restore the settings to what it was before. A guess would be that setting the OGG Vorbis box in OGG Vorbis to disabled (is native per default ) would do it. Then I suppose SC would use either AIFF, FLAC or MP3 to play ogg files. I've just run into this same problem with a set of ogg files from the 15 October 2004 Live at the Patio concert by Robert Walter's 20th Congress hosted on archive.org: http://ia310125.us.archive.org/2/items/RWTC2004-10-15.akg.flac16/ If I disable built-in player ogg decoding in the files configuration tab, then Squeezecenter transcodes ogg to FLAC that my Squeezebox 2 plays just fine. I can't determine which encoder or options were used to produce the troublesome ogg files. I downloaded the FLAC version of a song from that set. It plays fine, of course. I encoded it into ogg using oggenc version 1.2.0 on Linux with default options. Unlike the version on archive.org, my locally created ogg file plays fine on my Squeezebox 2. So it's confirmed. The problem is in the Ogg Vorbis decoder in the Squeezebox firmware. It cannot decode some Ogg Vorbis files that other decoders handle just fine. Since there appears to be no easy way to tell which files can't be decoded in the player, the only viable workaround until the firmware can be fixed is to completely disable built-in Ogg Vorbis decoding and decode it on the server. I like Ogg Vorbis and the other open audio formats as much as anyone, but I've been wondering about its utility built into a player. I guess it's useful when streaming remote radio stations (or song archives) that generate it when your local computer is off. Since Ogg Vorbis is a better lossy codec than MP3, in theory it could do better than MP3 for bit rate limiting. But it looks like MP3 is hardwired into the bit rate limiter, probably because it was the only lossy codec available in the player at the time. There's no reason Ogg Vorbis couldn't become the default bit rate limiter for Squeezeboxes that implement it correctly. That could also avoid possible legal problems in relying on LAME. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Minor nit: lossless codecs are never CBR
I know this is a really minor nit, but I've noticed it for a long time. Slimserver displays, on the Squeezebox and the web page, the bit rate for FLAC and other lossless material as CBR (Constant Bit Rate). Lossless compression algorithms like FLAC, ALAC, Monkey's Audio, Shorten, etc, are never constant bit rate. They must vary with the redundancy in the audio stream. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Replacing mDNSResponder with avahi
I already run avahi (a Bonjour daemon) on my Linux box and I'd rather have it advertise my slimserver instead of having slimserver run its own copy of mDNSResponder. In the past I've done this by manually creating the appropriate avahi config file and commenting out the mDNSResponder invocation in Slimserver. But avahi is getting pretty popular now so I'm wondering if any thought has gone into making slimserver work with it a little more naturally. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: SlimServer - A pain in the ass...
Lost Viking wrote: It takes ~45secs from clicking to diplaying the result page. Is this normal? Will it be as slow using the Transporter (once I have it in my hands, it is still on its way..)?? *shudder* No, that's definitely not normal. IMHO, the Slimserver web interface could be a lot faster, but here it's still only a couple of seconds at most. One of the recent Slimserver updates apparently added a lot of internal threading. That noticeably sped up the web interface. Make sure you're running recent code. Let me add a hearty amen to the other suggestions to run Slimserver on Linux, not Windows. Windows is a terrible server OS. Scratch that, Windows is a terrible OS, period. Jettisoning all that virus scanning cruft is just one of many reasons to dump it. Here are some other suggestions to speed up a file server. First, avoid external USB hard drives. In my experience, a USB 2.0 external drive is less than half as fast as an internal drive. Second, if you have the cabinet space and the budget, consider RAID. Without RAID (or a current backup), a failed drive is a major disaster. (Do you really want to re-rip a thousand CDs?) With RAID, a failed drive is just a minor nuisance. RAID can also speed up read performance quite noticeably. Linux has a very nice software RAID subsystem that avoids having to spend money on hardware RAID controllers. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Ogg Encoding Options
I haven't seen any comments on my problems playing Ogg files with 6.5.1. Can anybody confirm that they *can* play Ogg files on 6.5.1 and a Squeezebox 2 or 3 with firmware version 71 without server decoding? Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: First sec of song getting clipped off
Eric Seaberg wrote: I'd really rather NOT re-rip everything with FLAC. I have thought about it just to get the extra quality bump, but iTunes won't read them which, for me anyway, REALLY puts a crimp in my tag editing and organization for SlimServer. As a Mac user, there just aren't as many options to work with FLAC yet. This was a problem for us too until I discovered mt-daapd, an open source music server (functionally somewhat similar to Slimserver) that speaks DAAP, Apple's protocol for sharing iTunes collections over a LAN. I run mt-daapd alongside Slimserver on the Linux box that has our music library. The clients see iTunes' native file formats (.mp3, .m4a, .m4p, .wav) unchanged, while non-iTunes formats like .flac and .ogg automatically appear to iTunes as WAV files. The two servers coexist nicely. We can now use iTunes/mt-daapd for its superior search and seeking features and Slimserver for when we want to play something through a Squeezebox and good speakers. Unfortunately, DAAP is read-only, so iTunes cannot edit tags on a remote server. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: First sec of song getting clipped off
Eric Seaberg wrote: I'd really rather NOT re-rip everything with FLAC. I have thought about it just to get the extra quality bump, but iTunes won't read them which, for me anyway, REALLY puts a crimp in my tag editing and organization for SlimServer. As a Mac user, there just aren't as many options to work with FLAC yet. I've standardized on FLAC for my library collection (with subsequent conversions to Ogg Vorbis, MP3 or AAC as needed for portable jukeboxes), but I also like to rip with iTunes for the convenience. So my technique is to use ALAC when ripping, copy the ALAC files to the Linux server running SlimServer, and batch convert ALAC to FLAC with a little perl script I just wrote. The only hard part is converting the tags, but I think I do pretty much the right thing. Anybody who wants my script is welcome to it. --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Ogg Encoding Options
rgmiller1974 wrote: Just tried that; no luck. Tried both compiling from source and a pre-built 32-bit binary (I'm running an Athlon64 so the one I compiled was 64-bit.) No matter what I use, I get the same errors from slimserver.pl: 2006-12-19 22:11:59.1207 Error: Decoder does not support file format, skipping track 2006-12-19 22:11:59.1209 Error opening current track, so mark it as already played 2006-12-19 22:11:59.1213 Backtrace: frame 0: Slim::Player::Source::errorOpening (/opt/SlimServer_v6.5.0/Slim/Player/Source.pm line 634) frame 1: Slim::Player::Source::notSupported (/opt/SlimServer_v6.5.0/Slim/Networking/Slimproto.pm line 657) frame 2: Slim::Networking::Slimproto::_stat_handler (/opt/SlimServer_v6.5.0/Slim/Networking/Slimproto.pm line 387) frame 3: Slim::Networking::Slimproto::client_readable (/opt/SlimServer_v6.5.0/Slim/Networking/Select.pm line 238) frame 4: Slim::Networking::Select::select (./slimserver.pl line 487) frame 5: main::idle (./slimserver.pl line 440) frame 6: main::main (./slimserver.pl line 1039) I seem to have run into this same problem immediately after updating to today's (12/28/2006) release of 6.5.1 from 6.5.0. I'm not sure of the build date of the previous version; the timestamp on slimserver.pl was October 25. Today's build came with a player firmware update to version 71, and now neither my Squeezebox 2 nor my Squeezebox 3 will play any of my Ogg Vorbis files. WAV, FLAC and MP3 still play fine. Unfortunately, I updated both players' firmware files so I can't test with a 2 or 3 that hasn't been updated, and I don't remember the previous firmware version. My old Squeezebox 1 still plays Ogg Vorbis fine. I expected this because it doesn't handle Ogg natively, nor has it seen a firmware update. So server transcoding from Ogg to WAV still works with the current version. My guess is that either the current firmware load for the Squeezebox 2/3 somehow broke Ogg Vorbis decoding, or the slimserver somehow broke its handling of Ogg Vorbis for those models. If the firmware is indeed broken, is there a simple workaround to force transcoding of Ogg Vorbis to WAV for Squeezebox 2/3? Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Ogg Encoding Options
Phil Karn wrote: Today's build came with a player firmware update to version 71, and now neither my Squeezebox 2 nor my Squeezebox 3 will play any of my Ogg Vorbis files. WAV, FLAC and MP3 still play fine. Unfortunately, I updated both players' firmware files so I can't test with a 2 or 3 that hasn't been updated, and I don't remember the previous firmware version. I figured out how to downgrade my Squeezebox 2 to the previous firmware version, 64. That does *NOT* fix the problem; Ogg Vorbis files still won't play on the 12/28/2006 version of 6.5.1. The log shows the following backtrace: 2006-12-28 21:50:42.6919 Backtrace: frame 0: Slim::Player::Source::errorOpening (/usr/local/SlimServer_6.5_v2006-12-28/Slim/Player/Source.pm line 635) frame 1: Slim::Player::Source::notSupported (/usr/local/SlimServer_6.5_v2006-12-28/Slim/Networking/Slimproto.pm line 658) frame 2: Slim::Networking::Slimproto::_stat_handler (/usr/local/SlimServer_6.5_v2006-12-28/Slim/Networking/Slimproto.pm line 387) frame 3: Slim::Networking::Slimproto::client_readable (/usr/local/SlimServer_6.5_v2006-12-28/Slim/Networking/Select.pm line 238) frame 4: Slim::Networking::Select::select (/usr/local/slimserver/slimserver.pl line 492) frame 5: main::idle (/usr/local/slimserver/slimserver.pl line 445) frame 6: main::main (/usr/local/slimserver/slimserver.pl line 1071) FLAC, MP3 and WAV (e.g., transcoding from AAC) still work fine. I'll keep digging. --Phil ] ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Ogg Encoding Options
Phil Karn wrote: I figured out how to downgrade my Squeezebox 2 to the previous firmware version, 64. That does *NOT* fix the problem; Ogg Vorbis files still won't play on the 12/28/2006 version of 6.5.1. The log shows the following backtrace: I rolled everything back to 6.5.0 and my Squeezebox 2 and 3 *still* can't play any Ogg Vorbis files. Yes, their firmware loads reverted to version 64. I even forced a player factory reset. I'm absolutely sure these files played fine before I installed 6.5.1 today. Now I'm *really* confused. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Ogg Encoding Options
Phil Karn wrote: If the firmware is indeed broken, is there a simple workaround to force transcoding of Ogg Vorbis to WAV for Squeezebox 2/3? I found the workaround: simply uncheck the Ogg Vorbis/Ogg Vorbis line in File Formats under Server Settings. Slimserver now transcodes to WAV and avoids whatever problem kept the player from decoding Ogg Vorbis. Still trying to figure out why the original problem appeared, and why it didn't go away when I reverted to 6.5.0 and the earlier firmware. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Radioio Deadhead?
Peter wrote: Or try this: mms://radioio-dead-hi.wm.llnwd.net/radioio_dead_hi?MSWMExt=.asf (note the underscores) Works for me in 6.2.2. Thanks! --Phil ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: SB sends no DHCP host name
0xdeadbeef wrote: Unfortunately, in my case the DHCP server is running on my DSL modem/router and there's nothing to configure there. Though it should give the SQ the same IP every time due to MAC caching, I have the feeling it doesn't. Indeed, I observed at least 3 different IP addresses in the few days since I obtained my SQ. Then again, all devices whith a DHCP name get the same IP all the time. You really need to trace the packets to know what's really going on, as I know of at least two different ways that a given host might keep a stable IP address. First, the client might cache leases in nonvolatile memory across power cycles or reboots and simply request the previous IP address when rebooted. A DHCP server will almost always grant a request for a specific IP address as long as it's in that server's pool and no other client has a lease for it. Second, the server might cache client MAC addresses and previous leases (expired or still valid) and reassign the previous IP address even when the client doesn't ask for it. It's helpful to know the DHCP protocol exchange. A cold start looks like this: Client: DHCPDISCOVER [who can give me an IP address?] Server: DHCPOFFER a.b.c.d [I'm a DHCP server, and I can offer you this address] Client: DHCPREQUEST a.b.c.d [I'd like to use this address] Server: DHCPACK a.b.c.d [Okay, you've been officially granted this address] A booting client that wants to use a previously assigned address will jump directly to the DHCPREQUEST message. The server can respond with a DHCPACK as before, or it can respond with a DHCPNAK (negative acknowledgement), rejecting the request. At this point the client will fall back to the DHCPDISCOVER step. Ideally the Squeezebox would save DHCP leases across reboots, and your DHCP server would hand out very long leases to minimize the chances of that address being given to another client. But there are other ways to ensure that a Squeezebox always gets the same IP address, including bypassing DHCP altogether and assigning a static IP address. That might be your best bet assuming your Squeezebox doesn't move often. Just make sure that you set up separate blocks of addresses for static use and dynamic assignment, so your DHCP server doesn't hand out the address already in use by your Squeezebox. DHCP clients are supposed to detect this by ARPing for an assigned address before actually using it, but it can fail if the conflicting host with the static assignment happens to be offline at the time. --Phil Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB sends no DHCP host name
0xdeadbeef wrote:
When the Squeezebox requests an IP adress from a DHCP server, it doesn't
seem to send its own host name.
E.g. in Linux (Debian/Ubuntu), you can send the hostname to the DHCP
server by adding the following lines to /etc/dhclient.conf:
send dhcp-client-identifier 00:00:00:00:00:00; // enter mac address
here
send host-name host name; // change to your
host name
Since the Squeezebox doesn't send a host name, it's named noname by
the DHCP server, which is kinda ugly.
So I'd suggest to send the host name that was entered in the player
setup.
I do it in a way that doesn't require the Squeezebox to send a host name.
My DHCP server is ISC DHCPD on Linux. /etc/dhcpd.conf has an entry for
every regular host on my LAN, including Squeezeboxes. Each entry
specifies the MAC address and a fixed-address entry for that system. So
each Squeezebox gets the same IP and DNS name address every time it boots.
Here's a sample entry in /etc/dhcpd.conf:
host skinner {
hardware ethernet 00:04:20:06:1a:56;
fixed-address skinner.local.ka9q.net;
}
The zone local.ka9q.net contains A records in the 192.168.1/24 subnet
for hosts that don't need global IPv4 addresses. skinner.local.ka9q.net
resolves to 192.168.1.13, so that particular Squeezebox always gets that
same IP address.
The DHCP server keeps a separate pool of IP addresses for clients whose
MAC addresses don't have specific entries (e.g., a visitor's laptop).
--Phil
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB3 review at Silent PC Review
mflint wrote: Forgive me if this has been mentioned before: http://www.silentpcreview.com/article287-page1.html Overall it's a good review, and I'm glad he liked the Squeezebox 3, but early on he makes a few erroneous statements that might reduce his credibility with other readers. And it's clear that he comes from the expensive has to be better than cheap school of audio that has kept so many speciality audio companies in business over the years. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Best way to back up music on Macs
Marshall Clow wrote: So I use a Mac, and most of my music is on a laptop. Last year I had a laptop stolen, and had to rip everything again. So what i sthe best way to back up music on a Mac? Is there an easy way to get iTunes to access an external harddrive, or should I just burn everything to DVDs? I would burn everything to DVDs - it's not like the music is going to change. I recommend backing up to an external hard drive (or drives) rather than (or at least in addition to) burning DVDs. Hard drives have gotten really cheap. External drives are now less than $1/GB, and some internal drives are below half that cost. But even more important, hard drives are *much* roomier than DVDs so you don't have to keep switching disks during your backup. Writing to a hard drive is also *much* faster then writing to a DVD. Combined, these two features of hard drives makes it much more likely that you actually will spend the time to keep your backups complete and up to date. Also consider giving yourself some protection against drive failure with RAID. My ripped CD collection sits on a RAID-5 array, and that is in turn backed up on offline hard drives. We also keep the original CDs off site, making them less of a target for burglars. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] The servers that a Squeezebox sees
JJZolx wrote: I recently assigned my Windows XP computer a second IP address and switched to HTTP port 80 so that I could more easily address the SlimServer without a port, and so that I could run Apache on port 80 at another IP address on the same machine. SlimServer had been at 192.168.9.11:9000 previously. I'm using the --httpaddr command line option to designate the IP address. 192.168.9.11 (audrey) 192.168.9.30 (slim) running SlimServer, HTTP port 80 I have two SB2's on my network. Both see the server named 'audrey' at the .11 address, but don't see the server at .30. I had to key in the IP address to connect. If I get into the network setup on either SB, it always shows the nonexistent server. Is this a bug, with SlimServer incorrectly announcing that it's running on the .11 IP address? I suppose it is a bug, but I don't understand the point of what you're trying to do. By using the alternate port 9000, a Slimserver can easily co-exist with Apache on the same machine with a single IP address. I haven't checked, but it seems likely that the Squeezeboxes discover the slimserver by their zeroconf advertisements. They're made symbolically, not numerically, so the Squeezebox that sees a Slimserver advertisement will assume that it can connect to it on port 9000. Again, what's the point of what you're trying to do? ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Client/server docs
Two related questions. I've been looking at the protocols between the Squeezebox and the Slimserver with ethereal and I've noticed that the protocol specifications bundled with the Slimserver appear to be incomplete. I see commands and data structures that aren't documented. Is a more recent version available? If I understand the protocol correctly, the server hands the Squeezebox a command that basically says fetch the following URL, play the resulting data stream with the following DAC settings, and let me know when you're done. (The DAC settings are ignored with MP3 and FLAC files, as those settings are embedded in the data stream.) This seems pretty straightforward and flexible. During playback the Squeezebox continually lets the server know how it's doing, e.g., by reporting buffer utilization, etc, and the server tells the Squeezebox exactly what to show on its screen. Even something as simple as screen scrolling happens only when the server tells it to. But I notice that every HTTP 'get' operation is handed back to the Slimserver, even when it's an Internet Radio stream. The Slimserver fetches the data from the source and relays it to the Squeezebox. I suppose that makes it possible for multiple Squeezeboxes to play the same stream without duplication over the wide area network connection. Still, it would be handy if I had a hook to let me pass my own URL directly to the Squeezebox, without application-layer relaying through the Slimserver. This might be useful if I wanted to use my Squeezebox as a dumb D/A converter for some special application such as Internet telephony, or driving the Squeezebox DAC directly from a program of my own. Does anybody know if such a raw DAC access hook already exists in the Slimserver? Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: 20Kb/sec bandwith used and it's not even playing anything?
seanadams wrote: Who cares about 20Kb/s on a LAN? Nobody, at least not on a LAN. But it can be a problem if your Squeezebox and its server are separated by a shared wide area network. The Squeezeboxnetwork server appears designed to minimize network overhead, e.g., by updating the clock only every minute. I once took my Squeezebox to work and had it tunnel back home over SSH. It worked, but the overhead was rather high and I didn't want to put that much continuous load on my DSL uplink. It seems better to just take your music with you. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Weird DHCP bug on Slimserver 3 with latest firmware
kdf wrote: I have 192.168.1.34 as a static assignment for the mac address of the player (listed on the bottom and in player settings). however, the lease table shows an entry for 20:05:73:00:00:0C and has been given 192.168.1.100. i have 100-149 as a 7-day dynamic block of leases. Whether DHCP works under these conditions may depend on the particular DHCP server you're using. My packet traces showed that the Squeezebox DHCP requests were being sent with the correct MAC address in the Ethernet source field, but the hardware address field in the DHCP request packet was the funny one you observed (20:05:...). My ISC DHCP server running on Linux then answers with a unicast response to the funny (20:05: ...) address, and since the Ethernet controller in the Squeezebox is apparently not listening for that address, it never gets the response. So eventually the DHCP attempt fails and the Squeezebox reverts to a self-assigned address in the 169.254 block. But it's my understanding that it's legal for DHCP servers to broadcast all of their responses (i.e., to the Ethernet broadcast address ff:ff:ff:ff:ff:ff). This lets multiple DHCP servers serving the same subnet to easily observe each others activities. If this happens then the Squeezebox, which is also presumably monitoring broadcasts, will get its DHCP responses and complete the exchange. I'm guessing that's what's happening on your network, but without packet traces I can't say for sure. I suppose I could see if my DHCP server can be configured to broadcast its responses, and to try some more packet tracing experiments to flesh out the details of just how the SB behaves with bridging enabled. But as soon as I saw that it was munging frames I turned it off just so I could get my box playing music again. I don't have an immediate need for the bridging feature, but it would be nice to have it working someday. 802.11g bridges are surprisingly expensive, so it's a nice feature to have in the Squeezebox. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Weird DHCP bug on Slimserver 3 with latest firmware
I just received a pair of Slimserver 3s and opened one of them up. When I configured it for my wireless network, it quickly configured itself with DHCP and downloaded new firmware, version 28. It then came back up, auto-configured itself again and worked fine for a while. Then I unplugged it to move it into another room. I also enabled Ethernet bridging, to try it out. This time the unit was unable to complete DHCP. Some packet tracing showed why. The unit sent out a DHCP request with its factory-assigned MAC address 00:04:20:06:1a:50 in the Ethernet source field but the sender hardware address in the DHCP request was the unusual value 20:05:73:00:00:0c. When my DHCP server responded, it put this second MAC address into the destination field. Since the Squeezebox was presumably listening for its factory-assigned MAC address, it never heard the response. So it kept resending its request and my server kept sending the same unheard answer. Eventually the Squeezebox timed out of DHCP and gave itself a self-assigned IP address in the 169.254 block, which I do not use. If I manually set the appropriate IP addresses, all works fine. Only the DHCP client appears to be broken. The DHCP server is ISC dhcpd running on Linux. It works fine with everything else in my house. Anybody else see anything like this? Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Weird DHCP bug on Slimserver 3 with latest firmware
A followup: I forced a reset to factory defaults (by holding down the ADD key and cycling power) and the problem I encountered with DHCP disappeared. DHCP worked fine. Then I turned on Ethernet/WiFi bridging, and the problem appeared again. Neither the Squeezebox nor the Powerbook I have plugged into the Ethernet port on the Squeezebox can do DHCP. I see some broadcast traffic from my wireless network coming through on the Ethernet on the Powerbook, but I can't seem to connect to anything on my home network with either IPv4 or IPv6. Packet traces at the DHCP server seem to show that the Squeezebox is writing its own MAC address over the source address fields of the packets it is relaying from the Ethernet, something a bridge shouldn't do (bridges are transparent to MAC frames). And when bridging is enabled, the Squeezebox's own DHCP packets have the correct MAC address in the Ethernet link level source address field, but carry a bogus MAC address in the DHCP application-level packet so the Squeezebox doesn't hear the DHCP server responses. Basically, it appears that Ethernet bridging is completely broken, and enabling it disables the Squeezebox as well. Again, this is firmware version 28 on the Squeezebox 3. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Weird DHCP bug on Slimserver 3 with latest firmware
kdf wrote: This sounds a lot like this report: http://bugs.slimdevices.com/show_bug.cgi?id=2221 Thanks for the pointer. This is indeed exactly the problem I'm seeing. That report specifies firmware version 22. I'm running 28, so apparently the bug has been in several versions. Is version 28 the latest? i've had the same issue, as far as MAC. The difference in my case it that it does eventually get a dynamic IP, and works. The router has a static IP assignment set up, but that is not the resulting IP. I assume this was with Ethernet/WiFi bridging enabled? When you say that you eventually get a dynamic IP address, is it in the block you normally use on your network, or is it in the 169.254 block? That's the zeroconf address block set aside for self-assignment by hosts when they're unable to get an answer from a DHCP server, and the Squeezebox seems to follow this convention as well. Your network might have been set up to work with 169.254 addresses as well as your usual block, so that may be why it seemed to start working. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Obtaining mp3s/flac/whatever legally
max.spicer wrote: I've got a list of tracks that I'd like to own, but don't necessarily like the artists enough to go out and by the relevant albums (yet). I can't help you if you've got a list of specific tracks by artists on RIAA labels. But if you're looking for a good way to obtain MP3, FLAC and other digital music files without DRM, and with very liberal copying and usage rules, check out Magnatune (www.magnatune.com). They're *not* a music service like iTunes or emusic. They're an independent record label, that happens to do business very differently than most. You will *not* find well-known acts on Magnatune, as they can only sign new artists that haven't already signed away their souls to a regular label. Sure, a lot of what Magnatune has doesn't really interest me, but that's just as true (if not more so) for the big, evil RIAA labels. But you probably will find *something* you like. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] mDNS broadcasts on all IP addresses
slimbls wrote: Hi, slimserver newbie here...I have a suse 9.2 linux system that's my firewall and media server (please, no bottle tossing this way). After I installed slimserver (6.1.1) I asked it very nicely to only use my internal ethernet, but I'm still seeing UDP packets from myself on port 5353 to 224.0.0.251. How can I nicely tell mDNS to not broadcast on my external ethernet adapter besides a couple of lines in iptables? mDNS stands for multicast DNS and that's how it works. Multicasting is a lot like broadcasting, but scales much better because you can be selective about who receives your packets. mDNS is designed to let you find services and hosts on your local LAN without needing a server on your local network. Requests for IP addresses and services are multicast on the local LAN. Whichever machine has the requested information will respond, and the others will ignore it. mDNS is currently used most heavily by Mac OS X, which calls it either Rendezvous or Bonjour, and there are ports of mDNS to Linux. 224.0.0.251 is the standard multicast destination address for a mDNS packet. Your router won't forward multicast packets unless it's specifically designed and configured to be a multicast router, which it almost certainly won't. Otherwise it'll just ignore them, and they'll stay on your local network. So there's nothing to worry about. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Source for bin programs?
Where can I find the source for the various binaries included in the Slimserver package? I'm particularly interested in the source for the mDNSResponderPosix program, as I'm trying to set up mDNS on all my Linux machines to make them play better with our Macs. It appears that the Slimserver perl script writes entries for three services into the mDNSResponder's config file and then starts it. I'd rather start a separate system-wide mDNSResponder daemon so I can easily configure it to advertise all the services on my Linux box, not just the Squeezebox stuff. Do the Squeezeboxes actually use the mDNS stuff in any way, or is it just there to make the server's web pages visible to Macs that happen to be browsing the network with Bonjour/Rendezvous? Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] AAC playback background noise. Slimserver6/FreeBSD
icestorm wrote: However...When I try to play AAC music from my FreeBSD server, (which is most of my music collection), I can hear a sound like a constant wind in the background, which becomes intolerable when I increase the volume. Please note that I can hear the song fine! This problem does not happen with mp3 encoded music or radio. I seem to be having a somewhat similar problem. I just set up AAC decoding on slimserver 6.0.2 on Linux. It works fine with my original Squeezeboxes, but when playing on a Squeezebox2, the audio breaks up into loud noise about a second into each AAC song. I just isolated the problem. It only occurs when two conversions are done in tandem, e.g., AAC-PCM-FLAC or AAC-PCM-MP3. This is why the problem only appeared on the Squeezebox2, because the transcoding from AAC to FLAC is done in two steps. The original Squeezebox doesn't support FLAC, so faad converts directly to WAV. To verify this theory, I set bit rate limiting on one of my original Squeezeboxes to force transcoding to MP3. Sure enough, the same problem appears. I don't yet have a clue as to *why* this is happening. But it does, every single time. It seems almost as if a byte of raw PCM is somehow being dropped in the pipe between the two coders, causing a mis-synchronization that sounds like loud noise. Whether that's actually happening, I don't know yet. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Noise Spike at Song Startup
warc1 wrote: have experienced. The most annoying is a loud noise spike that occurs during the start of some songs when playing a long playlist. Is the spike really, really short and sharp, and right at the beginning of the track? If so, this could be the sound of the WAV header on the front of the file being misinterpreted as raw PCM. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless
Frank Xavier Ledo wrote: First, It seems that all songs start out with a pop. I am guessing that the command line options I set in convert.conf were incorrect and are resulting in a linefeed or space at the start of the song. What I used is: mov wav squeezebox * [alac] $FILE$ As a test I tried using alac to convert the file from *.m4a to *.wav, and added the wav file to my playlist. There were no pops. Second, alac supports PCM output. Is there any benefit to using this instead of wav output? The pop is almost certainly the sound of the WAV file header being misinterpreted as raw PCM audio. Try selecting raw PCM output from alac and see if the problem goes away. Are you sure you're using the convert.conf entry you gave above, and aren't actually transcoding to another format? In the convert.conf file entries that pipe two codecs together to transcode from one compressed format to another, the two codecs must agree on their interchange format. The existing convention *seems* to be raw little-endian 16-bit stereo PCM *without* a WAV header. If the first program outputs wav format when the second expects raw PCM, you'll get the pop. I'm not exactly sure which native format the Squeezebox 1 expects, WAV or raw PCM. Anybody know? --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB1 buffer size
Sean Adams wrote: When I started designing the Squeezebox1 hardware in 2002, I fully realized that an enormous buffer would be desirable. However, the architecture (which was chosen based on a long list of goals including ethernet/wireless capability, ability to drive a graphic VFD, OS performance, etc) unfortunately did not have an SDRAM interface, only SRAM, which meant that a very large (several MB) buffer would not be possible. Dean and I did a great deal of testing and never saw any problems on wired ethernet under any OS. On wireless networks there were some issues at first, which were quickly eliminated, most of them anyway, with some careful tuning of the TCP stack. I understand your design constraints. Memory is nice, but it can also be expensive and you don't want your box costing more than it really has to. That's quite reasonable. What we found was that in the real world there were still a few problems. I spent many weeks studying packet dumps and optimizing TCP (http://www.seanadams.com/ip2k), testing on Windows, Mac, and Linux, getting feedback from customers, and making improvements. Yup. Many stacks do have glitches, although I think the later Linux stacks behave very well, especially when the entire path is just a few high speed Ethernet hubs. A bigger issue, I think, are the OS and disk scheduling algorithms. It is no secret that a bigger buffer would be nice - in fact I think this request has been in our public bug database since its inception. Unfortunately the only way we can make the buffer larger is to make new hardware with a larger buffer, which is exactly what we've done. Optimizing streaming performance is still an active goal. But I don't think that buffer *has* to be huge. If it does, then that's a symptom of brokenness someplace else, specifically in the server and the way it is treated by the operating system on which it runs. PCM streaming on Squeezebox1, even with its 256K buffer capacity, works as advertised in nearly all environments, unlike my car which can only reach its advertised top speed on less than 0.01% of the road surface in the USA. I realize this is a retarded analogy and not a kind response but consider this: we are more open than any hardware company (that I know of) in terms of admitting where there's room for improvement (bugs.slimdevices.com). We view this information not as a liability, but as priceless guidance in how to make our products better. Um, I assume you didn't mean that as a serious analogy! A better analogy would be to the per-mile probability of my car suddenly and without warning, seizing up and stopping dead in the middle of the freeway. Then, after a few seconds, the tires screech and it suddenly lurches back up to 65 mph just as unexpectedly. :-) Certain issues are simply not addressable in software (802.11g support, as another example). For those issues we develop new hardware. Understood. Since you advertised those hardware limitations, I can't complain. Your transcoding scheme to optionally limit the network bit rate to something it can support was a very nice touch. Finally, as protection we provide a 30-day no questions asked return period. If the product doesn't work the way you want it to, or even if you just have a change of heart for some reason, we'll take it back. Well, that's problematical when the problem is in software, not hardware. Again, I have no complaints about the Squeezebox hardware, either version 1 or version 2. If the hardware were broken, mis designed or otherwise unusable, then it would be easy to decide to return it in the 30 day period. But the hardware is all fine; all of the problems I've encountered have been in server software, and that makes returning the unit a much harder call. You never know whether a given problem that you consider really serious will be fixed tomorrow or next week or next month or next year. Believing strongly as I do in the power of open source, I have decided to keep all three Squeezeboxes and wait for the software to improve. And that can be frustrating. Yes, I could roll up my sleeves and jump in and hack the code myself, but the Slimserver package is already a very large chunk of code that presents a dauntingly steep learning curve to anyone who wants to modify it. Confronted by it, I'd be strongly tempted to start over from scratch, or by adapting existing, mature mechanisms that I already know to work well (e.g., adapting the standard printer spooling system to manage queues and play lists for a Squeezebox.) I don't know what else to say - we vastly improved PCM streaming performance by adding a huge buffer, adding 802.11g wireles support, and adding lossless compression. At the same time we added a whole slew of features in SlimServer 6 which improve SLIMP3, a product which we began selling out of my garage in 2001, and of which we have not sold a single unit since 2003. I realize that these are not huge
Re: [slim] Slim Devices SB2 disappointment SB for sale.
Robin Bowes wrote: Can you show me where this claim is made? I'd be very surprised if this is true. For a start, the wired port on the SB1 is only 10MB/s (I can't find a spec. sheet to confirm this, but the last point here [1] says: - faster 100Mbps wired ethernet interface I do believe you're right; it's 10 Mb/s on the SB1. I checked it by plugging it directly into my PowerBook and looking at the interface settings, and also by plugging it into a different hub that indicates link speed on the LEDs. But this doesn't really matter. A raw, uncompressed PCM audio stream still takes up only 14% of a 10 Mb/s Ethernet port, so there's no reason it should cause any kind of playback interruption unless it's used on an ancient 10 Mb/s non-switched hub with lots of contending traffic. I got rid of all my hubs years ago. Every network port is switched and supports full duplex up to 100 or 1000 Mb/s, depending on the specific switch. The Linux box running SlimServer has a 1GB/s connection, and nothing (server or network) is ever loaded very heavily. [1] http://www.slimdevices.com/su_faq.html#about2-difference I've got a wireless SB1, and until recently, I had no problems with dropouts caused by network bandwidth (I too play flac files decoded on the server and streamed as raw PCM). I have two SB1s, but both are wired. I wanted to wait until 802.11g was supported before buying a SB, so I got one of the SB2s with wireless. But my playback interrupt problems were all over wired paths. I would have expected problems on 802.11b, but not on an all-wired path with plenty of capacity. I agree with the point you make about threading and making the streaming part of slimserver work better, but I don't think the SB or slimserver is particularly at fault in causing your dropouts - there must be something in your environment that is causing the problem. Maybe the port you've got the SB plugged into is not auto-detecting the 10Base-T link? Have you checked? I'm quite sure all my LAN switches are working fine. The playback interrupt problem is clearly due to sub optimum task scheduling on the server. If I renice the slimserver and related tasks up a few points, the playback interruptions disappear, but at the expense of slowing down everything else on the server whenever the Slimserver wants to do some sustained maintenance activity like scanning the music filesystem and rebuilding its database. The Slimserver code should run at high priority only in its real-time-critical sections, i.e., those directly involved in playing music. Everything else (e.g., the UI) should run at normal priority. Database reconstruction could even run at below-normal priority, just to be nice to the other users. Another way to minimize playback interruptions is to use lots of read ahead buffering inside the Slimserver playback path. That covers you in case the disk is suddenly pre-empted by another urgent I/O-intensive application. And if you can decompress and buffer up a lot of raw PCM inside the server, then you're also covered in case a high priority compute-bound job comes along and pre-empts the FLAC/Ogg Vorbis/AAC/etc decompresses (which are at least slightly CPU-intensive). If you can manage to buffer up a lot of raw PCM ready to transmit, then even if the server is busy running other applications it should be able to spare the few quick interrupt service calls needed to move that PCM to the Ethernet transmitter and then to the Squeezebox. Obviously if the system running Slimserver doesn't have, on average, enough disk I/O cycles and CPU cycles to supply a full-rate stream to the Squeezebox, then none of this will help much. But there's no reason why a fast, lightly loaded machine like mine should have frequent problems keeping the Squeezebox happy even when the occasional unrelated load-burst comes along. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: SB2 startup glitches
Additional comment: the crunching during startup does *not* occur with the original SB running off the same v6.0.0 server. The problem happens only with the SB2, and only when playing FLAC or OGG, not MP3. Haven't tried other file types. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] kinks in the SB2?
Phillip Kerman wrote: First, mine goes blank for no apparent reason sometimes. Blank screen. I see that too. I don't think the unit actually crashes, but it can be disconcerting. Also, I'm trying to compare the digital out into my DAC to the internal DAC but the digital out can't stay locked (I think that's it... my receiver keeps reseting like it used to between PCM and MP3). I wonder if this is could be related to the crunchy distortion I reported last night with my own SB2. I can't confirm it, but it very definitely sounds like the firmware in the box is starving the DAC when it has to handle the sustained, high speed burst of incoming traffic that fills up the playback buffer with raw PCM data. If the DAC is indeed being intermittently starved, perhaps this is killing the clock on the S/P-DIF output and making it difficult for your external DAC to maintain lock. Does the problem happen on all files, or only those transcoded to raw, high speed PCM? And does it persist through the entire track, or does it only happen at the beginning? The crunchy distortion I notice on my SB2 only occurs on raw, high speed PCM, and only until the buffer fills. When that happens and the server backs off to its maintenance speed of about 1.4 megabits/sec, the distortion goes away. It just occurred to me that I could try forcing the Ethernet down to 10 megabits/sec and see if the problem still occurs. If it's indeed due to DAC starvation from lack of proper CPU real-time management, this might work around the problem by limiting the peak speed of the buffer-fill burst to only 10 Mb/s. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Slim Devices SB2 disappointment SB for sale.
Jack Coates wrote: http://www.google.com/search?hl=enlr=c2coff=1client=firefox-arls=org.mozilla%3Aen-US%3Aofficialq=linux+encrypted+swap+partitionbtnG=Search I'm aware of the various ways to encrypt a swap partition. They are obsolete in this age of cheap, large RAM modules. Again, a fun theoretical argument -- or are you saying this box has a lot of untrusted root-level users who are frequently working in shells on it? I know my server won't let me do anything of the sort without being root. No, I'm the box's only interactive user, though it also runs web and mail services that my wife also uses. However, the machine sits in my house, not a co-lo, and is thus potentially vulnerable to physical theft. I use encryption as appropriate to protect my employer's information and other sensitive information, but that can be rendered ineffective if encryption keys can persist on an unencrypted swap device. OK, I give -- the key here, as you identify in another message is that you're playing FLACs, and with that fact I think there's just not a lot to do except for SB2 and its bigger buffer. Yes, clearly things are stressed by my large collection of FLACs and the relatively small buffer in the SB1. But... Buffer starvation could theoretically be slowed or alleviated by reducing other tasks. For instance, I bet your vmstat looks like a few miles of bad road when you're browsing those 17K tracks on two ATA drives through the Web UI or rebuilding the cache. In theory a bunch of componentry could be isolated off into other processes so it would be non-blocking, but in the end your performance would still be questionable (UI and streaming and data management rely on each other and are going to block, sooner or later). You could try prioritizing traffic (tc) and processes (nice), but at the end of the day I'm guessing that it's probably not going to work unless you transcode to a lossy format on the fly. This will work not just in theory, but also in practice. I have a fair bit of experience in networking and real-time applications, and I'm convinced that carefully restructuring and reprioritizing the server tasks and threads responsible for real-time playback -- and separating them from non-real-time operations such as managing the database and driving the UI -- could completely eliminate *all* playback interrupt problems, even with my many big FLAC files and a small SB1 playback buffer. My LAN is a combination of switched 100-Base-T and 1000-Base-T segments that are never loaded anywhere near capacity. (Yes, it's also quite reliable; I've measured my packet latency and loss rates, and they're always near zero or zero, respectively.) My server has plenty of all the required resources (disk I/O bandwidth, CPU cycles and RAM) to decode a FLAC file and buffer the raw PCM far ahead of the playback pointer in the SB. So there's simply no fundamental reason why playback interruptions should ever occur. The problem with the existing server, just as you point out, is that the real-time and non-real-time server functions are bundled into the same tasks and threads, and insufficient attention has been paid to meeting real-time-critical playback requirements. Yes, the bigger buffer in the SB2 will definitely help (I have one on order) but I disagree that it's the only way or even the best way to solve the problem. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Slim Devices SB2 disappointment SB for sale.
Jack Coates wrote: You might want to do some research on modern virtual memory management... swap is necessary no matter how much RAM you have. I disagree. I see no reason for a swap partition when you already have far more physical RAM than most swap partitions used to be, and tasks never fail because of memory exhaustion. Swap partitions are also a potentially serious security hazard; passwords, encryption keys and other sensitive cleartext information have been known to persist on them for years. Anyway, I haven't seen how many tracks you have, but that machine is about four times more than the average Slimserver installation runs on. As I just posted in another message, I count 17,115 files in two separate 200GB filesystems built from RAID-5 partitions spread across 5 300GB SATA disks, with an additional disk as a hot spare. homer$ vmstat 1 25 procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 1 0 0 58992 298524 11343720029 8 2333 43 1 56 0 0 0 0 58992 298524 113437200 0 0 1023 1054 0 0 100 0 0 0 0 58992 298524 113437200 036 1028 1073 1 0 100 0 0 0 0 58992 298524 113437200 060 1062 1092 0 0 100 0 0 0 0 58992 298524 113437200 0 0 1021 1059 1 0 100 0 0 0 0 58992 298524 113437200 0 0 1020 1059 0 0 100 0 0 0 0 58992 298524 113437200 0 0 1018 1048 0 0 100 0 0 0 0 58992 298524 113437200 036 1031 1088 0 0 100 0 0 0 0 58840 298524 113437200 0 105 1045 1080 0 0 98 1 0 0 0 58840 298524 113437200 0 0 1021 1051 0 0 100 0 0 0 0 58840 298524 113437200 0 0 1025 1055 0 0 100 0 0 0 0 58840 298524 113437200 0 0 1020 1051 1 0 100 0 [this is a little unusual in that I normally have two copies of [EMAIL PROTECTED] running -- this is a hyperthreaded 3.2 GHz P4 -- but the Boinc server has been off the net for several days, and my machines have run out of work. Those tasks are always niced to 19 and consume minimal memory.] homer$ more /proc/1410/status Name: slimserver.pl State: S (sleeping) SleepAVG: 98% Tgid: 1410 Pid:1410 PPid: 1 TracerPid: 0 Uid:0 10080 1008 Gid:0 0 0 0 FDSize: 256 Groups: VmSize:98800 kB VmLck: 0 kB VmRSS: 95240 kB VmData:94804 kB VmStk:84 kB VmExe: 996 kB VmLib: 2756 kB VmPTE: 132 kB Threads:1 SigPnd: ShdPnd: SigBlk: SigIgn: 00011080 SigCgt: 80004007 CapInh: CapPrm: feff CapEff: homer$ top - 17:34:46 up 5 days, 6:08, 1 user, load average: 0.00, 0.01, 0.00 Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3% us, 0.0% sy, 0.0% ni, 99.2% id, 0.3% wa, 0.0% hi, 0.2% si Mem: 2076460k total, 2019228k used,57232k free, 298616k buffers Swap:0k total,0k used,0k free, 1134960k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1410 slimserv 15 0 98800 93m 2204 S 0.7 4.6 77:48.69 slimserver.pl 1356 mysql 16 0 127m 15m 2804 S 0.0 0.8 0:00.54 mysqld 4082 karn 15 0 10308 7476 3884 S 0.0 0.4 0:02.74 emacs 1467 asterisk 18 0 38568 5852 3580 S 0.0 0.3 0:01.08 asterisk 20875 proxy 15 0 7648 5360 1628 S 0.0 0.3 0:01.77 squid 1785 www-data 15 0 6808 4236 2868 S 0.0 0.2 0:00.03 apache-ssl [...] [obviously slimserver has quite an appetite for memory. However, it's still only a small fraction of the 2GB on the system.] I note several other slimserver related tasks on the system: homer$ ps -elf | grep slimserver 5 S slimser 1410 1 1 75 0 - 24700 - Mar16 ? 01:17:52 slimserver 0 S slimser 1443 1410 0 76 0 - 406 - Mar16 ? 00:00:00 /usr/local/slimserver/Bin/i386-linux-thread-multi/mDNSResponderPosix -n SlimServer -t _http._tcp -p 9000 0 S slimser 1444 1410 0 76 0 - 406 - Mar16 ? 00:00:00 /usr/local/slimserver/Bin/i386-linux-thread-multi/mDNSResponderPosix -n SlimServer -t _slimhttp._tcp -p 9000 0 S slimser 1445 1410 0 76 0 - 406 - Mar16 ? 00:00:00 /usr/local/slimserver/Bin/i386-linux-thread-multi/mDNSResponderPosix -n SlimServer -t _slimcli._tcp -p 9090 Apparently the clients are currently all quiet (I'm not at home). --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Slim Devices SB2 disappointment SB for sale.
Jason wrote: The overwhelming majority of users do not seem to have the problems you have with the server crashing or grinding to a halt. It sounds like it might be worth your time to try Slimserver on another machine. Perhaps I did overstate the unreliability of the 5.4 code. What I said certainly *does* apply in spades to all of the 6.x versions I've tried recently. None of them were at *all* usable. 5.4.0 does usually stay up for a day or two, and as long as I don't try to add stuff to the database it usually works modulo occasional, long and unexpected pauses in responding to even trivial commands from the remote control or the web interface, and unexplained and sometimes long interruptions while playing back FLAC files over a 100 Mb/s wired connection. Renicing the tasks up a few points usually gets rid of the pauses, but only at the expense of impairing other interactive processes on the same machine whenever slimserver does crunchy things like rescanning the music database. Speaking of which, when I add something to the database, or merely change a FLAC tag, I don't even bother with the rescan button as I know it probably won't work correctly. I just blow away the database and rebuild it from scratch. This is an otherwise solidly reliable 4U rackmount 3.2 GHz Pentium 4 running Linux 2.6.11, with 2 GB of ECC memory and 2.3 TB of EIDE and SATA disk storage organized into RAID-1 and RAID-5 arrays. With that much memory, I don't bother with a swap partition, so VM thrashing is not a problem. The Antec box is loaded with big cooling fans, and internal temperatures are well controlled. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB2 really doesn't support 96kHz PCM on S/PDIF?
Richard Elen wrote: First, with the vast majority of users storing their music in lossy-compressed formats with sample rates seldom exceeding 44.1 kHz and often lower, this may be moot for a lot of people. Agreed. However with the advent of lossless compression format availability in the system, very likely those of us who care about audio quality will jump on them, and if we do so, we might feel that the ability to handle sample rates above 48 kHz would be an advantage. This is not obvious. But as we cannot hear above about 20 kHz, honestly, at the best of times, except perhaps when the level is above about 120 dB SPL at which point we certainly can't tell the pitch, what's the point of higher sample rates? Good question. The traditional reason for proposing higher rates was due to analogue filtering in the conversion process. With an audible band ending at, say, 20kHz, and a Nyquist limit (the highest frequency you can capture with a system, which is half the 'carrier' frequency) at fs/2, eg 22.05kHz, this meant only a small bandwidth to get signals out of the way before they started aliasing and imaging (frequencies above the Nyquist limit are intepreted as frequencies below - see http://www.apogeedigital.com/pdf/apogeeguide.pdf for more details). This meant very steep filters that were initially in the analogue domain. As a result they cause all kinds of problems such as ringing, and phase errors all the way down to below 10kHz. This is why early digital recordings sounded clangy and brittle (we also didn't know about the audibility of jitter then either). While it's true that sharp reconstruction filters were difficult to implement in analog hardware, this problem -- if it ever *was* a problem -- hasn't really been around for almost two decades now. Every modern DAC uses oversampling techniques to implement the high-performance part of the reconstruction filter in DSP, requiring only a simple and cheap analog filter to complete the job. That said, there was *never* any serious evidence that the much-discussed phase shifts of the early analog reconstruction filters were *ever* audible in any controlled listening environments. The effect was comparable to tiny position changes of a tweeter vs a midrange speaker in a cabinet. I certainly heard all those claims about brittle-sounding digital audio, but never did I see one based on solid, scientifically controlled evidence. The solution was to get the filters way out of the way by multiplying the sample rate - multiplying by integers was simplest and produced the fewest artefacts. But you don't really have to work at the higher rate; you can instead 'oversample', where you interpolate imaginary samples between the real ones, the Nyquist limit is way up there and there is tons of room for filtering - which you could also do digitally by now and avoid artefacts by and large anyway. Virtually all converters used today do many times oversampling and as a result this problem has gone away. Exactly. This is sometimes cited by the golden ears as a vindication of their claims -- why would the manufacturers do it if it wasn't necessary -- but the real reason is that it's simply cheaper and easier to oversample and filter in DSP than to do it with lot of expensive analog components. We just happen to be lucky that the cheaper way is also the better way in some sense. Of course, the vendors knew a marketing windfall when they had one, so they made lots of hay over their oversampled DACs. But they never made one whit of audible difference. They just saved the vendors a few pennies per unit in component costs. The other argument for high sample rates is that there may be stuff going on up there even if we can't hear it, and we really ought to capture everything - especially if we are archiving the material and think that inaudible stuff might just be important one day. It's also possible that inaudible frequencies might interfere with each other to produce something audible - for example if you close-mic violins and record each mic on its own track (please don't), not capturing the ultrasonics might adversely affect the timbre when you mix, which would not have been the case if you had used more distant mics and the mixing of ultrasonics had happened in the air between the musicians and the mics. That basically argues that intermodulation distortion is a good thing, the effects of which we should preserve. Seems very strange to me, especially since we already agree that the components involved in the intermodulation are not directly audible. So if we were to eliminate those ultrasonic components by low pass filtering before A/D conversion, the sole effect would be the elimination of intermodulation products in the audio range that wouldn't exist if the intermodulation distortion weren't present. Right. Makes perfect sense. Not. The fact is, however, that the human hearing capability can be satisfied
Re: [slim] Prefered Archiving Format
Robin Bowes wrote: Advice: Make sure you safeguard your collection against HDD failure in one or more ways. For example: - buy an external 400GB HDD and copy your rips onto that - buy another internal 400GB HDD and mirror your first disc. - burn your rips to DVD - stream your rips to high-capacity tape - you get the gist? - Use RAID in addition to external backups. RAID-5 is a good alternative to RAID-1 that lets you get by with less overhead on larger disk arrays. RAID-5 is well suited to relatively static data like a music collection. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Slim Devices SB2 disappointment SB for sale.
Pat Farrell wrote: The problem with open source is that the contributors want to do the cool stuff, especially when it is pretty easy. Redesigning the basic engine is hard, slow, and has zero sizzle Well, most people would say the same thing about an operating system kernel. Yet Linux routinely runs for months without panicking. So 6.* is the first major redesign, and 7.* will likely be a lot more like you'd want. I'm beginning to think whether maybe it's time to think about a complete server rewrite from scratch, probably in C rather than Perl. The menus would be ugly and simple, but the system would actually *work* without being restarted several times per day, without unpredictable 5 second pauses during playback, etc, etc. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless vs. FLAC
Todd Larason wrote: Another option would be to run a server which speaks iTunes' sharing protocol. I haven't paid much attention to this space since doing the initial work figuring out the protocol, so I'm not sure if any of the pre-packaged servers would do quite what you want. The perl module 'Net::DAAP::Server' might be a good place to start looking, or daapd[1]. [1] http://www.deleet.de/projekte/daap/daapd/index.html Thanks for the pointer. I'm trying to figure out, though, why we need yet *another* network file system protocol, this one just to share music. Is there some essential functionality in DAAP that I can't somehow provide over NFS, AFS, SMB or even http? Or is this just Apple up to its old tricks? Maybe I was wrong when I thought that with Mac OS X, Apple had finally seen the wisdom of building on open platforms. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Slim Devices SB2 disappointment SB for sale.
Danny Rego wrote: Ummm...as does Windows XP (although the more geek-sided may refuse to believe that)what's your point? Slimserver is open source, so Linux is the closer analogue. Windows XP is 1) proprietary and 2) owned by Microsoft, so it has its excuses for being so unreliable. Making slim server less user-friendly/ugly would be a very dumb move. Besides, after a bit of tweaking off the bat, slimserver runs reliably, unless you are one that enjoys downloading the latest nightlies...then you're asking for it. Little is less user friendly than a massive package of Perl code that crashes frequently in a mass of cryptic Perl error messages. Or just grinds slowly to a halt for no apparent reason, gobbling all CPU time until it has to be restarted manually. This is on a Linux machine with ECC memory and RAID disks that otherwise runs flawlessly for months. So it's not hardware. v5.4.1 runs beautifully on my Windows XP machine...so on a decent linux machine, I would only imagine how smooth it would run. I see various nightly versions of 5.4.x, but nothing officially labeled 5.4.1. If this is supposed to be the most stable release, recommended for those that want reliability over features, it should be labeled and distributed as such. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB2 really doesn't support 96kHz PCM on S/PDIF?
Patrick Dixon wrote: Phil, are you seriously saying that you can design a 'brick-wall' reconstruction filter at the Nyquist rate (fs/2)? With reasonably modern DSP techniques such as those employed in most modern DACs, yes. It's not *totally* brick-wall because all such filters are impossible, but it is a very good approximation. All it takes to provide an excellent LPF is a FIR filter with enough taps, and this is again readily doable with modern DSP hardware and oversampling so that the final analog filter can be trivial. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Ogg Vorbis Support on SB2?
Christian Pernegger wrote: Sorry if I missed something in this thread, but what's the down side of ogg-pcm on the server? Bandwidth to the SB? Yes. Raw PCM is just below 1400kbit while the ogg stream itself would be much larger. Don't you mean that the ogg stream would be much *smaller* than raw PCM? ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Open firmware for SB2?
Patrick Dixon wrote: IMHO, the two biggest threats to Slim Devices' competitive advantage are: * Product design - most 'normal' people think the Roku styling is better. Maybe. Personally, I think basic functionality and reliability are far more important. Then again, my Squeezeboxes are all black. * Simple software installation - most 'normal' people can't (or can't be bothered) to spend hours reconfiguring their computer to get an application running - if it doesn't work reliably straight from the tin, they'll just send it back and move on. Absolutely! The second produces a major dilemma - the opensource community is notoriously geeky and seems to just love wading though reams of poorly documented or undoccumented source code to re-configure it for some strange combination of a Linux installation. But if the company concentrates on supporting and making the software work seamlessly with Windows and iUnix, it will probably alienate the geeks. I don't think that's really a big dilemma. These sorts of sponsored open source projects work best when the volunteers work on the features that personally interest them, and the commercial sponsor acts as the project glue -- merging patches, conducting regression testing, and managing the release cycle. I can't see how any geek could oppose the mere existence of a stable Windows version (though that's arguably a contradiction in terms) so long as the code he's interested in remains open and hackable. What I *do* find discouraging is the distressing unreliability of even the 5.4 version of the server software. I shouldn't have to install the version du jour just to get a fix for a bug that keeps crashing my server in routine usage. There ought to be two code bases: a relatively stable, no-frills version with an emphasis on robustness, and an experimental version with all the latest gimmicks. As new features prove themselves and become stable, they can be backported to the stable version. This is hardly a novel concept; it's worked very well for Linux. Most of the volunteers would probably prefer to play with the experimental release, while the people at Slim Devices would maintain the stable version. After all, their product is pretty much useless without a server to drive it. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: problems with symbolic linking
Dan Sully wrote: I agree completely Phil - we're focused right now on making 6.0 stable. There was a big jump in functionality, speed and stability in changing out the entire backend between 5.4 and 6.0. However, as you well know, bugs are introduced along the way. I think this is exactly where the problem is. I shouldn't be forced to choose between an old version with lots of bugs, and a new, bleeding-edge version that fixes (most of) the older bugs, but also introduces many new bugs associated with lots of new features that are largely useless to me. There really should be two, separately maintained code bases: a stable version where stability and robustness are paramount, and an experimental version with the latest new features that may not be particularly stable. This *doesn't* mean that you never update the stable version. You update it as often as you have to to fix a bug or security hole. Even daily, if you have to. But new features, even seemingly simple ones, are *prohibited*. Those go only into the experimental tree. I think the Debian Linux project does it exactly right. Debian has three flavors: stable, which is regularly updated *only* with security fixes; unstable, with all the latest, bleeding edge features; and testing, which is something like stable, but periodically updated with features that have proven themselves for a while in the unstable version. Once in a while, you rev the stable version, including only those new features that have already withstood the test of time. It works pretty well for me. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless vs. FLAC
Todd Larason wrote: Can you point me to documentation for the Vorbis metadata? I've scanned vorbis.com and xiph.org, and I'm just not finding it. Start here: http://www.xiph.org/ogg/vorbis/doc/v-comment.html I decided on Vorbis for my meta data partly because I have a large collection of classical CDs, and whoever defined the MP3 ID tags obviously just wasn't thinking about classical music. The Vorbis comment conventions aren't complete, but they're a big improvement over MP3 tags, and more importantly they're free-format and extensible. E.g., when ripping piano and violin concertos I easily added SOLOIST tags even though no software currently pays attention to them. I figure they're not that important right now, and support for it can always be added later. The other convention I strongly recommend when tagging classical music is to make sure each TITLE tag is self contained. If a work spans several tracks, I'll include the name of the work in each TITLE comment. For example, if a CD contains Beethoven's 9th symphony in 4 tracks, then I'll use TITLE tags that look like this: TITLE=Symphony 9 - I. Allegro ma non troppo un poco maestoso TITLE=Symphony 9 - II.Scherzo, Molto vivace TITLE=Symphony 9 - III. Adagio molto e cantabile TITLE=Symphony 9 - IV. Presto, Allegro assai This is important because many classical CDs contain several unrelated symphonies or concertos, sometimes by multiple composers. You can't use the ALBUM comment for this purpose, because it really ought to be the same for every track on the same CD, even if it contains more than one work. iTunes has a GROUP tag that seems to be designed for this exact purpose, but it's not in the Vorbis comment conventions, no software supports it, and it's important enough that I wanted something that would be displayed by existing software like the Slimserver. Because there's already a Vorbis COMPOSER comment, there's no need to include the composer's name in the title tags. I use it to contain the composer's complete name, e.g., Ludwig van Beethoven. The ARTIST tag contains just the composer's last name, which I also use to name the actual directories. (I make exceptions for names like Bach and Strauss, where there's more than one composer with the same surname.) The name of the orchestra goes into the PERFORMER tag, the conductor into the CONDUCTOR tag, and so on. The existing Slimserver software seems to deal reasonably well with all this except for my nonstandard SOLOIST tags, which aren't all that urgent anyway. The iTunes practice isn't that simple. For mp3 files, for most things, the definitive metadata is stored in ID3 tags in the file; the information is cached in a binary file and reflected in an exported XML file. The definitive volume adjustment, equalizer, star rating, and start and stop time information is stored in the binrary file and relfected in the exported XML file. The part of a compilation field is confusing: as nearly as I can make out, it is initialized from the nonstandard TCMP ID3 tag, and when changed through iTunes the TCMP tag is updated; unlike all the other ID3 tags, though, changes made outside iTunes post-import are never reflected inside iTunes. Thanks for this description! I've looked at the XML files on occasion, and I've wondered which files iTunes reads and which it writes. I have noticed that I can delete the binary database file and force iTunes to rebuild it from the XML file. You can also blow away the database entirely and re-import it from an imported XML file. I've done this a few times after making manual edits to the XML file for various reasons. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless vs. FLAC
Todd Larason wrote: The iTunes practice isn't that simple. Speaking of the iTunes database structure, do you happen to know of any utilities that can scan a music folder and build the iTunes XML structure from the tags in the music files (other than iTunes itself, that is)? The reason I ask is that I have an Ogg Vorbis plug-in for iTunes that plays just fine, but it doesn't read the Vorbis tags into the database when I add an Ogg Vorbis file to the library. I'm also thinking of writing a NFS shim that would make my FLAC archive appear to iTunes as if it was full of WAV files, and WAV files don't have any metadata at all for iTunes to import. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless vs. FLAC
Michael Peters wrote: There are issues in other areas - for example, some CD's will have more than one artist - U2 for example, the album Rattle and Hum. In that case I'd just use a different ARTIST tag for each track, just as for a compilation album like Greatest Hits of the '70s. Unlike the ALBUM tag, which really ought to be the same for every track on the same physical CD, there's no reason that the ARTIST tags all have to be the same. If a particular track is a joint effort of several artists, then just list them all in the ARTIST tag for that track. Both iTunes and the Slimdevices databases do a pretty good job of indexing all this stuff so you can find what you want, and that's what really matters. That leaves just the question of how to name the directory that contains the album directory; iTunes' use of Compilations is as good as any. The Vorbis COMPOSER and PERFORMER tags give you even more indexing flexibility, if you need it. I don't usually bother to set the COMPOSER tags on popular music, but some songs are *so* widely covered that it makes sense to do so. E.g., I must have a dozen different versions of Dave Mason's song Feelin' Alright by a half dozen different performers: Dave Mason, Grand Funk Railroad, Joe Cocker, Three Dog Night, Traffic, etc. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Open firmware for SB2?
Patrick Dixon wrote: it's worked very well for Linux. Really? As someone struggling to get FC3 configured, googling for information produces many more people with Linux problems than there are solutions out there. I was talking about Linux, which is just an OS kernel. There has traditionally been a production branch and a development branch, with features from the development branch integrated back into the production branch after they've been adequately tested. As a result, the production branch has been remarkably stable. All of my Linux boxes routinely run for months at a time without crashing; when they do, it's almost always because of a hardware failure like a crashed disk or a power failure. BTW, I use Debian, not Red Hat. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: shorten
kdf wrote: to make things worse, systems like windows dont like /dev/null so the server spits out a warning for every shorten file it finds and never adds them to the db properly. I have only about 10 shorten files. Only 2 are playable with slimserver. I have tried to find alternative ways of getting the info, but I give up after losing too many evenings. tips would be useful. Well, transcoding to FLAC as Michael Peters does would seem to be the right answer. I've already decided to do that with the shorten files I get from etree trading. The only problem with this is if I want to continue to help make these files available via Bit Torrent, then I have to keep both formats around, and that's extra disk space. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Slim Devices SB2 disappointment SB for sale.
momerath wrote: having odd problems connecting after power off, and, of course, pcm streaming skips sometimes, even in situations I would have thought would certainly work. I think the PCM skipping (buffer underflow) problem could be substantially improved if a little attention were paid to thread priority and CPU scheduling in the server. That's something Slim Devices could do to help keep the faith of those of us with original Squeezeboxes. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Suggestions for 802.11g Wireless Router?
Chris Glushko wrote: I would suggest staying away from Netgear. I just replaced my WR614 today. Even with the latest firmware, my netgear router was never very stable and under intense use (i.e. a few hours of Bittorrent w/ Azureus) the netgear would essentially freeze, needed to power cut off manually to unfreeze it. I agree. Netgear's plain vanilla Ethernet hubs and switches have always worked great for me (I also like their simple metal cases) but their WR614 wireless access point was always a problem. It had poor coverage, and even at close range we had unacceptably high packet loss rates to our Power books. Firmware upgrades and appeals to customer support didn't help. So it's been sitting unused in a box ever since we got our first Linksys WRT54G. I really wish Consumer Reports could evaluate stuff like this. They could save a lot of people a lot of time and money. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless vs. FLAC
Phillip Kerman wrote: I have a proof of concept thing I built in Flash that parses iTunes's XML. What do you need to extract exactly? I'm pretty sure it'd be easy to adapt this thing I have to output a string (in any form you want) to your clipboard so that you can paste it into another tool or text file. Or, do you just want to view the data with something other than iTunes? No, I want to build the iTunes database by extracting FLAC and Ogg Vorbis tags (they're the same format). iTunes itself does this automatically when importing MP3 and AAC files, but when I import Ogg Vorbis songs with the iTunes Ogg Vorbis plugin installed, the Vorbis comments are ignored. I have to enter them by hand. There's a Sourceforge project that's supposed to be working on a FLAC plug-in for Quicktime/iTunes, but it doesn't seem to work. So while I'm waiting, I thought I'd build a simple shim for NFS that would make my library of FLAC files on Linux look like a network filesystem full of WAV files to my desktop Mac. I can then import them into iTunes and play them from the server onto my Mac. However, there wouldn't and couldn't be any meta information in iTunes' database, because WAV files don't have meta tags. That means I'd have to add the meta info manually to the iTunes database, or preferably use a tool to extract the tags from the FLAC files and build an XML file that I could then import into iTunes. I actually like iTunes. Although it doesn't have native support for my preferred formats, it has one of the best user interfaces of any music jukebox program around. And it's pretty stable. So when I want to listen to music while I'm at my computer, I'd much rather use iTunes than SoftSqueeze. I'd prefer to limit my use of SlimServer to just my Squeezeboxes, at least until it becomes a lot more stable. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Suggestions for 802.11g Wireless Router?
Michael Peters wrote: Just for the record - I have the same issue with my Linksys wrt54g router. I should point out that I use only the wireless base station and 4-port Ethernet switch features on our WRT54Gs. I don't use the built-in DHCP or NAT/routing functions at all; that's all handled by a Soekris Engineering box running Linux. So I wouldn't have encountered any bugs in the WRT54G's routing or DHCP functions. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Virgin Radio Ogg Vorbis streaming problems
Has anyone tried to listen to Virgin Radio (London) on their Ogg Vorbis streams? The streams are: http://ogg.smgradio.com/vr160.ogg http://ogg.smgradio.com/vc160.ogg http://ogg.smgradio.com/gr160.ogg Their equivalent MP3 streams work fine, but their Ogg streams close at the end of each song. At first I thought they were kicking people off intentionally, but a little packet tracing showed that slimserver, not Virgin's server, is closing the TCP connection. I also see this message in slimserver.log each time it happens: Only one logical bit stream currently supported This message, plus the fact that the problem always occurs during the segue between songs, suggested to me that Virgin sends separate streams for each song, they overlap during the transition, and this overlap apparently isn't supported by oggdec. Does anyone know of an Ogg Vorbis stream decoder that does work in this application? I wonder if *anyone* is listening to Virgin's Ogg streams. It's a shame, since the audio quality is noticeably better than their 128k MP3 stream. I'll probably dig into this problem myself, but I wanted to see if anyone else has solved it first. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Bombout in 6.0b1
I brought up 6.0b1 tonight, and while it was rebuilding the database it abruptly exited with these messages: Use of uninitialized value in multiplication (*) at /usr/local/slimserver/Slim/Player/SqueezeboxG.pm line 65. Can't use an undefined value as an ARRAY reference at /usr/local/slimserver/Slim/Player/Squeezebox2.pm line 209. Is the server supposed to just exit when it encounters an error like this instead of trying to continue? --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] problems with symbolic linking
kdf wrote: that's a font crash. are you trying to run slimserver 5.4 with a softsqueeze session that is still running from 6.0? SB2 (and softsqueeze 2.0a11) use different fonts, so they will cause earlier servers to barf. It may also be that you ran with 6.0 and it had the same MAC addy, so the player prefs have been updated with SB2 stuff. You may have some better luck if you play with the softsqueeze settings to have different mac addresses. I just figured that out for myself a few seconds ago. When I killed the copy of softsqueeze I had been running, slimserver 5.4 came back up. You know, I hate to say this but it's really been bothering me for some time and I think I need to say it. The Squeezebox is a *really* nice piece of hardware. When it works, it's wonderful. The design philosophy of having the box do just the essential functions and do them well while moving all the smarts to a much more capable and open server is exactly the right approach. But this also means that without its server, the Squeezebox is a totally useless lump of plastic. So that server has *got* to be reliable. Since I got my first Squeezebox, I've been more than a little surprised at the overall brittleness of the server software, at least on Linux (I haven't tried any of the other OS versions). It seems to abruptly exit at the slightest provocation, such as this little mixup on fonts. Various cryptic Perl error messages appear from time to time in the log; whether they're cause for concern, I haven't a clue. Seemingly simple web operations, like walking down a directory tree, often take undue amounts of time. Sometimes I'll see it gobbling all available CPU time for no apparent reason; aborting and restarting seems to make it behave again for a while. Clicking rescan after adding music rarely seems to work right; I almost always have to blow away the cache and restart. And so on. That's with the 5.4 version. The 6.0 versions have been even worse; I haven't gotten one to play yet without crashing within the first minute or two with another flurry of cryptic Perl error messages. This is not quite what I expected from a consumer product seeking a mass market. It is just not reasonable to expect every user of a device like this to be a skilled Perl hacker, able to know that a cryptic message like Can't use an undefined value as an ARRAY reference at /usr/local/slimserver_5.4/Slim/Player/SqueezeboxG.pm line 123. followed by an abrupt server crash means that you're running an incompatible version of the client somewhere on your network. Not only should the error message be a little more informative, but the user just might be forgiven for foolishly expecting that software written as a multi-user network server should be just a little more robust against unexpected input in general. I don't know why it should be so difficult to make a simple and robust server for this thing. Perhaps the other users consider a rich selection of 17 web skins and the various plugins and news ticker crawls more important than basic functionality and robustness; I don't know. But I do know that, as nice as the Squeezebox is, I just can't recommend it yet to my less technical friends until it comes with a *far* more robust and foolproof server. When it does, I'll recommend it wholeheartedly. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] 60b1 buggy?!
[EMAIL PROTECTED] wrote: Tried the new version 60b1 yesterday, but immediately downgraded to 5.4.1 Where's 5.4.1? I don't see it in http://www.slimdevices.com/downloads. I only see 5.4.0 and the v6 betas. If there's a stable, no-frills version of the server software, I would very much like to use it. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB2 and FLAC
Phillip Kerman wrote: For my ears, my SB plays FLACs back to back perfectly. I've yet to find an instance where it doesn't... and there are many cases where you'd definitely hear a pause if one were inserted. Right, thanks for confirming my observation. As an aside, I have noticed that, unlike flac, shorten (.shn) files play through the Squeezebox with a tick between tracks. This seems to be because the shorten command used for decompression has no option to produce a raw, headerless stream. The tick sound is the sound of the reconstructed .wav header being fed to the DAC. Shorten still seems to be popular on bt.etree.org and other sites where audience recordings of taper-friendly bands are traded. I can't figure out why, as flac seems to be superior to shorten in every way. FLAC files are about 5% smaller, and they support metatags. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Open firmware for SB2?
Sean Adams wrote: That was SLIMP3 firmware, which was all code I wrote myself, so we could release it however we wanted. Squeezebox and Squeezebox2 include 3rd party proprietary OS and wireless drivers and require a $30,000 development kit in order to write code for them. These are just a few of the obstacles to opening up firmware development. Well, I suppose an alternative would be to open up all the necessary hardware specs (if they're not already open) and encourage an independent open source firmware development from scratch. If or when it surpasses the stock firmware in features and stability, you could switch to it. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] MP3 quality on repeat copies
Patrick Dowling wrote: On average what level of compression are you seeing? I know there are many factors, but for space planning I'm looking for a general estimate. A very rough rule-of-thumb is about 50% (2:1). You get better than that on quiet classical music, and worse on loud, volume-compressed rock. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] MP3 quality on repeat copies
Here's another data point for comparison. I recently bought the Magnatune label album Nocturne by The West Exit and was given my choice of file format to download. Here are the sizes: # 44k/16bit WAV: 507meg zip of perfect quality WAVs. # FLAC: 357meg zip file of perfect quality FLAC files. # OGG: 65meg zip file of high quality Ogg Vorbis files. # 128kb MP3: 47meg zip file of 128kb MP3 files. # MP3 VBR: 84meg zip of high quality MP3 VBR files. # Mac iTunes: 58meg iTunes OSX AAC files. # Mac MP3: 96meg OSX OS9 compatible 256k MP3s. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Suddenly can't start SlimServer on Linux
Jack Coates wrote: Either slimserver is already running, or something else is using its network port. As root, ps aux | grep slimserver. That won't show if another process is listening to that port. If you have the lsof (list open files) command, that's a better way to get the information you need. E.g., if I do sudo lsof | grep TCP on the Linux machine that runs my slimserver, I'll get (heavily edited): slimserve 32635 slimserver8u IPv45470505 TCP *:3483 (LISTEN) slimserve 32635 slimserver9u IPv45470506 TCP *:9000 (LISTEN) slimserve 32635 slimserver 10u IPv45470507 TCP *:9090 (LISTEN) slimserve 32635 slimserver 11u IPv45709439 TCP homer.local.ka9q.net:3483-192.168.1.31:35348 (ESTABLISHED) slimserve 32635 slimserver 12u IPv45709440 TCP homer.local.ka9q.net:3483-otto.local.ka9q.net:33030 (ESTABLISHED) slimserve 32635 slimserver 13u IPv45520472 TCP homer.local.ka9q.net:9000-milhouse.wi.local.ka9q.net:51407 (ESTABLISHED) slimserve 32635 slimserver 32u IPv45718345 TCP homer.local.ka9q.net:9000-otto.local.ka9q.net:33036 (ESTABLISHED) This shows that process ID 32635, named slimserve(r), is listening on TCP ports 3483, 9000 and 9090. Chances are you'll find some old slimserver process still bound to one of the needed ports, and that's keeping you from starting a new one. Kill the old ones and try again. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Apple Lossless vs. FLAC
Chris Glushko wrote: If you are an iPod user and you like using iTunes to manage your music, wouldn't Apple Lossless be the most logical choice for your primary archive? Well, it might be -- if you're willing to spend all that precious iPod disk space on a lossless format. If you insist on lossless even on your iPod, then Apple Lossless is your only choice. I understand the preference to Open Source, but aren't you just adding extra work for yourself for nothing more than to spite apple if you are an iTunes/iPod user? Well, for one thing I didn't buy an iPod. Even though I have several Macs and do use iTunes, I bought an iRiver 340 specifically to get Ogg support. If Apple were to support Ogg Vorbis on the iPod, I'd buy one in a heartbeat. That said, the numbers I've seen tend to indicate that FLAC achieves somewhat better compression ratios than Apple Lossless. Also, FLAC supports Vorbis-style metatags, which I consider vastly superior to either MP3 ID tags or the iTunes practice of keeping all the meta information in a separate massive XML file. I invest a lot of time getting the metainfo right, especially on classical music, so the right tag format matters. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Out of curiosity
Joshua Uziel wrote: Oh, I'm well-aware of SCO and a whole bunch of other open source related cases over the years. :) Sure, this is a conceivable outcome. To be honest, while I'd prefer to be able to play with the firmware for the SB2 and add stuff like native ogg support, the fact that it requires a totally expensive toolchain suite ($25k was it?) kinda shoots it in the head. I'm happy enough with the source for the server anyways. This is about as good an argument as you can make for putting as much as you can in the server and keeping the client (the Squeezebox) as simple and generic as possible. The Squeezebox should focus on a very basic set of hardware functions and doing them as well as possible. Everything else -- all the bells and whistles -- belong on the server where you have essentially unlimited CPU and memory and a powerful, open development environment to do whatever your heart desires. I presume Slim Devices chose its name because they felt much the same way. IMHO, I can think of only two really valid reasons to justify additional functionality in a device like the Squeezebox. The first would be features that make it easier for the server to meet its real-time constraints to prevent buffer exhaustion. The SB1 has a rather small buffer that empties in less than one second at PCM rates, and this can be difficult to meet on a general purpose server that's also doing other things. The SB2 has essentially solved this problem with a much bigger buffer. If you can't get your server to refill the SB2's buffer often enough, you've got bigger problems to solve. The other class of enhancements would alleviate the Squeezebox's bandwidth requirements on wireless channels. (PCM is already a trivial load on a 100 Mb/s wired connection. If you still have 10 Mb/s hubs, upgrade!) The built-in MP3 decoder in the original Squeezebox certainly helps with this, as does the addition of 802.11g and built-in FLAC decoding in the SB2 for the purists who insist on a totally lossless audio path under all conditions. With these new features to the SB2, I really can't think of anything else that I *really* can't live without. I think Slim Devices has done an excellent job with both the SB and SB2, and wouldn't want to see it sunk with creature feep as has happened to so many other products of its type. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Gapless playback with mp3 - another shot
Can somebody give me some background on gapless playback? I don't understand why it's a big problem. With FLAC, at least, I don't seem to have any problem at all playing tracks that flow together seamlessly. Occasionally I'll get a FLAC file that was created with an erroneously embedded WAV header that results in a tick at the beginning of each new track, but there is no actual interruption. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] SB2 and FLAC
Steinar Bjaerum wrote: I have started to rip my record collection to FLAC. I am using one FLAC file per album, internal cuesheets with tag information included as numbered Vorbis Comments. This works great with SB1 and server-side decoding. I'm curious as to why you did this. I've also ripped my own collection to FLAC, but with one track per file. Before I did this, I ran a test using everybody's favorite continuous album, Pink Floyd's Dark Side of the Moon. I ripped it as a single WAV file, and then again as individual tracks. I found that the concatenation of the individual track files was exactly bit-for-bit identical to the single WAV file. This told me that I could rip everything as single tracks and have them play correctly as long as the player doesn't insert any pauses. This seems to be the case for the Squeezebox/Slimserver. What support is there in Slimserver/Squeezebox for cue points within a single large FLAC file? How do you easily play just one track on an album? Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Open firmware for SB2?
Jason wrote: The obvious risk to slim devices if they do this is that some other company can produce a super budget version of the SB, load the SB firmware onto it and completely undercut Slim Devices potentially putting them out of business. Quite frankly, I just don't see all that much value in the existing SB firmware that couldn't be easily duplicated from scratch by someone else building a similar product. After all, it *is* a slim device, meaning that the box does very little on its own; nearly all the heavy lifting is done back at the server, and that's already open source. So open-sourcing the Squeezebox firmware would result in Slimdevices picking up a lot of new features from its users for free, and since they already make a very good hardware box at a reasonable price I don't think they have much to worry about from being knocked off. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Squeezebox 2, could it be an access point also?
Andrew Lucas wrote: Hi, Just curious, seeing you can get to the Squeeze 2's wireless interface via the ethernet connector, would it be also possible to use this this a basic wireless access point. The SB2 as described is a wireless bridge, not an access point. A wireless bridge is a *client* of an access point, and that's a very different (and much simpler) set of functions than being an access point. Besides, with excellent access points like the Linksys WRT54G now down to the $60-70 level, there's simply very little point in adding access point capability to the SB2. I'd rather keep the box cheap, simple, and focused on doing one thing (playing music) very well. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Squeezebox2 wireless interference question
Christian Pernegger wrote: Question: Are there any disadvantages in having the radio and one antenna internal? I'm thinking interference, added noise in the analog stages ... Probably very little, if any. Spurious noise from computing equipment is generally strongest at the lowest frequencies, and it falls off fairly rapidly in intensity the higher you go. That's why you tend to have so much more trouble with AM radio interference (~1 MHz) than FM (~100 MHz). 802.11 operates on the 2400 MHz band, which is high enough for most computing equipment to generate relatively little noise. Even high-end CPUs like Pentium 4s and Athlons with clock speeds in the multi-GHz region confine signals at those frequencies to inside the chip; the external interfaces to memory and peripherals that can radiate interference run at slower speeds, e.g., 800 MHz or 1 GHz. Harmonics can certainly exist at higher frequencies, but they probably won't be all that strong. The biggest source of radio frequency noise from Squeezeboxes has been the little power supplies that they bundle with them. Slimdevices ought to return them for a refund and use a cleaner model. Quite a few people are now complaining that they can't listen to an AM radio anywhere in a house that has a Squeezebox. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] (a bit OT) firewall in the router (was Squeezebox2)
Ken Hokugo wrote: Dean or anyone, Would the firewall feature in these routers (wireless or wired) be good enough so that I can get rid of Zonealarm Pro which contributes 10 to 15% more of CPU usage when playing Slimserver? If I could get rid of the sw based firewall, that would be great. A particularly powerful and flexible firewall is a Linux box with multiple Ethernet interfaces. If you'd rather not dedicate a full-blown PC to the job, Soekris Engineering (www.soekris.com) makes a line of single-board PC-compatible machines specifically designed as network engines. They come without any software, so you have to roll your own, but there are many people who can help you. I have a Soekris net4801 acting as my primary router. It provides QoS (Quality of Service) in the upstream direction to my DSL line, along with DHCP, IPv6 routing/tunneling and IPv4 NAT for any local machines that need it. Except for the filtering inherent in a NAT, it doesn't actually filter any packets because I basically don't believe in firewalls; I'd much rather just keep my individual machines as secure as possible. Basically, that means banning anything and everything from Microsoft; we're in the process of getting rid of the very last Windows machine on our network (my wife's desktop) and replacing it with an iMac. The combination of Mac OS X on the desktop and Linux on servers can do pretty much everything Windows can do, and do it a whole lot better and with far better security. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Squeezebox2
Christian Pernegger wrote: I'd been holding out for a public domain linux apple lossless decompression solution that would run compfortably on a squeezebox, but this might push me to dual libraries (one flac, one aac for ipod)... There is a preliminary FOSS decoder for ALE out: http://craz.net/programs/itunes/alac.html You could have SlimServer transcode ALE -- FLAC without loss of quality. That said, I'd much rather people didn't use closed formats. Agreed! I don't see much reason to ever use ALE, though it's certainly nice to now have the ability to decode it if necessary. Lossless formats are still too bulky for portable players, so even though an iPod supports it, it doesn't seem very practical. That leaves AAC and MP3, since the iPod supports them but not Ogg Vorbis. Since AAC seems to give better quality than MP3 for the same data rate, then it makes the most sense to keep your primary archive in FLAC and convert to AAC for the iPod as necessary. Both AAC and MP3 are patent encumbered, so you're forced to choose between two evils. But if you're lucky enough to have some other portable player that supports Ogg Vorbis, then you can produce Ogg Vorbis versions from your FLAC masters and not deal with proprietary formats at all. That's the route I've chosen by buying an iRiver 340. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Squeezebox install creates IP address conflict -- resolved!
Roy Owen wrote: Don't be suprised if the problem re-occurs. It's been my experience that problems that fix themselves will bite you in the backside at the most inconvient time. Yeah. That's why you should take the time to assign permanent addresses to each one of your devices, and use dynamic addressing only for guests. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Squeezebox causing RFI on AM
Maurice Poirier wrote: Since I installed my Squeezebox, there is constant static interference on AM radio reception. Is it the ethernet cable that is causing this -- or the Squeezebox itself?? The AM tuner is on same receiver that the Squeezebox is connected to, and the Squeezebox is located on a shelf ca. 16 inches below the receiver. (The Squeezebox itself is working fine). I temporarily disconnected the ethernet cable (cat 5E) from the Squeezebox, but the interference remains. Any advice on how to resolve this problem would be much appreciated. It's almost certainly the switching power supply that came with the Squeezebox. My boss (who initially turned me onto the Squeezebox) had exactly the same problem, and he eventually found a different model of power supply that greatly improved the situation. You might also try adding an inline RFI filter to the standard power supply. I don't know how some of these power supplies ever get FCC certification. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] MP3 quality on repeat copies
Others have already pointed out that MP3 files are like any other kind of computer file; as long as no errors occur during copying, the copies will be exactly identical to the original. Only if you decompress and recompress will there be any further degradation. Having said that, let me make a plug for FLAC (Free Lossless Audio Compression). Not only does FLAC not lose *any* quality from the original PCM WAV format (the format on standard audio CDs) but the FLAC header also includes a built-in MD5 hash of the uncompressed audio. This lets you verify a FLAC file to ensure that it's not corrupted. (You use the command flac --test file.flac). I don't know of any other commonly used audio format with this *very* nice feature. FLAC uses much more space than the lossy formats like MP3, Ogg Vorbis and AAC, but modern disks are *so* roomy and cheap that this just isn't a big deal anymore for a desktop machine. I chose FLAC as my primary format on my Slimserver, and I can still produce lossy compressed versions from the FLAC masters as needed for various portable players. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] new open source decoder for Apple Lossless
http://craz.net/programs/itunes/alac.html ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Modifying squeezebox clock
momerath wrote: Phil is absolutely correct that the burden of proof is on the audiophile, and that a double blind study is the only practical way to prove the audibility of jitter. I intend to do this in the near future with some skeptical friends. By all means, if you can run a controlled test, then do it! I'm not sure how to best go about that. I know of some audio ABX testing software, but I think it's designed mainly to evaluate lossy codecs. You're testing something at a much lower layer. It might be possible to simulate the effect of jitter in software by using similar algorithms to those that convert between sampling rates, although here the rates would be very nearly identical. This might not satisfy everyone, though, as it wouldn't actually test the real hardware, so an actual hardware switch would probably be the best as well as the simplest. The most crucial thing in any audio A/B test is level matching. Otherwise, the louder signal will almost always sound better. This shouldn't be hard to do in an all-digital system; just make sure identical bit streams come out both cables. Also, make sure that all switching transients and propagation delays are the same; if you do a test that involves A vs A and A vs B, you don't want the lack of a switching transient or change in delay in the first case to give it away. Keep in mind that a positive result will be less conclusive than a negative result, at least with that particular subject. A positive result could be due to some artifact other than the property you're trying to test (e.g., different audio levels, different time delays, etc) and you've got to carefully exclude every possible artifact other than the one property (jitter) you're trying to test. There's a classic example given in a MIT science textbook about just how incredibly hard it can be to design a proper experiment on human perception. It asked the question Can humans detect magnetic fields? The answers kept coming up Yes, but closer examinations kept finding various bugs in the experiment that explained the positive results (e.g., the test subjects could hear the buzzing of the electromagnets, or saw the slight dimming of the lights as the switch was thrown, etc.) Eventually, after going to very great lengths to eliminate all artifacts, they got their answer: No, humans cannot detect magnetic fields, at least not at the intensities tested. Let me know what happens! --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Proposal: more lists
Robin Bowes wrote: I'd like to propose that additional mailing lists are created to split up the traffic more, particularly on the general list. I'd also like to see the names of the lists change as indicated below. In general, I think this is a bad idea. Topics have a way of crossing finely-drawn boundaries like these, and besides most of us now have good mail-reading software that can easily organize mail by topic and thread. This makes it easy to follow the threads and topics you want while ignoring the ones you don't want. My observation is that when a list splits, one usually ends up bearing all the traffic while the others go unused. Even worse, people start cross-posting to all the lists. So nothing is really accomplished. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] New Squeezebox?
Christopher Jacob wrote: and a hard drive and a keyboard and a mouse Then build yourself a mini-ATX PC, or buy a Mac mini and run Softsqueeze. The whole point of a Squeezebox is to have a small, light, low-power, and **fanless** box that just plays music and plays it well. I think the current design is just fine, though it took me a while to get used to the complete lack of local controls on the box. I soon realized I'd probably never use them anyway. Heck I hardly even use the IR remote, as a web browser on a wireless laptop is usually much faster. The key to a successful product like this is keeping it simple! ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Magnatunes vs. slimserver
Chip Hart wrote: ...after hearing a few references to Magnatunes here, I decided to check it out. Cool idea, surprisingly good music. I was about to work on parsing their WWW pages to extra playlists when I realized _they'd already done the hard work_ and supply xml/csv lists of all their music. Wow. Yup, Magnatune is run by one remarkably enlightened dude, John Buckman. As far as I can tell, it's a one-man operation. He participates in the Magnatune forums quite regularly, if you're interested. Parsing these lists and creating groups of related playlists is fairly easy (I just did it for a much grosser radio1234 file), but I figured I'd see if anyone else has already tried this. So - anyone played with Magnatunes and automatic playlist generation? I just grabbed his .m3u playlists, massaged them a bit with Perl and stuffed them into my playlist directory. I also grabbed his Shoutcast streams; he currently has 6 of them for different genres. I actually find myself listening mostly to these streams, and then going on his site when I hear something I like. His ultimate goal *is* to get you to buy an occasional album, to help cover his streaming costs. One thing that seems to be missing from m3u and pls formats is the ability to have comments or information about the tracks. Sure, I can crank out 100s of playlists, even sort them by genre, but that's not as handy is understanding that Phebe Craig and Katherine Westine feature harpsichord duets and not the Ukranian Children's Choir. Try fitting that on the slim display...I just wonder if anyone has come up with a smart(er) way to do this. I don't think so. I did notice that his playlist entries are URLs with file names that just give the track #, artist and song, no album, year or comment. But if you suck them into iTunes and quickly click on each one, iTunes will grab the MP3 tags from the stream and display them in the library window. I haven't run Slimserver on the machine with iTunes, so I don't know if Slimserver can pick this data out of the iTunes database and display it on the Squeezebox. But even if it doesn't, the Slimserver ought to extract and display the MP3 tags when you actually play the track. Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Magnatunes vs. slimserver
Chip Hart wrote: Oh, unless I am misunderstanding you, check this out: http://magnatune.com/info/api Look at the XML and csv files - tons of data. I've got it parsed and all, what I really struggle with is a cool way to I guess I wasn't aware of all that stuff. Cool! Now to see if I can do anything with it myself... ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Modifying squeezebox clock
Robin Bowes wrote: What information on that image tells you that? It seems to me you're not understanding what you're seeing. The legend says the time trace is 5 ns/div. A pair of measuring lines implies that the jitter on the uncorrected is somewhat less than that, about 3 ns. As I recall (I can't find good, recent references), each subframe in S/P-DIF carries a (usually) 16-bit PCM sample in a 32-bit subframe, so the clock rate of the composite stereo signal would be 64 times the 44.1 KHz CD sampling rate, or 2.8224 MHz. At this rate, a bit time is 354.31 ns, so the 5 ns jitter is a tiny fraction of the bit time. That's why you only see one bit transition on the scope -- because its horizontal sweep rate has been blown way up to make the small jitter visible. Even if that jitter were directly imposed on the local VCO, which it is not because of loop filtering, it would still be reduced by a factor of 64 as the VCO clock is divided by 64 to produce the DAC sample clock. 5ns of jitter would become 78 ps. Even tinier when you consider that a cycle of 20 KHz (the highest frequency the CD can reproduce) takes 50 *microseconds* to complete. What fraction of an audio cycle is that? What's the FM modulation index? What is the resulting spectrum of sidebands around the 20 KHz signal? What about lower frequency audio? I'll leave the precise numbers to the reader, but it should already be obvious that they're already tiny for the 20 KHz signal, and even smaller at the lower frequencies. Not only that, but it's showing us the raw signal jitter, before the bit clock has been reconstructed by the receiver's PLL and divided down to the sample rate, which decreases the jitter accordingly. And furthermore, there's no indication of the exposure time, so we don't know anything about the frequency spectrum of the jitter. That's important too. It's the same for both cases. Level playing field, anybody? Except that, in both cases, it's just too small to matter! But you don't believe in all this audiophile mumbo jumbo about good cables and bad cables, do you? Don't put words in my mouth. You don't need cables that can pass 2 MHz if you're carrying baseband analog. If you're carrying S/P-DIF, which has its spectral peak at 2.8 MHz, then you do. It would be hard to find a coaxial cable that couldn't do an adequate job of passing the spectral components of a 2.8 MHz S/P-DIF signal over a few feet in a home stereo system. We regularly use even smaller coaxes to carry far higher frequencies from cell phones to external antennas. I *can* see how there might be a problem with ordinary shielded, twisted-pair microphone cables such as the kind long used in professional work to run 600 ohm analog signals over significant distances. Here you'd probably want a redesigned cable better suited for megabit digital signals. Something like Cat-5, for example, which is really cheap and goes up to 100 MHz. It doesn't have to be expensive or gold plated to be good. You're general POV seems to be that if *you* can't hear a difference then no-one else should either. Not at all! For one thing, I'm 48 and my hearing is not what it was at 18. But if I can't hear a difference, and some calculations cast strong doubt on *anyone* hearing the difference, then I think it reasonable to ask those who claim to hear a difference if they have conducted any proper blinded listening tests. If not, then I question their assertion. Audiophiles have a very long history of hearing all sorts of amazing differences that seem to disappear as soon as proper controls are introduced. That's a fact, and it would be foolish to ignore it here. Have you ever heard the effect of phase modulation on an audio signal? Sure I have. Remember I said I help design modems for a living. Phase modulation (e.g., PSK) is one of the modem designer's standard methods. I'm well aware of what large amounts of phase modulation sound like; I've spent many hours listening to these things while developing and using modems on satellite links. But that doesn't mean very tiny amounts of phase modulation sound at all alike. The sort of improvements audio enthusiasts wax lyrical about can often be attributed to phase. Soundstage, depth, clarity, all that sort of stuff. Even a small phase error can radically smear the sound. Yeah, but can you do it in a properly controlled test? How do you know you're not just fooling yourself? I don't hear discrete sounds or tones, no, but I do hear relationships between sounds and positional information that is encoded in the HF band. If you lose that you lose clarity and detail in the sound. Again, so you say. People can claim to hear anything. Prove it with a properly controlled test. That's all I ask. And what happens if the crystal is inaccurate? If it's in a wall clock, the clock runs a little fast or slow. If it's a local oscillator in a radio receiver, then its dial frequency calibration is a
Re: [slim] Modifying squeezebox clock
Phil Karn wrote: Even if that jitter were directly imposed on the local VCO, which it is not because of loop filtering, it would still be reduced by a factor of 64 as the VCO clock is divided by 64 to produce the DAC sample clock. I'm going to have to revise and correct this. (In my defense, I've been home sick with the flu for the past few days, and I'm not firing on all cylinders.) When the VCO clock is divided by 64 to obtain the 44.1 KHz sample clock, the jitter time is *not* divided by 64. With this correction, I believe the rest of my analysis remains valid. That is, the clock division by 64 reduces the modulation index of the jitter on audio components by that same factor. So 5ns of jitter (a little more than that scope showed) represents only 1/10,000 of a cycle of a 20 KHz sine wave (period 50 microsec). And the modulation index would be proportionately lower at lower audio frequencies; down at 1 KHz, where there's far more energy in a typical audio signal, 5 ns would be only 5/100 (5 millionths) of an audio cycle! These are truly *tiny* phase modulation indices that would produce very little in the way of PM/FM sidebands. I just can't imagine that anyone could hear them. And I've left out the effects of PLL smoothing, which reduces jitter even further. But if you feel otherwise, conduct some properly controlled listening tests. I'm all ears. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Modifying squeezebox clock
Triode wrote: For some science, try the following: http://www.essex.ac.uk/ese/research/audio_lab/malcolmspubdocs/C41%20SPDIF%20interface%20flawed.pdf Okay, I've read it. And I'm still not convinced. Although his math looks fairly solid, he makes a lot of questionable assumptions that lead to very questionable conclusions. But he also makes some interesting observations. The first observation is that significant (i.e., measurable, though not necessarily audible) jitter appears only when a composite S/P-DIF signal is severely bandpass filtered. Indeed, his entire paper is all about the jitter caused by such filtering. This surprised me, as I had initially assumed that people were complaining about the jitter from timebase oscillators. That too-tight filtering can generate jitter is no surprise to me at all. I'm a digital communications engineer with experience in modem design, and we call this very well known and thoroughly understood phenomenon inter-symbol interference. (See the Nyquist Sampling Theorem for the math details.) Intersymbol interference is something we take great pains to avoid, as it can, if severe, impair the bit-error-rate performance of the modem even at high signal-to-noise ratios. But here, the author concedes that the jitter isn't so bad as to cause any bit errors. The *only* problem that remains has to do with jitter in the recovered clock stream. By now it should be obvious that if the only significant source of jitter is bandpass filtering of the S/P-DIF channel, then there is absolutely no point in replacing the timebase oscillator in a DAC in an attempt to reduce it. The timebase simply isn't the problem; the narrowband channel is the problem. Even the cheapest and worst crystal oscillators have very low phase noise; when you buy a more expensive crystal, you're mainly buying improved frequency accuracy and long term frequency stability, not lower phase noise. If the incoming S/P-DIF signal has a lot of jitter due to tight filtering, then even an absolutely noise-free local oscillator would be forced, by the error feedback signal in the clock recovery PLL, to reproduce this jitter at its output. This reinforces the comment I made yesterday that if you're truly concerned about jitter, then the very last thing you want to do is to attach an external DAC to your Squeezebox. Just use its internal DAC and you'll get an analog signal with virtually no jitter because there's no S/P-DIF link and no PLL anywhere in the path. Just a DAC clocked directly by a crystal, playing out audio data at its own rate. You can't get better than that. But back to S/P-DIF. The obvious and preferred solution to the S/P-DIF jitter problem -- if it's even a real problem -- is to simply avoid transmitting S/P-DIF signals over bandwidth-constrained channels in the first place. While this may be difficult in some professional applications where you have to go long distances, e.g., hundreds of meters, it ought to be easy in most consumer applications where you're only going a meter or so. Especially if the link is optical, as it often is. If that's not possible, then I agree with the recommendations in the paper: tighten the loop bandwidth of the clock recovery PLL in the receiver so while it will continue to track the incoming clock, it won't attempt to track the faster jitter components. (Another way to look at this is that the local reference oscillator won't be forced to follow the higher frequency components in the incoming jitter.) As the paper correctly points out, this may slow lock-up or prevent it entirely if there is an excessive frequency offset between the incoming and local reference clocks, but a two-step acquire/track PLL can fix this. But I'm still totally unconvinced there even *is* a jitter problem in the first place. His analyzes tend to assume absolute worst case, and even so the effect of jitter tends to be right at the level of the quantization noise in a 16-bit system. Considering that the vast majority of real-world audio sources, even the very best ones, have a dynamic range considerably worse than 16 bits, most people would conclude that jitter is simply not a problem worth fixing with hundreds of dollars of fancy accessories. And if anyone believes otherwise, all they have to do is to prove it with carefully controlled studies. Glowing testimonials and anecdotes from audiophiles won't do. --Phil ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Modifying squeezebox clock
Julian Alden-Salter wrote: 1) The fact that my dac locks on with different qualities of lock when mp3 and flacs are played back. Suggesting that there is indeed some difference in the spdif data stream between the two formats. What do you mean by different qualities of lock? I've had no trouble with my squeezebox connected optically to a Sony V333ES receiver. Works fine in both MP3 and raw PCM mode. There is an important difference between these two modes, though. A fixed-size buffer in the Squeezebox provides several seconds of network buffering at MP3 rates, but far less time at the much higher raw PCM speed. MP3 streams play fine, but I often hear music interruptions in raw PCM mode when the slimserver is doing other things (e.g., rebuilding the database.) Since most of my database is in FLAC format and is streamed in raw PCM format to the Squeezebox, this is a major concern for me. Renicing all slimserver-related tasks to a higher priority usually stops the interruptions, but this is clearly not a very desirable fix especially since the slimserver sometimes likes to gobble up all available CPU, e.g., when it's rebuilding the database or when it just goes out to lunch for no reason. It's clear that some attention should be given to real-time issues and thread scheduling priorities in the slimserver. Threads and processes involved in real-time playback activities should be given higher scheduling priority, whie background activities like rebuilding the database should be given a *lower* than normal priority. The UI/webserver should run at normal priority. Perhaps you're simply having similar problems with buffer underruns when operating in raw PCM mode? 2) The 'subjective fact' that the squeezebox sounded worse than a cd transport. They sound *exactly* the same to me, assuming of course there are no buffer underruns. Secondly we aren't talking about reclocking the dac. We are talking about reclocking the squeezebox - specifically taking the spdif output, stripping the old clock data out and adding a more accurate one to the data stream. If I understand correctly this is what both the trichord and tent xo3 boards do. *Any* external DAC with a S/P-DIF input should do a good job of cleaning up its input clock. That's the entire purpose of a clock recovery PLL. If you think that the PLL in a particular external DAC is badly designed and has too much jitter, then try tightening the bandwidth of its loop recovery filter. That should work just as well -- if not better-- as buying an expensive standalone clock regenerator box, and at the cost of just a few component value changes. The reason I say this should work even better than the external box is very simple. If, as that AES paper suggests, tight filtering of the composite S/P-DIF signal by the transmission line is the root cause of jitter, then it won't do any good to regenerate the clock in a separate box only to re-encode it as S/P-DIF and send it over another cable into the DAC; you'll just reintroduce the jitter! And if you use a high quality, wideband cable between the clock reconstructor and the DAC to minimize jitter, why not just use one directly between the Squeezebox and the DAC and omit the clock reconstructor box altogether? As for not using a dac, well the analogue output stages and filters inside the squeezebox are poor compared to that in a decent off board dac. Even with the jitter / unknown problems effecting the spdif output it still sounds better than the analogue outs from the squeezebox. Really? They sound just fine to me. I just can't get excited over minor differences in filter design that are highly unlikely to be audible. I'm old enough to remember all the nonsense about linear phase lowpass filters when the CD first came out, in 1984. A bunch of us tried carefully controlled listening tests and *none* of us could tell *any* difference among players in a blinded test with carefully matched audio levels -- with one exception. The only one player that we could easily tell apart from the others was the Sony D-5, the very first Walkman mini-player. It had very noisy analog electronics after the DACs, and the hiss was easily heard. A much more valid reason to use an external DAC is when the device whose DAC you're bypassing is in a system with a lot of digital noise running around. This can sometimes be true in your garden-variety PC sound card given that it's plugged into a motherboard with ~100A of supply current flowing through a high-end Pentium 4 only 10 cm away. But I sincerely doubt it's true in a small, low power box like the Squeezebox with its own power supply. Now it's still possible that there's a ground loop or similar design flaw in the Squeezebox that introduces noise into the analog outputs, but I haven't heard anyone complain about that yet and I haven't noticed any such noise myself. This is in contrast to some older network audio players, such as the
