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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
