[sdiy] Audio hardware platforms?

[Dan Snazelle]

great post !!! very informative

Sent from my iPhone

> On Oct 13, 2013, at 3:54 AM, "Tom Farrand" <mbedtom at gmail.com> wrote:
> 
> A floating-point DSP in an audio hardware platform seems a natural,
> yeah?  Well, yes and no.
> 
> H/W Cost and Complexity:
> The first thing I think of when I hear "DSP" is "BGA".  Many of the
> more capable DSPs seem to only be available in ball grid array
> packages.  What's the problem?  For one, it often takes a six-layer
> PCB to jailbreak all of the balls to fully utilize the part.  Six
> layer boards are expensive to buy in prototype quantities.  The
> initial cash outlay to get something off the ground is very
> substantial.
> 
> Coding it up:
> The universe of people who can craft the requisite software for a DSP
> is probably smaller than the universe of people who can craft the
> requisite software for other compute platforms.
> 
> Time:
> To design such a platform and debug it, and then craft the software
> for it, will take a long time.  It is possible that by the time this
> all comes together, a better widget might then exist that can be
> "bent" to serve the need even better.  All that effort and cost
> expended thus far could be for naught.  Ouch.
> 
> Obsolescence:
> DSPs come and go rather a bit faster than I am comfortable with.  If
> commercial market demand for the magic DSP part chosen for this audio
> gizmotron shrinks, the part can evaporate overnight.  The realistic
> approach is to not find the "ideal" compute elements but to find
> acceptable compute elements that will have a lifetime that
> significantly exceeds the time it takes to get some working software.
> 
> 
> My $0.02:
> 1) Obtain some consensus on what the end platform shall do.  At this
> point, don't define "how" something is to be done, define only the
> "what".
> 
> 2) Next, detail which software functions are required to implement the
> functionality the end platform is to provide.  It is essential to know
> (and document) what you want to do before deciding on how to best do
> it.  Write the code comments at this point, which explains how the
> required things are accomplished.  Don't write the code yet ... just
> the comments and function headers.
> 
> 3) Buy off-the-shelf hardware that is capable of hosting the software
> functions required.  Don't design new hardware for the whole damned
> thing.  Buy the complex pieces off-the-shelf and custom design only
> the bits of glue or peripherals minimally necessary to carry out those
> functions not natively provided on the off-the-shelf boards.  Keep the
> design of custom bits straightforward and as simple as possible.  Now,
> write the code to match the comments documented previously.
> 
> 4) Get ugly ... fast.  Identify risk elements early on and pull the
> plug on the things that are proving to be unrealistic for time or cost
> reasons.  You might have to go back to the point of asking "Is this
> still worth doing if we can't provide function 'x'?"  Better to know
> that on day 17 instead of day 308.
> 
> Peace.
> Tom Farrand
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Sat, Oct 12, 2013 at 5:42 PM,  <rsdio at sounds.wa.com> wrote:
>> Apple is not making a device that is primarily geared towards audio. They're
>> making a general purpose device that does GPS, compass, cell (voice and
>> networking), wireless networking, touch, massive GUI for endless
>> possibilities in applications, and then also audio and voice recorder type
>> features - all on top of a fairly sophisticated mobile operating system. It
>> makes way more sense to use a general purpose processor like the ARM for
>> that long list of features, rather than just specializing on one or two
>> specific features.
>> 
>> But a couple of DSP opcodes in an ARM variant does not make those chips
>> perform like a dedicated DSP, which has much more silicon dedicated to high
>> performance of a particular kind. If you want to focus on audio, then a DSP
>> makes the most sense. There are even some DSP chips, like the TMS320 C55xx
>> family, that have USB and other hardware support that allow them to handle a
>> display and basic interface tasks while primarily devoting the bulk of the
>> power to signal processing.
>> 
>> 
>> Apple does have to worry about performance because they're a battery-powered
>> mobile platform. But the fact that they're doing many things means that they
>> need a processor that does reasonably well at a wide variety of things.
>> 
>> For an audio hardware platform, battery power might not be as important,
>> since adaptors can usually be attached for power. But there's still some
>> importance for performance, especially if you want to do a lot of effects
>> without needing a high-wattage supply. The nice thing is that a good DSP can
>> do more audio processing than a full-on computer (laptop or desktop) using
>> far less power.
>> 
>> 
>> As for price, a well-designed DSP like the TMS320 is actually much cheaper
>> than an FPGA chip when you really start doing complicated processing. DSP
>> chips are very competitive with ARM on price, so I don't think anyone would
>> choose ARM just to save money. The AVR can go lower in price, but the AVR
>> cannot handle as much as the ARM or a DSP, so that particular choice is a
>> price/performance tradeoff.
>> 
>> Brian Willoughby
>> Sound Consulting
>> 
>> p.s. I just discovered the XMOS chip, and that company has a few interesting
>> platforms for development. I just saw the XK-USB-AUDIO-U8-2C, which actually
>> has on-board MIDI I/O connectors along with stereo audio I/O and, of course,
>> USB. There may be a plug-in board for an LCD, but I've not really studied
>> their offerings. They do have a multi-channel audio I/O version, but that
>> one does not have MIDI. They also have mini-board that plug in to the
>> various main boards, adding optional peripheral I/O. As for something that
>> can be sourced later for manufacturing, I think the XMOS development
>> platforms show how there are just too many variations for anyone to make
>> exactly what you want - it's a shame that their MIDI board is only stereo,
>> while their multichannel audio board has no MIDI. I still think it's
>> necessary to prototype on a generic board with added options, but then pay
>> to have a purpose-built PCB made that fits your product enclosure and has
>> exactly the I/O you need, no more and no less.
>> 
>> 
>> 
>>> On Oct 12, 2013, at 14:15, Joel B wrote:
>>> 
>>> Question, these DSP processors - are they a better choice than the Arm
>>> Cortex/neon for music? Wondering since companies like apple are using the
>>> Cortex series. Is it a price/performance thing?
>>> 
>>> Joel
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Oct 12, 2013, at 9:01 AM, Martin Klang <mars at pingdynasty.com> wrote:
>>>> stm32f4
>> 
>> 
>> 
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy