SoundBridge M2000 and SlimServer

[Greg Friedman]

I've had my eye on the SoundBridge for many moons as an upgrade to my
Audiotron. Specifically, I've wanted to move my music collection over to
FLAC and the SoundBridge acting as a frontend for SlimServer promised to be
the best solution on the market. The shift from SlimServer to iTunes as a
preferred backend has confused me, and I'm trying to figure out if it still
makes sense to buy a SoundBridge.

Reading the SoundBridge manual online makes it very clear that the majority
of Roku's SoundBridge effort is being directed towards their custom UI and
iTunes integration. What does this mean about the quality of experience with
SlimServer as a backend? Photos of the M2000's 3-line display look
fantastic,
but I can't figure out what it will look like fronting for SlimServer. Will
it display three lines of text? Will the fonts be dramatically different?
Will there really be no support or documentation available for SlimServer
users? Seems like there is a disconnect between the website claims of Og and
FLAC support and the manual which basically says, "Use it at your own risk."

For what it's worth, I can't help feeling a bit let down by this embracement
of iTunes. iTunes may be an interesting app to run on a desktop machine, but
many of us early adopters have headless media servers running some variant
of Windows and a dependency on a GUI-driven app like iTunes just doesn't fit
into our worlds. The Audiotron's use of SMB and SlimServer's capability of
running as a server are both reasonable solutions. I'm hoping that you guys
see this and are planning to spend the resources to maintain your SlimServer
support and make it work as well as possible given the limitations of the
SlimServer architecture.

Just my 2 cents.

Thanks...

Greg.


--
Greg Friedman
***@cognosis.com

[Mike Kobb]

Hi Greg,

Let me answer a few of your questions.

First of all, what many people don't realize about the SlimServer is that
it not only provides the back-end library functionality, but also generates
the entire display that you see on the screen.

Although we initially discussed doing modifications to the open source
SlimServer to support our bitmapped displays, visualization capabilities and
so forth, we are no longer pursuing that approach. Rather, we have
engineered SoundBridge to connect to the unmodified server software.

We did this by implementing a SlimServer-compatible mode, where the
SoundBridge essentially appears to the server as if it were a SqueezeBox.

Therefore, what you see on the SoundBridge when connected to a SlimServer
is exactly what you would see on a SqueezeBox. The exception being that on
an M2000, the text is twice as tall and therefore legible from a greater
distance.

If you want to see the 3-line display, you need to use our built-in player
software with an iTunes back end. We believe that the large majority of our
customers will choose this approach, because of the simplicity of
installation (no need to install additional software on the PC for people
using iTunes as their jukebox already) and the advantages of our client
(like a simple navigation model, the support for multiple font sizes and
bitmapped display elements).

There is no documentation available from Roku for the SlimServer, because
none is needed. Because the software is unmodified, the documentation
provided by Slim Devices is all you need. Refer to our documentation for
setup of the SoundBridge and connection to your network. Refer to the
SlimServer documentation for setup of the server and operation of the
client.

FWIW, although iTunes doesn't run on a NAS (neither does SlimServer) or on
Linux, it works pretty well on a headless server, be it Mac or PC. I have
an old G4 Mac in my media rack at home connected to a 360GB disk array with
my uncompressed music library. I never have any need to view the screen of
that machine, except when I'm adding new music to the library. You can fire
up iTunes, minimize it, and not worry about it. If I needed to access the
iTunes GUI for any reason and didn't want to walk to the rack, I have a VNC
server running on that computer.

If you actually use the server machine for other purposes, you can (on
MacOS X 10.3 or Windows XP) create a separate user account just to run the
iTunes server, start it up, and then do the fast user switch to your usual
account. iTunes will run happily in the background, and you can even listen
to the library on the local computer via the network sharing feature on a
second copy of iTunes running in your normal account.

It's true that our client does not support FLAC or Ogg at this time.
That's because iTunes doesn't support those formats. We do hope to support
Apple Lossless in a later release -- we have asked Apple for specs on this
codec, but have not received them so far.

Let me close by saying that we have said all along that we want to make
the SoundBridge usable by people who use different "back end" products. For
1.0, that means iTunes and SlimServer in an emulation mode. As we progress,
we are evaluating other server offerings and will support those that make
sense and have good adoption rates.

Best,
--Mike

Post by Greg Friedman
I've had my eye on the SoundBridge for many moons as an upgrade to my
Audiotron. Specifically, I've wanted to move my music collection over to
FLAC and the SoundBridge acting as a frontend for SlimServer promised to be
the best solution on the market. The shift from SlimServer to iTunes as a
preferred backend has confused me, and I'm trying to figure out if it still
makes sense to buy a SoundBridge.
Reading the SoundBridge manual online makes it very clear that the majority
of Roku's SoundBridge effort is being directed towards their custom UI and
iTunes integration. What does this mean about the quality of experience with
SlimServer as a backend? Photos of the M2000's 3-line display look
fantastic,
but I can't figure out what it will look like fronting for SlimServer. Will
it display three lines of text? Will the fonts be dramatically different?
Will there really be no support or documentation available for SlimServer
users? Seems like there is a disconnect between the website claims of Og and
FLAC support and the manual which basically says, "Use it at your own risk."
For what it's worth, I can't help feeling a bit let down by this embracement
of iTunes. iTunes may be an interesting app to run on a desktop machine, but
many of us early adopters have headless media servers running some variant
of Windows and a dependency on a GUI-driven app like iTunes just doesn't fit
into our worlds. The Audiotron's use of SMB and SlimServer's capability of
running as a server are both reasonable solutions. I'm hoping that you guys
see this and are planning to spend the resources to maintain your SlimServer
support and make it work as well as possible given the limitations of the
SlimServer architecture.
Just my 2 cents.
Thanks...
Greg.
--
Greg Friedman
_______________________________________________
Roku-tech mailing list
http://lists.rokulabs.com/mailman/listinfo/roku-tech

------
Mike Kobb
Senior Software Engineer, Roku
Get more out of your high-def TV.
High-definition photos, art, music and more.
http://www.rokulabs.com
tel: [phone] x12 fax: [phone]

[justin blecher]

Post by Greg Friedman
For what it's worth, I can't help feeling a bit let down by this embracement
of iTunes. iTunes may be an interesting app to run on a desktop machine, but
many of us early adopters have headless media servers running some variant
of Windows and a dependency on a GUI-driven app like iTunes just doesn't fit
into our worlds. The Audiotron's use of SMB and SlimServer's
capability of
running as a server are both reasonable solutions. I'm hoping that you guys
see this and are planning to spend the resources to maintain your SlimServer
support and make it work as well as possible given the limitations of the
SlimServer architecture.

greg,

not sure if this will help you out, but there are other daap-compatible
servers out there besides itunes. check out daapd[1]and mt-daapd[2].
they are of course written for un*x, so not much help for a machine
running windows, but someone has ported daap for windows[3].

i haven't tried them yet, but i am *very* interested in replacing a
server running smb/nfs/appletalk with just one protocol: daap. of
course, the clients have to be capable of talking daap, but the current
favorite (itunes) has no problems with that. <g> plus, there are other
daap clients out there[4]. granted, they aren't all that pretty, but
there is work being done.

personally, i find a daap client/server setup much more appealing than
a file-system sharing based setup. for one, it works better over slow
links: the server can read and parse the media files faster than a
client over an 802.11b connection.

anyway, just some food for thought... :)

[1] http://www.deleet.de/projekte/daap/daapd/
[2] http://sourceforge.net/projects/mt-daapd/
[3]
http://www.rustydust.net/cgi-bin/wiki.pl?
action=browse&diff=1&id=WinDaapd
[4] http://sourceforge.net/projects/jtunes4/ (there are others)


-justin

[Greg Friedman]

This is interesting info.

An intelligent server that catalogs metadata is fine with me as long as it
is designed to run well on a server. A client app like iTunes doesn't fit
the bill though, since it requires an active UI session and has client-app
type behaviors. A non-Apple implementation of a DAAP server would be a
particularly interesting proposition because it could do server-side
on-the-fly translation between non-Apple supported formats and
Apple-supported formats (e.g., transparent FLAC to WAV conversion).

It's also worth noting that implementation strategies aren't polarized
between a) smart clients that talk a file-server protocol (e.g.,
SMB/NFS/AppleTalk) and build catalogs on the client and b) smart servers
which build catalogs on the server and use higher-level protocols (e.g.,
DAAP, SlimServer) to drive dumber clients. Consider, for example, the TOC
generation model supported by the Audiotron which enables a catalog to be
built on the backend, which the client consumes, but the client talks a
file-system protocol. Tools like Philip Jacob's excellent TOC Generator[1]
can be run as a chron job, on demand, whatever, on the backend to build up a
catalog file, which the media player reads. No trolling metadata across a
thin pipe, and no need for a new protocol on the server.

Anyhow...I think we're probably straying from the purpose of this list and
should take this discussion offline if it's worth pursuing.

Thanks again for the info...

Greg.

[1] http://www.whirlycott.com/phil/software/audiotron/

Post by justin blecher
not sure if this will help you out, but there are other daap-compatible
servers out there besides itunes. check out daapd[1]and mt-daapd[2].
they are of course written for un*x, so not much help for a machine
running windows, but someone has ported daap for windows[3].
i haven't tried them yet, but i am *very* interested in replacing a
server running smb/nfs/appletalk with just one protocol: daap. of
course, the clients have to be capable of talking daap, but the current
favorite (itunes) has no problems with that. <g> plus, there are other
daap clients out there[4]. granted, they aren't all that pretty, but
there is work being done.
personally, i find a daap client/server setup much more appealing than
a file-system sharing based setup. for one, it works better over slow
links: the server can read and parse the media files faster than a
client over an 802.11b connection.
anyway, just some food for thought... :)
[1] http://www.deleet.de/projekte/daap/daapd/
[2] http://sourceforge.net/projects/mt-daapd/
[3]
http://www.rustydust.net/cgi-bin/wiki.pl?
action=browse&diff=1&id=WinDaapd
[4] http://sourceforge.net/projects/jtunes4/ (there are others)
-justin
--
justin blecher // sr. design engineer // digital pulp | nyc
vox://212.679.0676:235 fax://212.679.6217
_______________________________________________
Roku-tech mailing list
http://lists.rokulabs.com/mailman/listinfo/roku-tech

[Mike Kobb]

Howdy,

Just a quick heads-up that we haven't tested against non-iTunes DAAP
servers.

The one requirement to work with SoundBridge 1.0 is that the server *must*
support DAAP queries. My brief exposure to daapd suggests that it does not
support queries. (We use queries in order to keep our overall memory usage
low -- we load minimal information about a list of song, then use a query to
fetch the information needed to play the selected song).

I'm hoping to remove that requirement in a later release to improve
compatibility with other servers.

Best,
--Mike

Post by justin blecher

Post by Greg Friedman
For what it's worth, I can't help feeling a bit let down by this embracement
of iTunes. iTunes may be an interesting app to run on a desktop machine, but
many of us early adopters have headless media servers running some variant
of Windows and a dependency on a GUI-driven app like iTunes just doesn't fit
into our worlds. The Audiotron's use of SMB and SlimServer's
capability of
running as a server are both reasonable solutions. I'm hoping that you guys
see this and are planning to spend the resources to maintain your SlimServer
support and make it work as well as possible given the limitations of the
SlimServer architecture.

greg,
not sure if this will help you out, but there are other daap-compatible
servers out there besides itunes. check out daapd[1]and mt-daapd[2].
they are of course written for un*x, so not much help for a machine
running windows, but someone has ported daap for windows[3].
i haven't tried them yet, but i am *very* interested in replacing a
server running smb/nfs/appletalk with just one protocol: daap. of
course, the clients have to be capable of talking daap, but the current
favorite (itunes) has no problems with that. <g> plus, there are other
daap clients out there[4]. granted, they aren't all that pretty, but
there is work being done.
personally, i find a daap client/server setup much more appealing than
a file-system sharing based setup. for one, it works better over slow
links: the server can read and parse the media files faster than a
client over an 802.11b connection.
anyway, just some food for thought... :)
[1] http://www.deleet.de/projekte/daap/daapd/
[2] http://sourceforge.net/projects/mt-daapd/
[3]
http://www.rustydust.net/cgi-bin/wiki.pl?
action=browse&diff=1&id=WinDaapd
[4] http://sourceforge.net/projects/jtunes4/ (there are others)
-justin

------
Mike Kobb
Senior Software Engineer, Roku
Get more out of your high-def TV.
High-definition photos, art, music and more.
http://www.rokulabs.com
tel: [phone] x12 fax: [phone]