Bottom feeding network appliances II

[Argh! I hit send before adding...]

I am also looking for similar suggestions for a
network audio client. Think: "Internet Radio"

This has many of the same characteristics as the
VoIP-ish phone with a few key distinctions:
- dual D/ACs running much faster (e.g. 50KHz)
- no A/DC
- larger memory requirement (maybe 100K?)
- larger TEXT requirement (maybe 30K?)
- more MIPS as audio is less forgiving than telcom

Note that this also suffers from the power/space
constraints of the VoIP-like application! I am
hoping to benefit from some of the things
learned there -- and learn even more from this!
(i.e., "Make TWO to throw away!" :> )

This might end up commercialized or offered as
an open source project so that probably means
more readily accessible parts (i.e., something
that a hobbyist can purchase one-off from a
local vendor -- *I* don't want to be in the parts
business! :> )

Again, suggestions sought as well as pointers to
interesting reference designs that I might learn from.

Thanks!
--don

 

Are you planning to generate the streams for this, or use streams made by
other people? If the latter, you'll probably be restricted by whatever
formats they use (MP3, WMA, whatever). An appliance which can only use a
small variety of stream formats is more pain than it's worth IME.

If you do use existing formats, you'll probably need more CPU/RAM to do the
decode unless you farm it out to a separate decoder chip (but then you'll be
stuck when WMA25 comes along and changes everything). And some of the
proprietary codecs only come prebuilt for some architectures.

Theo

 

Anything going to the appliance has to come from or go *through*
a server under my control. Why push the "smarts" to decode
various different formats into the device when you are going
to have/want/need several of them *and* the server is going
to be there anyway? (I surely wouldn't let the outside world
have access to anything inside the house without going through
a secure bastion host! And, if I *never* had access to the
outside world, it is relatively trivial to glue standard
decoders onto media files *before* sending the streams off to
the actual client! Any bugs in *that* code are then fixed in
*one* place and immediately beneficial to all clients. Clients
can then be *very* simple and robust as you truly can test
them "100%".

Support for a wide variety of formats is geared towards consumers
who want *one* such device, don't want to know how it works, want
"interoperability", etc.

Your only vulnerability is to formats that come from "outside".
Any media that you already own can be converted *once* to
whatever format you want. E.g., convert everything to AIFF
and store it that way if you don't want to spend any compute
resources on the server when a client calls for that "title".

If you get something in a proprietary format, convert it
"wherever" to "whatever" and you never need to convert
it again. E.g., why keep decoding MP3's each time they are
played? Pick some simpler format to decode and use *that*
and reap the benefits of simplifying the client software
and hardware. Even if my 20G of MP3's would expand to
a TB, so what? I use an $80 disk to store them instead
of a $20 disk? (can you even *buy* 20G disks??)