[sdiy] $53 Intel Edison dual 500MHz Atom 1GB RAM SOC board has I2S + Intel Xeon Phi 72 core . . .

[rsdio at audiobanshee.com]

On Dec 3, 2014, at 6:35 PM, Robin Whittle <rw at firstpr.com.au> wrote:
> I am replying to Brian and nvawter.  I also look at Atom Silvermont
> floating point performance.  This CPU will be in the next generation 72
> core Intel Phi.
> 
> Brian, the TI DSP chip and devboard you mention:
> 
>  http://www.ti.com/tool/tmdx5505ezdsp
> 
> looks good to me for what it is, but I was interested in the Edison
> because of the possibility of writing sound and music code in C++, with
> full floating point processing.  This range of Intel DSPs is 16 bit
> integer only, which is a totally different thing.

Yes, I noticed that you mentioned floating point, specifically. However, I made the assumption that you were also considering the price, and really focused on whether an audio codec could be attached. The eZdsp at least hits the low cost with codec already taken care of. As for floating point, Texas Instruments does have DSP chips that provide floating point capabilities, but I believe that they are not as low power as the 16-bit fixed point.

By the way, these sorts of DSP chips use 16-bit fixed point instead of 16-bit integers, and thus they're actually dealing with fractional numbers. It's also very common in signal processing to use existing API to do the heavy lifting for things like FFT calculations or vector manipulations, so in some respects you don't have to worry too much about whether it's floating point or not. But I will admit that fixed point is more difficult than floating point, even though you do have C++ as an option.

I think it all depends upon which variables are most important. I chose the TMS320VC5506 because I absolutely needed to operate a DSP with lots of FFT on USB bus power only, with no external power supply. In that sense, I don't think it would have worked to have floating point.

If you're really focused on low power consumption, the MSP430 with FRAM uses less than half the energy of anything else out there, but I don't think it has floating point either (I can't actually remember because I only briefly worked with that chip for a wearable computing device).

I might sound like a Texas Instruments ad, but I do still think other companies have good offerings. SHARC and ARM and freescale and tons of options are out there. There's even XMOS if you want low latency computing and good audio codec support on the evaluation boards (see their DJ kit).

The Atom sure sounds interesting, but in the end it still fits into the spectrum of options with some advantages and some disadvantages, and it all depends upon which variables are most important to the project at hand.


> nvawter, I can understand the attraction of sharing patches etc. via the
> Net.  However, having anything connected to the Internet raises problems
> with security, privacy, robustness against viruses, worms etc. and the
> need for updating the kernel and other programs and parts of the OS in
> order to keep the system secure.  Managing such things is likely to be
> beyond the capabilities or interests of most users.

I was already going to say that sharing code is very likely not to work in such a situation. There are far too many differences between the various platforms, and it really takes knowledge of the hardware specifics to get the most performance out of any small device. That said, shifting the focus from code sharing to patch sharing is more likely to succeed. With a few standards for synthesizer engines across various platforms, it could be possible to share patches much wider than code can hope to be shared. And, this approach solves the issue with viruses and worms because no code is running. Sharing a patch cannot be a security risk because it's only data, not executables. The worst that can happen from sharing patches is that your ears are offended.

Brian Willoughby
Sound Consulting