 Is it better? Better like this? OK. So I'll be talking about Speaks, which is a speech code that I wrote, and it's used in voice over IP. So what I'm going to talk about is I'll have a brief introduction to Speaks. Then I'll have some detailed explanations of how Speaks work and the algorithm that it uses. That's the only part that will be quite technical. The rest won't be. So I'm going to talk about the features in Speaks, how to use Speaks in applications. I'll have a lot of audio samples. And I'll be talking about some recent development road map of what's coming ahead and then I'll complete with a bit of advocacy. So first, what is Speaks exactly? So it's an audio codec that has this particularity that it's specifically designed for encoding speech and designed for voice over IP in mind. It can also be used to compress files in the subcontainer, but the main design decisions were made for voice over IP. So it's open source, free software, whatever. It's licensed under the BSD license. It's mainly designed to avoid software patents. I've got a star there because it's not a trivial task to do. Basically I've avoided all the known stuff, but with software patents, all those that attended Richard Stallman's talk, you see that nothing is simple and you never know exactly whether you infringe or not or what happens with that. So this is the current situation, but at least the effort was made to limit the damage of software patents with Speaks. So it's developed within the ZIF.org foundation, which is also responsible for the Vorbis audio codec, the Fiora video codec, FLAC, and some other ongoing projects. Speaks is now included in most Linux distributions. So as I said, the idea of Speaks is to have an alternative to the closed, expensive proprietary codecs that exist today. And it's based on an old and reliable technology called Kelp, which I'll explain a bit later. So this is just a brief history of what's been going on. So prior to about 1875, people have been using technology known as voiceover acoustic waves, which was the only way you could communicate. And then we had analog telephony for a long time. Then telephony moved to digital with New Line A-Law, which was the first digital audio codecs. Then the algorithm called Kelp was first presented in 1984. A bit afterwards, you have codecs that's still used today, even though the quality isn't that good, which is the GSM full-rate codec. So that was 1990. Around 95, some newer codecs arrived, like G729, G723.1, which are proprietary and really expensive. Following those, there's been a lot more proprietary codecs like this, more like in a race, just to be the one that has the patents in the most standard to get as much money as possible, more than just improving on technical grounds. So Speaks was started in response to that in 2002. It's been part of the Ziv.org Foundation over 2002. And since March 2003, the bitstream for Speaks has been frozen with the release of the 1.0 version. That means that any version you use later than that will be compatible with any other version, even if Speaks itself can change, it remains compatible for the bitstream. So these are the goals and the design decisions that were made for Speaks. First one was that the frame size and the overall delay added by the codec has to be small. This is a requirement for voiceover IP. You want to keep latency to a minimum, which is not the case necessarily for when you encode files. The encoding and the decoding must work with limited resources. Once again, you don't care if it takes an hour to encode a one minute file if it's for just distributing files. You do care for voiceover IP. It has to be designed so that distortion is minimized when you lose packets because voiceover IP, IP is unreliable. You tend to lose packets. You have to leave with that. It's designed to support Norban and Wideband. I'll explain what these are a bit later. Designed for multiple bit rates and multiple quality settings. Some people have a lot of bandwidth. Some people have less. Someone really good quality. Some others just want to be able to understand what's being said. And the idea is to achieve as good compression as possible by while still avoiding software patterns. All those requirements led to choosing CELP, mainly because it has already been proven that both low bit rate and high bit rates. Many of the patterns that are related to CELP has expired now. And with that, I'm still minimizing, unlike some other CELP codecs, I'm minimizing the dependency between frames without going to the extreme for those who know the ILBC codec that has completely independent frames. But it comes with a price that's a bit too much. So CELP still has some dependency, but not too much. So now I'll be talking about CELP specifically. It means the acronym means Code Excited Linear Prediction. It first was presented in 1984. And it's still the most popular speech coding algorithm. The original version was sort of 100 times slower than real time on a Cray supercomputer. So at the time it was presented, it was a really nice idea, but it wasn't really practical. Since then, the machines have got faster, and people found a lot of ways to cut down on the complexity. So it can now run pretty much every cell phone now uses some kind of CELP variant. There's a lot of them. Many have patents on them. A lot of those patents are also standard-specific. Like in this standard, I will initialize this variable to 0, and I have a patent on it. The main reason for that is when they divide the royalties, they look at the number of patents. They don't care if the patent is trivial. They just divide by the number of patents. So the general idea that I could summarize for CELP is that if you take exactly the right noise and you filter it carefully, it may eventually sound like speech. And I'll show a demonstration of that later. Sorry, I tend to use speaks instead of speech. But so in more detail, the main ideas of CELP, first it's to use linear prediction, also known as LPC. That means instead of encoding one sample directly, you predict what you think that sample would be worth based on the previous samples. So you can save a lot of bit rate there. It uses what's called perceptual weighting of the noise. That means if we minimize the noise in the places where the ear would hear the most and we put more noise where you wouldn't really notice it, you can have better quality and lower bit rate. That's used by most audio codecs now. There's the idea of analysis by synthesis. What that means is the encoder actually simulates a decoder, and it optimizes the bit for what the decoder would decode in terms of audio. So it tries to minimize the noise based on the decoder. And the other idea is the use of vector quantization, which means instead of taking values and quantizing them separately, you take a bunch of them and you assign IDs for a whole bunch of values. So quickly, this is what speech signals look like. On the top here, I've got voiced sound. In this case, I think it's the sound R. And in time domain, what it looks like is you see that there are impulses, one impulse there, one impulse there, one one. And it just gets filtered so it oscillates afterwards. In the frequency domain, what it looks like, I've got a spectrum here. And basically, it's a lot of harmonics one next to each other, regularly spaced and all that. So this is a voiced sound. At the bottom, I've got an unvoiced sound. In this case, it's the sound S. So what it looks like both in time and frequency, just noise. It's basically white noise. So in most speech codecs actually use this model to improve the coding of speech, which is also why it never really works for music if you're trying coding with speaks or other voice codecs. So this here is what the speaks decoder looks like. Basically, you receive some bits. The bits will select some sequences in what is called a fixed codebook. If you receive the 00, you will have this sequence of signal. If you have 01, you'll have this one. 11, you'll have this one, for example. Then you have another codebook, which is called an adaptive codebook. Basically, it's based on the past of some kind of memory and the decoder. You transmit an entry in the memory and you have a signal for the adaptive codebook. You apply some games to both the signals you get there. You obtain something called the excitation, which is basically the model of speech. If I say the sound A or E or O, in all cases, I've got at the bottom here, I just have the vocal chords vibrating at certain rates. And the only difference between all the vowels, for example, is the shape of my vocal tract, which is represented as a filter based on an original excitation. So you have the excitation here and I transmit the encoder, transmit the filter. The decoder gets it and applies it to the excitation and you get the final speech there. Now, what the encoder does, it's very similar to the decoder. All of this part here is the same as the decoder. The only thing it does is it has a decoder. It compares with the signal you're trying to encode. And the difference, which is basically the noise, it gets weighted so that some frequencies of the noise will get amplified, some will get dampened so that the encoder will optimize the bits that will go to the fixed codebook, the adaptive codebook, and all the gains. It will optimize so that to reduce the output weighted noise. So here, what it actually looks and sounds like, if you encode a particular sequence of speech, on the in here, I have the green signal is what is transmitted as fixed codebook for a certain, I think this is like an ah sound. So basically, it's pretty much noise. You can't figure anything out of that signal except that it was carefully selected. If you look at the signal above, that one is from the adaptive codebook that is there. So it's the memory, the right memory of the excitation. And by the way, when I said this sounds basically like noise, I have like an audio sample of that. So this is basically what most of the bits in Kelp get allocated to. Then what gets reconstructed there after you sum both contributions for the fixed and adaptive codebook, you get the signal in red, which is quite different from the green one, which would be the ideal if the codec was completely lossless. So it's still quite different because the bitrate is quite low. So what you get here, I'm going to play the sample corresponding to that. So you start hearing that it sounds a bit better. And after you apply the final filter that actually helps discriminate between any of the vowels or basically the shape of the spectrum, you get the last signal. So this is how you can just take noise, filter it, and you get a good speech signal. So that was the end of the technical part. I'll talk more about the actual features of Speaks. These are the basic specs for the codec. In terms of bitrate, you can do narrowband, which is a sample at 8 kilohertz. That's what gets used in all the telephony stuff at the moment. And that can be encoded between about 2 kilobits per second up to 24 kilobits per second. So there is a very wide range of bitrates. Speaks also supports wideband, which has a lot better quality, sampled at 16 kilohertz. And those range from about 4 kilobits per second up to 42 kilobits per second. In terms of latency, latency is quite low. 25 milliseconds for narrowband, 29 milliseconds for wideband. The frames themselves have 20 seconds. And the rest is a bit of look ahead for the processing. Now, some of the features that Speaks have that not all of the other codecs have. The first one is what I call the embedded wideband bitstream. That means that you can take wideband bitstream, you strip the last few bits, you give it to the narrowband decoder, and it will decode. You take a narrowband stream, you give it to the wideband decoder, it will still decode it. Of course, you won't have the higher frequencies, but you don't need to transcode or anything like that, which is very useful. It can also do variable bitrate. If what you're concerned is just maximizing quality with on average a certain bitrate, you can do that. In voiceover IP, most of the time it's not that useful unless you have a lot of calls that go through the same path. So you can also do average bitrate, set what target bitrate you want, and it will adjust the quality. And it also has voice activity detection and supports this continuous transmission, which means if there's silence, it can just stop transmitting at all, and the decoder will generate the background noise so that you think the communication is still alive, and when the talker starts again, then the packets start flowing again. These are some tips if you want to have speak support in your application. The first thing you need to do if you want to support speaks or have any codec in general, is to figure out what your requirements are. That means mainly the quality versus bitrate tradeoff. You want really high quality, and you're prepared to have a higher bitrate, or is the channel capable of only 10 kilobits per second, so the bitrate has to be less than that, so you need to figure that one out first. My advice is to start from sample code that can already do encoding and decoding of speaks. The speaks manual has sample encoders and decoders which are rather simple to understand. If you're interested in the files, there's the reference encoder and decoder that put everything in AUG the right way, so it's a lot better to start from there instead of just writing code and then figure out why it doesn't work. Then one very important thing is to make sure that the actually send speaks the right input. That means sending the right format and the right sample rate and the right block size of the API expects. I've seen so many people sending new law to speaks, whereas it requires linear 16-bit samples, and then wondering why is the sound really crap? That explains most of the problems using speaks. Another thing that happens sometimes is some cheap sound cards sometimes have a DC offset, which means that the values aren't centered at zero, but for example, centered at some pretty high value. This is something that most speech cortex don't like and it tends to perform rather poorly. Of course, also a good thing to do is to use the right gains for the signals, not having some clipping on the input because then the output will have clipping too, not having the input so small that the noise is fairly high and the input at the beginning. Very important, just listen to what's going on. Sometimes I've had messages on the mailing list. I encode this and when I decode it, it's crap, and then I ask, well, how's the input? And they say, well, I don't know, I haven't listened to it. So this tends to be important. If you're sending crap, this is what you're gonna get at the output. So listen to the input, listen to the decoded. Use the speaks-enc, speaks-deck encoders and decoder, compare with that. If you're getting something different from the same bit rate, then most likely you did something wrong. And the last bit is to, when you're doing voice over IP, it's very important that the decoder that you call the right function and speak to handle packet loss because if you lose packets, it's fine, speaks can handle it, as long as you tell it that you lost a packet instead of just putting zeros. So that's something important. So I've got some speech samples here to give you an idea of what the quality is like. So just before that, so these samples are for narrowband. At eight kilohertz, what I recommend as the bit rates you should use is mainly eight, 11, or 15 kilobits. You could go below or above, but these are the most useful for voice over IP. So here, if I'm gonna play the original file. The navy attacks the bit. 15 kilobits per second, this is what it sounds like. Then at eight kilobits per second, some may notice a slight degradation, but the quality is still quite acceptable and four kilobits per second, you obtain this. So four kilobits, you start hearing quite a bit of noise, but in some cases it's still useful. So in terms of what speaks does compare to other codecs, I have here some MOS cores that aren't, it's not a real MOS test. It was done using the tool called PESQ. And you have here, this is the quality, this is the bit rate. So the idea is to get as close to this corner as possible. In red you have what the reference speaks implementation has. In green it's an experimental version that has slightly better quality. Now if you look at other codecs, all the ones in magenta there, these are the only codecs that you can use. Before speaks, these were the only codecs that you could use in free software. This one here is GSM, which you can see is fairly worse than speaks. The quality is just slightly better than speaks at six kilobits, except the GSM is like 13 kilobits. These are ADPCM codecs. This is G711, which is Mueller A-Law. And now compared to proprietary codecs, it fairs better than this one, which is G728. You've got ILBC there, which is also worse than speaks in most conditions. The only codecs on this side are G729 and AMR and Urban. They're only slightly better, so the idea with speaks was that you're pretty close to that, except that you don't need to pay very expensive royalties for the codec. Now I've got this graph too for the complexity of speaks. Here what I have on this axis is basically how much faster than real time it is, or in other words, how many channels you could do at the same time in really given CPU. So you see that generally the cost goes up or the speed goes down as the bit rate increases, but you can still do around, in the order of the 100 times faster than real time in most of the narrowband modes, which is pretty much enough for most uses, unless you're doing like 200 channels at a time on the same machine, then you need a very powerful one or something like that. Now I'll have some samples for use of speaks for wideband. Wideband means 16 kilohertz sampling rate. You have a lot more frequencies available. So I think wideband is really important for voice over IP, because that's the only way you can actually have better quality than the regular phone service. So instead of saying, well, use voice over IP, the quality is almost as good, but it's cheaper and stuff, you can say like, actually, not only it's cheaper, but I can have a lot better quality. So I think things should be moving there. The bit rate is a bit higher, but it's still not that expensive if you consider that just sending the IP packets over with RTP in it and UDP, the overhead is already 16 kilobits per second. So you might as well transmit good quality audio with that. So with speaks, the narrowband and wideband are compatible. So if one side doesn't support wideband, it's easy to convert between the two. And with speaks, the bit rates that I recommend for wideband are the ones that are between 12.8 kilobits per second up to 27.8 kilobits per second. This is what I generally recommend, although you can go outside of that. So these are the samples that I have. The original is this one. This is an example of speaks, an audio compression codex specifically tuned for the reproduction of human speech. Now, if I code this at 27.8 kilobits per second, this is an example of speaks, an audio compression codex specifically tuned for the reproduction of human speech. So you'll have a hard time hearing the noise at that rate. I've got the 20 kilobits per second. This is an example of speaks, an audio compression codex specifically tuned for the reproduction of human speech. So this is still fairly good quality. If you go down to 12.8, you can start hearing some noise, but it's not too bad. This is an example of speaks, an audio compression codex specifically tuned for the reproduction of human speech. And now I'm gonna play the same thing, but in narrow band at 15 kilobits per second, and you'll see why I say use wide band. An audio compression codex specifically tuned for the reproduction of human speech. This is actually higher bit rate than the one I played just before, yet the quality is not as good because it's only narrow band and about half the spectrum is missing. Now, when I was talking about packet loss, this is just a quick demo to see how important it is. The first sample that I'll play is if you basically don't handle packet loss, you put zeros when you don't receive the packet and then you decode the next packet. This is the result you obtain. This is with 15% packet loss. This is an example of speaks, an audio compression codex specifically tuned for the reproduction of human speech. So this is with zeros and if you actually handle packet loss correctly, just by calling speaks properly, you obtain this instead. This is an example of speaks, an audio compression codex specifically tuned for the reproduction of human speech. So even with 15% packet loss, you can still have quite acceptable quality if you do things properly. So in white band, I have this same graph to compare the two speaks version that I have with what is currently pretty much the only one, the only modern proprietary white band codex which is AMR white band. And you can see that for everything except the very low bit rates, speaks actually fairs pretty well compared to that one and has actually even better quality because you can crank the bit rate up and have pretty much transparent quality for speech. Sorry. Now these are some of the recent development with speaks. So as I said, although the bit stream has been frozen for a while, development is still quite active in terms of adding features. It's even possible to improve the quality in some cases without touching the bit stream at all. Some of the improvements that have happened recently. First one is what I call the pre-processor, something that you can run on the audio before running the encoder. What the pre-processor can do, first thing is noise suppression. If you have some background noise, you run the pre-processor on it and it can, any noise that is constant in time, it can remove most of it so that when you encode, you encode something that doesn't have noise, so obviously the quality is better at the end. It has automatic gain control that you can apply to the signal. It's got an improved voice activity detection algorithm that is more accurate than the one in the main codec. In some cases it's useful. I also have an acoustic echo canceler. That's something you need if you want to have a hands-free phone and not hear yourself as your voice goes out of the speakers at the other end back in the microphone and hear yourself so you can cancel the echo with that. And the last one is that Speaks is being converted to Fixed Point. All the narrowband stuff is converted completely. The wideband stuff has a little more to do but I'll have it in the next slide. Here, so Speaks is made so that just as a compile option, you can make it use only integer arithmetic instead of floating point. That's very useful on embedded devices or anything that doesn't have an FPU. The only assumptions made by the Fixed Point is that you have a 32-bit accumulator and a 16-bit multiplier. So everything goes down to multiplying two 16-bit values to have a 32-bit one and adding to other 32-bit values. That's the only thing that's required. There's no requirement for hardware saturation. Most of the DSPs have hardware saturation but not CPUs like ARM and stuff so Speaks doesn't assume that. And the quality of the Fixed Point version is very close to the one of the floating point version which is the idea. So some things are fully implemented in Fixed Point now. All the constant bitrate modes between six and 18 kilobits per second, yeah? Okay, so the question is what I mean by the quality is close to the float version, whether it's the quality of the encoder, the decoder, and the answer is both. If you do the whole, you encode in Fixed Point, decode in float, do the opposite or basically any combination will have pretty much the same kind of quality. And obviously the bitstream is the same. And even the API and the ABI of the libraries are the same. You can just substitute a shared library compiled for Fixed Point or Floating Point and it works exactly the same. Yeah, so the ones that are fully implemented in Fixed Point, between six and 18 kilobits in narrowband that's fully converted, the echo canceler has very recently been converted to Fixed Point. Some parts are only partially implemented. That means most operations are converted to Fixed Point but there are still a few float operations left that need to be emulated and in most cases, there's so few that it still can run in real time. So all the other narrowband bitrates that aren't fully implemented are almost complete so you can still use them on an ARM chip, for example. The wideband is almost completed and the only one that's really not implemented in Fixed Point at all is the preprocessor so far so you can't have the noise suppression running on an ARM chip. Now in terms of Speaks in the embedded world, it's been mainly working on three architectures that I know of. There might be other ones that can use it. So the first one is the ARM architecture. Speaks has actually some assembly optimizations for both the V4 and V5e architectures. So it can run pretty fast in the ARM chips and it can be used, I've used it before with Linux and GCC. Another embedded chip is the analog devices Blackfin DSP. That one also has assembly optimizations for it. The interesting thing about it is it has a completely free development kit that goes with it. You can buy very cheaply development board that's actually released. The schematics of the board is actually GPL and you can run new su-linux on it with GCC. Linfone has been ported to it so you have a complete voice-over IP kit for that chip. So this is the URL where you can get all the information and even buy the board which is called a stamp board. So the last DSP is the Texas Instruments C54, C55 and C6000. Speaks is known to work on these chips although I've never tested it. Unfortunately also there's no free operating system or development tools that I know of that work for these chips. The question is, is it that DSP that's used in the latest Nokia 7 something? I think if I understood correctly that the chip, yeah, okay, good. I think that device actually has an ARM plus Texas C5, sorry, so just to repeat it's a dual core ARM plus C55. So Speaks would definitely run on that. It could run on either the ARM part or the C55. The C54 is actually not recommended for now because the standard TI compiler tends to generate stupid things like calling functions for every multiplication which is probably not what you want and it tends to run really slow on that. So until that is sort of fixed it's not really recommended. Now where this is going at the moment, what's currently in progress is there is a Speaks over RTP draft of the ITF. So we're pushing that one in standardizing Speaks for using RTP, SIP and all that. The porting to fixed point is still ongoing and will continue until everything has been converted to fixed point. And you saw some curves with Speaks in red and green. The green one was actually Speaks using the Vorbis Placoacoustic model to shape noise better than what it does by default. So it's not cheap, it's more computationally intensive but you can get better quality with that and it's still ongoing that I'm trying to increase the quality using that. Now some possible improvements that could be done in case there's any volunteer that wants to do some Speaks stuff. One thing that can be done is there's still quite a bit of tuning that's possible. A lot of things that could be improved by just tweaking a few values to optimize some things. There's also a possibility for those who know some signal processing to improve the voiceover activity detection, the variable bit rate code, perceptual enhancement and all that can still be improved without again changing the bit stream. Also in the future and that's not related to Speaks directly but we've got a project that's infancy that ideally we'd like to have the very high quality real time audio codec that would fill in the gaps between Vorbis and Speaks. The reason being that Vorbis has fairly high quality but fairly high latency, Speaks has low latency but the quality isn't as good as Vorbis for example, for music and things like that, Vorbis has much better quality so the idea would be to combine both together. So this is some other things we're going to be working on in the future years. And in conclusion, so this is why you really should use Speaks if you're not already using it in voiceover IP. First reason is open source, I don't think, or free software, I don't think I need to convince anyone here that it's a good thing. Basically it means no cost, you don't get locked in with the vendor from some codec because it's open source, the codec is still evolving and it will get better. And it's also the only way, even if you have a proprietary voiceover IP application, if you wanna be compatible with free software applications you need to be able to understand free codecs because obviously free software can't use proprietary codecs. Another good reason is Speaks can do a lot of things and a lot more things than most of the proprietary codecs. It's one of the few codecs that can actually do narrowband and wideband, unlike most codecs that do narrowband at this bit rate and if you want another bit rate you need to get another codec and that gets complicated. So Speaks does pretty much everything. It covers a very wide range of bit rate between two kilobits per second to 44 kilobits per second. This is more than any speech codec than I know of by a wide margin. It's very flexible, you can tweak a lot of things with the library, you can even tell it if you want to optimize for CPU time or optimize for quality and things like that. There's a lot of things you can change. And it's basically easy to use. The LibSpeaks library has a clean and simple API and of course there's some community support. If you have questions you can ask on the mailing list. There's also an RSC channel, HashSpeaks and the website which is sort of below the screen, 3w.speaks.org and that concludes my talk. These are some of the software that supports Speaks right now only have free software there. There are more, I'm sorry, for all of the ones that I forgot in this list. So is there any question? Yes? So the question is what's the adoption for SIP phone manufacturers? In terms of support, in soft phones a lot, most of the free soft phones supported at the moment. In terms of hard phones, I'm not aware of phones that support it now. Although I think it is coming now, the fixed point part is relatively recent and ever since it happens I see a lot of, there's been a lot of activity on the mailing list about people implementing Speaks on all kinds of DSPs. I don't know all the companies they're working for but I would expect to see several hard phones coming in in the near future. Yes? I'm sorry, can you repeat again, I can't hear? The question is if I'm trying to standardize the RTP profile for Speaks? Yeah, there's currently a draft of the IETF for specifying how to use Speaks on RTP. I'm sorry. Oh okay, there isn't that much that happened recently, mostly because of lack of time and my lack of knowledge of RTP in general. If anyone would like to help on that one, I'm really open to changing stuff. It hasn't changed much and I wouldn't expect it to change all that much until it becomes an RFC by the way. But if you have any comments or you wanna help, I'm definitely open to that. Yes? The line is RTP, can't set the V. Okay, so the question is basically what's the difference between acoustic echo canceler and a line echo canceler and can we use the Speaks echo canceler for line echo cancelation? And basically the main difference is that acoustic echo cancelation is a much harder problem and the filter length is usually longer. So even though I haven't really tested it, the acoustic echo canceler in Speaks can most likely be used to cancel line echo. It's just simpler. The algorithm that I'm using in Speaks is different than the NLMS algorithm which is usually used for line echo. The one I have in Speaks is usually faster. The only, the main difference, for example, we're trying to, I'm trying to work with Mark Spencer to use the Speaks echo canceler and asterisk to cancel line echo. The main thing that needs to be solved at the moment is the fact that the Speaks echo canceler works on blocks. Usually it expects like a 10 millisecond or 20 millisecond block, cancel the echo for that block. It doesn't work on a sample by sample basis. That's the main difference. Any other question? Yes? How speak, the question is how Speaks compares to the codec used in Skype. I'm not that familiar with Skype. I think it uses ILBC and ISAC. The ILBC is the narrowband codec which I have in this slide. Yeah, I think they're using both anyway. So the narrowband version is the one in Sion here, ILBC. So Speaks is actually better for the same kind of bitrate. The wideband one is ISAC. I'm not familiar with it. I couldn't find it when doing my wideband comparisons. But I would expect, does anyone know what bitrate it's using? The wideband one, okay. But I would expect Speaks to fare pretty well compared to that one too. Considering that it already goes pretty well against AMR wideband, but I don't have exact comparisons. The question is, if it's possible to, I'm not sure I understood the question anyway. If Asterix support, oh okay. If I know what, yeah. So the question is transcoding from G711 MULA to Speaks. I haven't done any formal testing with that, but I would assume you would get roughly the same quality as these here, which are from linear 16 bit. MULA has a slight degradation, but I don't think it's that major. Probably in the same kind of degradation that you have for other codecs when you transcode from MULA. Any other question? Thanks very much.