[sdiy] Audio hardware platforms?

Tom Farrand mbedtom at gmail.com
Sun Oct 13 09:52:19 CEST 2013


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



More information about the Synth-diy mailing list