[speex-dev] Introduction...

[A. J. Baker]

> 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 
> never.

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 
further.

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 
right answers.

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 
directions.

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 
later stage.

> Beware of Marketing guys.  They quote memory in bits instead of bytes 
> and words.

BTDTGTTS :-)

> 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.