Bottom feeding network appliances II

Dec 18, 2009 2 Replies
[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??)

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required