A. J. Baker
Andrew at teledesign.co.uk
Wed Feb 19 13:58:22 PST 2003
> Point taken. Generically, if it is open source, I expect people might
> want to use more than just TI DSPs. We use TI DSPs alot and tried to
> say we'd never put it anywhere else. But, we found you can never say
That's certainly true. But the project in hand is very much a "one off".
I can't explain why, the project itself must remain confidential - but
trust me. It will be done, it will work and nothing further will happen
with it - its a dead end. The interest is that it gives me the funding
and the excuse to do this work.
However looking forwards it is indeed different as you say. But I'm
quite comfortable with the idea of working in stages. What is key is
that I make it easy for other people to take what I've done and take it
Obviously I need to thinkg further about the pros and cons of sticking
with the TI framework. The obvious first assumption is that it will be
great if you want to use TI and much less so otherwise. Some developers
will be very happy with having a TI starting point handed to them on
plate - it is relatively cheap and easy to get going with TI. Other
developers will want something more portable and general - there are no
We will actually have two programmers here working on this - myself and
another. The other, Tricia (who may join this conversation) is whizzo
with linux, C++ and portibility (I'm more a hardware guy who does the
maths, optimisations and precise C coding). One idea Tricia has
suggested is to do the grunt work in C and do a C++ wrapper to make it
work within the TI framework. Given we probably have processing power to
spare this might make a nice starting point and it will be close to the
best of all worlds - except that most people would then need to optimise
a real soltuion from the published code. But I see nothing too bad about
us publishing working, tested code written with a view to general
portability, and then optimising this code for our own application. This
would also have benefits for us in the future when we take this in other
Speaking entirely selfishly for a moment - I have a vested interest in
Speex (or something very like it) take off and be a success. I think I
will be able to sell projects and hardware on the back of it. Currently
the market is partially paralysed because the IP mess inhibits
innovation - it means you can never take a small risk - you always have
to take a big one.
At this stage I'm also going to explain "Why TI". The reason for TI here
is that they make nice DSPs which look like they'll do what we want
within our budget. I have looked elsewhere. Every alternative I
considered had a major problem. One factor is that TI are encouraging
and actively helpful. It is interesting to contrast their attitude with
(eg) Atmel who won't even talk to you abour their "media" products
unless you're into multi $million orders from the word go.
> I'd like to know more about that.
<p>I'll ask for more in email and post the response (assuming permission)
> For a long time DSPs in general and certainly TI fixed point DSPs like
> the 5x, 54x, 55x, etc. have had "EXP" and "NORM" instructions which
> could loosely be thought of as helping implement floating point - is
> this what he meant?
I'm fairly sure he meant a more than that. But I'm not currently well
enough armed to ask searching questions - I've been concentrating my
attention on the 6711 work. So, again I will revisit this point at a
> Beware of Marketing guys. They quote memory in bits instead of bytes
> and words.
> They probably also told you the C67x was 8 * Clock rate MIPS.
Actually no. He was very candid that TI had picked an artifical,
simplistic measure, that "MIPs" was not that simple and that headline
figures are nothing better than a crude starting point for comparison.
Ie Someone probably achieved that MIPs figure once, in totally artifical
conditions and someone might even achieve it again one day - but don't
expect you'll ever see it yourself in practice.
> On 55x you still require a good number of cycles to implement an IEEE
> floating point multiply. Download the free evaluation tools for the
> 55x from TI and look at their floating point multiply in the supplied
> library to get an idea (file = rts.src).
I've got the full kit coming and I'm currently having to (re) build the
machines to do the development on - so I'm going to wait until I get the
full software. ( The Linux computer is new, the Windows one is a rebuild
from an NT4 machine to 2000 because I need USB for the TI ICE stuff.
> if you are only intending to run 1-2 channels per 55x you might do it
> in floating point.
<p>I'm only after one channel in each direction. Battery life matters - but
the TI chip is only one part of it. I've got BlueTooth and analogue
stuff eating power to worry about and I only have to achieve around 5
hours from a set of batteries ie about the same as the talk time of a
modern phone. So I think I can afford to be a bit lazy.
Remember that at the moment I am going to be deliberately cagey on
getting too involved in technical detail - especially on the fixed point
stuff. Once I get started I'm going to come back on some of the issues
you have raised and develop them further. I'm very keen to ensure that
I'm covering the right ground and I'm very grateful for comments like
yours - which give some good pointers aa to what I need to be looking
out for as I work up the learning curve.
<p><p><p>--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Speex-dev