> > 4. I think the codec is portable to more fixed point embedded devices > > if you stick to C rather than C++ code. If you follow the TI XDAIS > > standard you'll wind up creating an object-oriented codec but you can > > do it all in C (Relocatable, re-entrant code, state structure, etc.). > > Who knows you might want to run it on an embedded DSP that doesn't > > support C++ someday. > > > I doubt I will. Others might :-)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.> > OK. Noted. > > I've also been told by a TI applications BOD that although the 55x is a > fixed point device, it does contain some internal features which speed > up running floating point code. This was done to meet certain > requirements in the Mobile market and they suspect that there may be > enough computing power to running a floating point codec on the 55x.I'd like to know more about that. 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? 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. 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 guess if you are only intending to run 1-2 channels per 55x you might do it in floating point. High density, no.> An issue to consider is why we want a fixed-point port. I suspect we/you > do. But I'd currently hate to have to justify that suspicion rigourously.I want a fixed point port because an embedded, say battery powered device, that runs this codec will need a huge battery if it is a floating point device. Cheap VoIP phones, for instance, might want to use a 54x, 21xx, ZSP, 3DSP, ARM, MIPS, StrongARM... you get the idea. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> 3. I'm interested in the methodology for creating a fixed point > implementation and guaging how "good" it is relative to the floating > point golden standardMy methodology at this stage is to get it working on the floating point DSP first and to gain recent experience in both Speex and the TI DSP range while I do so. Then I'll enter into serious discussions about the fixed point version - see below.> 4. I think the codec is portable to more fixed point embedded devices > if you stick to C rather than C++ code. If you follow the TI XDAIS > standard you'll wind up creating an object-oriented codec but you can > do it all in C (Relocatable, re-entrant code, state structure, etc.). > Who knows you might want to run it on an embedded DSP that doesn't > support C++ someday.<p>I doubt I will. Others might :-) More specifically - the manufacturer of VoIP cards I refer to earlier build their current cards using fixed point DSPS (although they use floating point DSPs (Sharc) elsewhere in their range. They have a number of seriously talented and very well equipped DSP programmers in their staff - their business depends on how much they can squeeze out of every DSP. If suceeded in getting them interested it would be good. I personally would prefer working in C rather than C++. But my choices might be limited. :-) I'll come back to this point when all the TI stuff arrives and I've looked through it all. I've just had notification it has been despatched.> 5. You should take a close look at the intrinsic definitions on the > 55x when making your (the?) integer implementation. When you port to > the 55x you can substitute the intrinsics and get alot of MIPS > reduction right away. We've seen alot of similar intrinsics on other > (non-TI) DSPs too.OK. Noted. I've also been told by a TI applications BOD that although the 55x is a fixed point device, it does contain some internal features which speed up running floating point code. This was done to meet certain requirements in the Mobile market and they suspect that there may be enough computing power to running a floating point codec on the 55x. Again when I've got this working on the 6711, it will be much easier to come back to this using some of the TI tools to tell me how good (or bad) it is going to be. I might not have an immediate need to do a true, full "fixed point" port at all. An issue to consider is why we want a fixed-point port. I suspect we/you do. But I'd currently hate to have to justify that suspicion rigourously. <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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.