I've been following this kist for a while now and I suppose I had better introduce myself. This is going to be rather a long message, but that can't be avoided. My name is Andrew Baker and I work for a company called TeleDesign. We are based in the UK. http//www.teledesign.co.uk I have lots of experience with telecomms, a fair bit with VoIP, quite a bit (but rather less recent) with DSPs and some concerning codecs. I am currently working on a project where I have "end to end" control - ie I know about both terminals and what connects them. The terminals at each end must be embedded devices. This project requires a codec which will compress speech down to around 8kbps. Looking forward, I am also involved in other projects where a good codec is going to be required - especially in the area of embedded devices which handle Speex. I looked around at codecs and the IP issues which surround codecs and was shocked. I knew it was all a bit messy - but the situation was far worse when examined closely. There is a very substantial barrier to innovation and getting products to market. So I looked around a little further and discovered speex. Having looked closely at speex, myself and my colleagues have made some decisions which I think the people here will find interesting. A) We are going to do some porting work to Port Speex to the TI range of DSPs. Initially we are going to target a TI Floating point device. the device we have chosen is the TMS320C6711 See http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TMS320C6711 B) We will then plan to do some porting work to the TI fixed-point range. Most likely TMS320VC5510 - basically because our project is battery powered the TI TMS320C55xx series is excellent as regards power consumption. See http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TMS320VC5510 C) TI within the UK are aware of what we are doing and are supporting us in various ways. In principle they seem happy with anything which reduces the barrier to entry for products which use their products. D) We will be releasing our codec on the same licence terms that apply to the rest of the Speex project. E) Our code will be written to all applicable TI recommendations - which means it should integrate well with other modules for the TI range of DSPs. You should be able to use the speex code in just the same way as you can use other codecs and TI DSP software components. F) I am also trying to persuade a certain large maker of Central-Office type VoIP cards to impliment Speex on their products. I haven't succeeded yet, but they are showing significant interest and are examining the issues carefully. Getting some embedded devices working with Speex would also help with this. ----------------------------------- So here's the relevant details of our plan. The following is subject to change - and any constructive suggestions for change will be seriously considered. 1) We're going to write a Codec using the DSP starter kit that will convert speech at 8/16 kbps 16 bits to/from an 8kbs serial stream. 2) We will some Linux utilities which will allow the TI developer kit to be connected to ethernet etc. This connection would require the use of one of the standard daughter cards for TI DSP kits - or you could build your own (I'm going to) using the adapter plugs and a couple of standard chips. I will include suitable schematics in the documentation. 3) We will then port the above codecs to the Integer DSPs 4) All the ports will be tested against the current Speex impliementation(s) 5) My first priority must be the project in hand. However I intend to do everything reasonably possible to get the fullest port of speex possible - or at least make it easy for others to build on the work I do. ----------------------- Tools We will be using 2 x TI DSP cards http://focus.ti.com/docs/tool/toolfolder.jhtml?PartNumber=TMDS320006711 2 x custom circuit board with UART and serial drivers. Code will be built using standard TI software tools. Code will be written with "C" and "C++" We currently use CVS for source control. We have the ability to temporarily host CVS on one of our Company servers - if there is any interest. We also have access to Windows 2000 machines and will consider porting the Linux Utils to that platform. Any tools and utilities we create as part of this project will be made available on the same terms as the codec proper. Tools and utilities will be built for the Linux Platform. We currently use SUSE 8.1 for our Linux development machines. I think that's it for now. Advice, warnings, hints, help and questions - all welcome. Andrew Baker <p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><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.
1. Good Luck 2. Keep posting, we are interested in a fixed point version of speex and would try to colaborate. Our need isn't as immediate but if you set this up correctly we and (hopefully) others will try to collaborate. 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 standard a. Should a totally objective measure be formed? Object + Subjective? b. Should MOS scoring or the like be used? (Yuck expensive) c. Should a bit-exact integer implementation be formed? I would suggest that a fixed point model be formed on Linux, Cygwin and/or Windoze first. Then port to the 55x (see comment 4). 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. 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.> -----Original Message----- > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On > Behalf Of Andrew Baker > Sent: Wednesday, February 19, 2003 12:56 PM > To: speex-dev@xiph.org > Subject: [speex-dev] Introduction... > > > I've been following this kist for a while now and I suppose I had better > introduce myself. This is going to be rather a long message, but that > can't be avoided. > > My name is Andrew Baker and I work for a company called TeleDesign. We > are based in the UK. > > http//www.teledesign.co.uk > > I have lots of experience with telecomms, a fair bit with VoIP, quite a > bit (but rather less recent) with DSPs and some concerning codecs. > > I am currently working on a project where I have "end to end" control - > ie I know about both terminals and what connects them. The terminals at > each end must be embedded devices. This project requires a codec which > will compress speech down to around 8kbps. > > Looking forward, I am also involved in other projects where a good codec > is going to be required - especially in the area of embedded devices > which handle Speex. > > I looked around at codecs and the IP issues which surround codecs and > was shocked. I knew it was all a bit messy - but the situation was far > worse when examined closely. There is a very substantial barrier to > innovation and getting products to market. > > So I looked around a little further and discovered speex. > > Having looked closely at speex, myself and my colleagues have made some > decisions which I think the people here will find interesting. > > A) We are going to do some porting work to Port Speex to the TI range of > DSPs. Initially we are going to target a TI Floating point device. the > device we have chosen is the TMS320C6711 > > See > > http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TMS320C6711> > B) We will then plan to do some porting work to the TI fixed-point > range. Most likely TMS320VC5510 - basically because our project is > battery powered the TI TMS320C55xx series is excellent as regards power > consumption. > > See > > http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TMS320VC5510> > C) TI within the UK are aware of what we are doing and are supporting us > in various ways. In principle they seem happy with anything which > reduces the barrier to entry for products which use their products. > > D) We will be releasing our codec on the same licence terms that apply > to the rest of the Speex project. > > E) Our code will be written to all applicable TI recommendations - which > means it should integrate well with other modules for the TI range of > DSPs. You should be able to use the speex code in just the same way as > you can use other codecs and TI DSP software components. > > F) I am also trying to persuade a certain large maker of Central-Office > type VoIP cards to impliment Speex on their products. I haven't > succeeded yet, but they are showing significant interest and are > examining the issues carefully. Getting some embedded devices working > with Speex would also help with this. > > ----------------------------------- > > So here's the relevant details of our plan. The following is subject to > change - and any constructive suggestions for change will be seriously > considered. > > 1) We're going to write a Codec using the DSP starter kit that will > convert speech at 8/16 kbps 16 bits to/from an 8kbs serial stream. > > 2) We will some Linux utilities which will allow the TI developer kit to > be connected to ethernet etc. This connection would require the use of > one of the standard daughter cards for TI DSP kits - or you could build > your own (I'm going to) using the adapter plugs and a couple of standard > chips. I will include suitable schematics in the documentation. > > 3) We will then port the above codecs to the Integer DSPs > > 4) All the ports will be tested against the current Speex > impliementation(s) > > 5) My first priority must be the project in hand. However I intend to do > everything reasonably possible to get the fullest port of speex possible > - or at least make it easy for others to build on the work I do. > > ----------------------- > > Tools > > We will be using > > 2 x TI DSP cards > > http://focus.ti.com/docs/tool/toolfolder.jhtml?PartNumber=TMDS320006711 > > 2 x custom circuit board with UART and serial drivers. > > Code will be built using standard TI software tools. > > Code will be written with "C" and "C++" > > We currently use CVS for source control. > > We have the ability to temporarily host CVS on one of our Company > servers - if there is any interest. > > We also have access to Windows 2000 machines and will consider porting > the Linux Utils to that platform. > > Any tools and utilities we create as part of this project will be made > available on the same terms as the codec proper. > > Tools and utilities will be built for the Linux Platform. We currently > use SUSE 8.1 for our Linux development machines. > > I think that's it for now. > > Advice, warnings, hints, help and questions - all welcome. > > Andrew Baker > > > > > > > > > > > > > > > > > > > > > > > > > --- >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. >--- >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.