It encoded those 3.75 seconds in 0.06 seconds and decoded in 0.04 seconds on my AMD Phenom 9750 2.4 GHz, one core only, compiled with GCC and the -O3 switch. That's all of the overhead of the program starting and exiting, too. It's using floating, not fixed point.
This, it seems, bodes well for low latency of the final implementation on a DSP chip.
The repeater can rebroadcast the data, but that data would be AMBE encoded, and AMBE is both trade-secret in its implementation and patented in some of its algorithms. There may be an AMBE chip in the repeater, I've not played with one. The usual way one converts to and from AMBE on a PC is with a device called the DV-Dongle, which contains the AMBE chip. This costs lots of money and is not nearly so powerful as the CPU of the computer it's plugged into, which is one reason to be fed up with proprietary codecs.
So, if you had some newer, Codec2-based radios, and some older D-STAR radios, linking repeaters might be a good way to get them to talk to each other.
This is hand-waving about a lot of issues, like we've not designed the next generation of data radio to put Codec2 into. One might guess that such a thing could use IPV6, and better modulation than just FM, and FEC, etc.
I think you could cut the sample rate in half and get acceptable performance, but I've not tried. Currently I think it's 25 microsecond frames, and each frame has one set of LSPs and two sets of voicing information so it's interpolated into 12.5 microsecond frames. Those lower bandwidth codecs do 50 microsecond frames. Go forth and hack upon it if you'd like to see. Also, there are some optimizations that are obvious to David and Jean-Marc (and which I barely understand) that haven't been added yet. One is that the LSPs are monotonic and nothing has been done to remove that redundancy. Delta coding or vector quantization might be ways to do that. I understand delta coding but would not be the one to do VQ. Another is that there is a lot of correlation of the LSPs between adjacent frames, so you don't necessarily have to send the entire LSP set every frame. And there is probably lots of other opportunity for compression that I have no concept of.
Congratulations on the license, OM. We haven't yet explored how to wedge this into D-STAR, but sending it as data rather than voice would be one way. All of the D-STAR radios except the latest one, the IC-92AD, use a plug-in daughter board to hold the AMBE chip, and it might be that somebody could make a dual-chip version of this board sometime. Since AMBE is proprietary we are stuck using their chip if we want to be compatible, unless the repeater does the conversion for us using a DV-Dongle. They sell TI DSP chips with their program burned in, and don't give out the algorithm.
It may be that on D-STAR the AMBE chip also does the modulation for a data transmission, just doesn't run the codec. But the modulation is known and there is a sound-card software implementation of D-STAR that interoperates with it. I don't have any D-STAR equipment to test. The folks on dstar_development@yahoogroups.com know a lot more about D-STAR.
Jean-Marc Valin is on the project mailing list and David is another Speex developer and the person Jean-Marc recommended to me. We are trying for an improvement over Speex at low rates.
Right. Sorry. Real time on the x86 workstation I'm using. Not converted to fixed-point for weaker CPUs yet. Not tested on ARM, Blackfin, AVR, etc. Waiting for you to do that:-) Downloadable code. Reasonably portable. Type make and let fly.
It is a real-time codec on my workstation and is intended to be a real-time codec on embedded DSP. It's currently all floating point and does things it should not like malloc of multiple buffers per sample
Download the code and build it. It's "just type make" on Linux. The raw (uncompressed) sample format we've used for testing is 16-bit samples at 8 KHz and there are some tools to play those, and some pre-recorded samples. Not too much trouble to figure out.
The original rationale for Codec2 is at Codec2.org. I've been promoting this issue for about four years, as I was bothered by the proprietary nature of the AMBE codec in D-STAR. But I didn't have the math, etc., to do the work myself. It was really fortunate that David became motivated to do the work without charge. He has a Ph.D. in voice coding. By the way, look over his web site rowetel.com for the other work he's done: two really nice Open Hardware projects - a PBX and a mesh telephony device, an Open Source echo canceler for digital telephony, used in Asterisk and elsewhere, and his own electric car conversion. He'd be my nomination for the MacArthur grant.
I'll be presenting on Codec2 at the ARRL/TAPR Digital Communications Conference this weekend in Vancouver Washington, Near Portland. I'll try to get the video online.
You have perfect freedom to create new works of content which can operate under the economic paradigm you prefer, as do all artists. The fact is, only a minority are currently engaged in creating content that they place under an attribution, share-alike license. If we held a vote on how the overall paradigm should operate, today, unfortunately the share-alike folks would lose.
We're doing better with software, but not perfect.
I paid for my home with my share of Pixar's IPO. And I'm an Open Source evangelist. So, I'm in both worlds where this is concerned.
What I think is fair is for infringing redistribution of copyrighted content to be prosecuted as necessary. You really don't have the right to give all of the internet a copy of that Hannah Montana song. But when I have paid or done whatever is appropriate to gain the right to view that media on my LG TV, I should have the right to view it on my Linux system too.
So, basically I am for content creators having the right to monetize their work and against having an electronic cop in my TV room. And I'm against having Free Software locked out of being a player.
I hope the key is real and that it's really this simple. I am not equipped to test it today but I'm sure someone here is.
Codec2 is a digital voice codec for ham radio and potentially all low-bandwidth voice communication. Currently it fits in 2550 bits per second, and we expect it to get narrower. See the Alpha Release Code.
Boffins did not decide this. It is a consequence of the evolution of human speech, both vocalization and hearing. The part of our speech that encodes content is the part that telephones have been engineered to convey. It's actually less than the 300-3400 Hz band, there's a mostly-useless band segment between the low frequencies and the higher ones that can be left out without much effect on speech recognition.
There have been a number of "hi-fi" schemes for telephony and bandwidth-limited radio. Some add bass, which is really cheap to do in terms of bandwidth because there is only a narrow band to be added and there's not much real information there at all so that you can compress the heck out of it and it still sounds like speech. AMBE+ does this on two-way radio, with a rather irritating synthetic bass. The other is to add more highs, and then you are going to mostly get more sibilants.
It is going to end up working better on the music-on-hold than it will on real voice.
Thanks for the kind words. What I find in general is that those who feel this is simply a matter of doctrinal rigidity are only interested in solving today's problem, without much vision toward what their lot might be tomorrow. Working to improve your own future is hardly zealotry.
Obviously it makes sense to decrease the degree to which we must be supplicants of a hardware vendor. That's even more true when the hardware vendor is in an essentially unchallenged duopoly. A vendor is working in our interest when they help us to free ourselves from the need to go to them to fix bugs, add functionality, and support our devices through software and hardware changes. When a vendor doesn't do this, we live constantly under the threat of withdrawl of support.
Rewarding vendors who do less will make it more certain that we'll get less in the future.
Mark Hurd's silly exit has little to do with HP's real problems. As an executive there about a decade ago, I saw a company that was giving up its differentiating value in the name of operational savings, not realizing that by now the Golden Goose of creativity would find greener pastures. But surprisingly, the classic HP tradition of building a great place to do engineering that results in a flood of excellent creative products is being followed...
Peer-to-patent is only useful when the patent applicant is participating in the process. Most patent applicants are not interested in having the community bust their patent, and don't participate. And if the patent applicant does participate, we end up in a situation where the community folks work to make the patent stronger, which isn't necessarily a good thing either.
Slashdot Mirror
Sound-card modem implementations over SSB would be practical. See FDMDV. We're still a little wide for that, but we'll get there.
It encoded those 3.75 seconds in 0.06 seconds and decoded in 0.04 seconds on my AMD Phenom 9750 2.4 GHz, one core only, compiled with GCC and the -O3 switch. That's all of the overhead of the program starting and exiting, too. It's using floating, not fixed point.
This, it seems, bodes well for low latency of the final implementation on a DSP chip.
The repeater can rebroadcast the data, but that data would be AMBE encoded, and AMBE is both trade-secret in its implementation and patented in some of its algorithms. There may be an AMBE chip in the repeater, I've not played with one. The usual way one converts to and from AMBE on a PC is with a device called the DV-Dongle, which contains the AMBE chip. This costs lots of money and is not nearly so powerful as the CPU of the computer it's plugged into, which is one reason to be fed up with proprietary codecs.
So, if you had some newer, Codec2-based radios, and some older D-STAR radios, linking repeaters might be a good way to get them to talk to each other.
This is hand-waving about a lot of issues, like we've not designed the next generation of data radio to put Codec2 into. One might guess that such a thing could use IPV6, and better modulation than just FM, and FEC, etc.
I think you could cut the sample rate in half and get acceptable performance, but I've not tried. Currently I think it's 25 microsecond frames, and each frame has one set of LSPs and two sets of voicing information so it's interpolated into 12.5 microsecond frames. Those lower bandwidth codecs do 50 microsecond frames. Go forth and hack upon it if you'd like to see. Also, there are some optimizations that are obvious to David and Jean-Marc (and which I barely understand) that haven't been added yet. One is that the LSPs are monotonic and nothing has been done to remove that redundancy. Delta coding or vector quantization might be ways to do that. I understand delta coding but would not be the one to do VQ. Another is that there is a lot of correlation of the LSPs between adjacent frames, so you don't necessarily have to send the entire LSP set every frame. And there is probably lots of other opportunity for compression that I have no concept of.
Congratulations on the license, OM. We haven't yet explored how to wedge this into D-STAR, but sending it as data rather than voice would be one way. All of the D-STAR radios except the latest one, the IC-92AD, use a plug-in daughter board to hold the AMBE chip, and it might be that somebody could make a dual-chip version of this board sometime. Since AMBE is proprietary we are stuck using their chip if we want to be compatible, unless the repeater does the conversion for us using a DV-Dongle. They sell TI DSP chips with their program burned in, and don't give out the algorithm.
It may be that on D-STAR the AMBE chip also does the modulation for a data transmission, just doesn't run the codec. But the modulation is known and there is a sound-card software implementation of D-STAR that interoperates with it. I don't have any D-STAR equipment to test. The folks on dstar_development@yahoogroups.com know a lot more about D-STAR.
73
K6BP
Jean-Marc Valin is on the project mailing list and David is another Speex developer and the person Jean-Marc recommended to me. We are trying for an improvement over Speex at low rates.
I am bringing the materials for a demo table with two laptops and real-time encode-decode, so people can try it themselves.
Right. Sorry. Real time on the x86 workstation I'm using. Not converted to fixed-point for weaker CPUs yet. Not tested on ARM, Blackfin, AVR, etc. Waiting for you to do that :-) Downloadable code. Reasonably portable. Type make and let fly.
It is a real-time codec on my workstation and is intended to be a real-time codec on embedded DSP. It's currently all floating point and does things it should not like malloc of multiple buffers per sample
Download the code and build it. It's "just type make" on Linux. The raw (uncompressed) sample format we've used for testing is 16-bit samples at 8 KHz and there are some tools to play those, and some pre-recorded samples. Not too much trouble to figure out.
The original rationale for Codec2 is at Codec2.org. I've been promoting this issue for about four years, as I was bothered by the proprietary nature of the AMBE codec in D-STAR. But I didn't have the math, etc., to do the work myself. It was really fortunate that David became motivated to do the work without charge. He has a Ph.D. in voice coding. By the way, look over his web site rowetel.com for the other work he's done: two really nice Open Hardware projects - a PBX and a mesh telephony device, an Open Source echo canceler for digital telephony, used in Asterisk and elsewhere, and his own electric car conversion. He'd be my nomination for the MacArthur grant.
I'll be presenting on Codec2 at the ARRL/TAPR Digital Communications Conference this weekend in Vancouver Washington, Near Portland. I'll try to get the video online.
I am very sorry that when this Microsoft executive opens something, he faces incompetence. Perhaps he can get a pill from his doctor.
Geez. Someone needs to take a good look at how this article got on the front page.
There's also space, and space has the quality of locality, thus the three important things about real estate: "location, location, location".
You have perfect freedom to create new works of content which can operate under the economic paradigm you prefer, as do all artists. The fact is, only a minority are currently engaged in creating content that they place under an attribution, share-alike license. If we held a vote on how the overall paradigm should operate, today, unfortunately the share-alike folks would lose.
We're doing better with software, but not perfect.
Although ACCS isn't broken this gives you a means to get the cleartext.
I paid for my home with my share of Pixar's IPO. And I'm an Open Source evangelist. So, I'm in both worlds where this is concerned.
What I think is fair is for infringing redistribution of copyrighted content to be prosecuted as necessary. You really don't have the right to give all of the internet a copy of that Hannah Montana song. But when I have paid or done whatever is appropriate to gain the right to view that media on my LG TV, I should have the right to view it on my Linux system too.
So, basically I am for content creators having the right to monetize their work and against having an electronic cop in my TV room. And I'm against having Free Software locked out of being a player.
I hope the key is real and that it's really this simple. I am not equipped to test it today but I'm sure someone here is.
Monetize your content all you want. Prosecute illegal distribution. Just let me play it with my own device and software.
Codec2 is a digital voice codec for ham radio and potentially all low-bandwidth voice communication. Currently it fits in 2550 bits per second, and we expect it to get narrower. See the Alpha Release Code.
Boffins did not decide this. It is a consequence of the evolution of human speech, both vocalization and hearing. The part of our speech that encodes content is the part that telephones have been engineered to convey. It's actually less than the 300-3400 Hz band, there's a mostly-useless band segment between the low frequencies and the higher ones that can be left out without much effect on speech recognition.
There have been a number of "hi-fi" schemes for telephony and bandwidth-limited radio. Some add bass, which is really cheap to do in terms of bandwidth because there is only a narrow band to be added and there's not much real information there at all so that you can compress the heck out of it and it still sounds like speech. AMBE+ does this on two-way radio, with a rather irritating synthetic bass. The other is to add more highs, and then you are going to mostly get more sibilants.
It is going to end up working better on the music-on-hold than it will on real voice.
Why is American Beer like making love in a row-boat?
:-)
Thanks for the kind words. What I find in general is that those who feel this is simply a matter of doctrinal rigidity are only interested in solving today's problem, without much vision toward what their lot might be tomorrow. Working to improve your own future is hardly zealotry.
Obviously it makes sense to decrease the degree to which we must be supplicants of a hardware vendor. That's even more true when the hardware vendor is in an essentially unchallenged duopoly. A vendor is working in our interest when they help us to free ourselves from the need to go to them to fix bugs, add functionality, and support our devices through software and hardware changes. When a vendor doesn't do this, we live constantly under the threat of withdrawl of support.
Rewarding vendors who do less will make it more certain that we'll get less in the future.
This all sounds eminently pragmatic to me.
Go out and buy some. And then help to make the driver rock-solid, if you're capable.
We've got to reward the companies that do this.
Bruce
Mark Hurd's silly exit has little to do with HP's real problems. As an executive there about a decade ago, I saw a company that was giving up its differentiating value in the name of operational savings, not realizing that by now the Golden Goose of creativity would find greener pastures. But surprisingly, the classic HP tradition of building a great place to do engineering that results in a flood of excellent creative products is being followed...
Read the rest of the posting.
Peer-to-patent is only useful when the patent applicant is participating in the process. Most patent applicants are not interested in having the community bust their patent, and don't participate. And if the patent applicant does participate, we end up in a situation where the community folks work to make the patent stronger, which isn't necessarily a good thing either.