Gloolabs Readies A Java-Based WiFi Audio Device

An anonymous reader writes "A new Java powered home entertainment audio device design promises to simplify sharing computer music files among computers and stereos in connected homes. Gloolabs's Gloo is Java middleware that puts an iPod-like interface on music files it "discovers" around the network. Gloo, which will be licensed to multiple device makers, is available now on one device that runs embedded Linux, and Gloolabs is currently bootstrapping a Gloo developer community. Gloolabs is currently taking orders for the $250 MacSense HomePod, the first Gloo-based device, which will ship in January 2004. A limited quantity of the $350 Developer Edition is available now."

Comments

Open-ish source....

[tcopeland]

...or something like that. From the GLOO site:

Open firmware philosophy - The Java source will be made available to the GLOO
developer community. Developers will be able to enhance any of the software
components including the firmware running on the hardware.

So, buy the Developer's Edition and you get the source code. Cool.

Neat idea, but

[ActionPlant]

I'm already thinking of security compromises. What's to stop an outside source from eventually being able to search this in an attempt to determine if you have illegal music? Also, error logs could pose a problem. I'm assuming they have that worked out, but using java to do this worries me. With an intelligent search, the ability to spider your own network looking for files...should it grab the *ahem* "wrong" file and surprise you with it when your parents are visiting...uh oh.

Damon,

Ouch

[djupedal]

"*While standard ACC files are supported, Apple Music Store Downloads are not due to DRM restrictions."

A bit of creative capture should solve this, I believe. However, it bodes not well for other formats.

Re:Ouch

[laird]

Right, there are two basic approaches (that I can think of) to playing DRM'd music on a device like this.

1) Implement the DRM on the device, and handle the key management, etc., so that the device has the same rights to decrypt and play the DRM's content.

2) Use the DRM on the desktop computer, and stream the result to the device.

I think that (2) is the better approach, because it means that you don't need to do the work of porting a zillion proprietary DRM systems to your box, but can leave that on the desktop where's it's already present (or you wouldn't have the DRM'd content). The easiest way to do it would be to have the 'streaming' software tell the desktop music software to play whatever you wanted, capture the metadata and output stream, and send it to the device. It'd require a little integration to be able to remote control WMP, iTunes, etc., and capture their audio output stream, but that's got to be less work than licensing and porting their proprietary code to Linux.

IMO, of course.

Ogg?

[Damon C. Richardson]

No Ogg? forget it! ( here's my dollar walking away ).

Re:why do all these players need extra software?

[seanadams.com]

why do all these players need extra software?

Because there are very severe penalties for doing it over just file sharing. It's why the audiotron takes 45 minutes or more to scan a large music collection when it crashes, can't handle collections of more than 10K songs, and doesn't have sophisticated search capabilities or a decent web interface. All these things need a more powerful device.

Slim Devices pioneered the "thin client" approach, which solves all of these problems and furthermore, makes it possible to develop plugins, web skins, additional codecs, and so on.

Also consider the multi-room environment - why replicate music database information across more than one device? Centralizing this work at the server has so many advantages that the cost of a double-click to install software is really negligible.