[CentOS] Appliance platform

Ted Miller tedjeanmiller at sbcglobal.net
Mon Nov 10 03:45:39 UTC 2008

Les Mikesell wrote:
> Ted Miller wrote:
>> Les Mikesell wrote:
>>> Ted Miller wrote:
>>>> Application (in case anyone cares): Move better-than-FM quality 
>>>> audio across a leased audio circuit with delay under 10 seconds.  No 
>>>> Internet exposure.  Obviously one box is required at each end, and 
>>>> the encoding box works much harder than the decoding box.  Software 
>>>> to run will probably be Ices -> Icecast -> network -> mplayer.  Will 
>>>> be using USB audio interfaces, probably something like the M-Audio 
>>>> Fast Track Pro.  Because of the nature of the application, once it 
>>>> is booted up the only disk activity is occasional logging when there 
>>>> is a problem with the connection.
>>>> Any advice, web links, battle scars, or advice gladly accepted.
>>> Not quite a match, but maybe worth investigating the hackability: the 
>>> $99 Roku box sold initially to stream Netflix but supposed to be 
>>> getting other capabilities.  Or for just audio, their soundbridge 
>>> products that are more expensive but some include speakers.  
>>> Development specs are available for the soundbridge along with source 
>>> for gpl'd code included with the netflix box.  Not sure about 
>>> development on the netflix box, though.  Might be worth $99 just to 
>>> take it apart and see what's in there.
>> This would be more interesting for the playback end (no audio input 
>> capability is visible) if this were a one-time project, but we will 
>> probably have to supply more pairs in the future, so a more stable 
>> platform is more interesting.  Price is certainly right, but unlikely 
>> to hold, as they are charging $200 for their SoundBridge.
> The netflix box is new hardware - and there doesn't seem to be much 
> reason for promotional pricing.  They claim that they will release an 
> SDK soon for anyone who wants to generate their own channel (but not 
> opensource the box itself).  But as long as you can send some 
> standard-protocol stream, why worry about matching the hardware?

According to their FAQ the only "standard-protocol stream" it understands 
is "Windows Media formatted files from Netflix content servers", and 
according to the manual they are using Macrovision DRM software to control 
access.  That kind of approach is not compatible with the project I am 
working on.  We will encode with MP3, Ogg, or FLAC among other possibilities.

> A sip speakerphone might even work as an endpoint.

This is not to play background music at somebody's desk.  This application 
literally puts a company out of business any time it is not working.  It 
has to recover automatically and immediately following the removal of every 
possible problem that would interrupt the audio stream.  It will eventually 
be equipped with a USB drive full of MP3 material so be a temporary 
substitute in case the main audio source is lost.  Once I go to the work to 
get it right, I don't have the time to go back and rework it every time a 
consumer-type platform does a revision.  I want something that I can get 
working and know that six months from now, when I get a request for another 
system, I can order the hardware, program it up, and send it out the door.

> Here's an interview with the roku CEO:
> http://www.youtube.com/watch?v=7z3zUCiELcI

At the moment Firefox doesn't feel like playing any Flash, so I can't see this.

> The chumby is probably more hackable, but it already plays network streams.

Same problems with persistence in the face of obstacles.  My guess is that 
if the stream ends the Chumby is quite content to sit there silently.

Ted Miller
Indiana, USA

More information about the CentOS mailing list