We convinced you that software patents are a problem. How did we do that? We presented evidence, and political discussion, and stories told by the people whose businesses were injured, etc.
Some of us understand how to tell that story to people who aren't in Slashdot's demographics. I could do it, if I had the support to do so, and Red Hat could do it with any number of evangelists other than me. But this is not something I can do out of my pocket.
The difference between these folks and Red Hat is that their business is not based on Open Source software entirely. Red Hat's is. And thus, I think there is little doubt that Red Hat should do what is right for Open Source. That said, I wish those folks would help us too.
Well, they're the guys making the money. That's the main reason why.
Much as Red Hat has sponsored employees who make copious code contributions, they are not by any means more than a fractional developer of the system they vend. Even in the case of the kernel, one of the projects in which they participate most, they are only about a 15% contributor (11.8% for 2.6.35, similar numbers for each kernel version). It is very clear that Red Hat mostly benefits from outside developers.
The community, unfortunately, would find it a lot harder to fund the lobbies and publicity efforts that Red Hat could handle without trouble with a portion of the money it makes from the community's work.
Red Hat, as the copyright holder, is not held to the license terms regarding their own software. If they are not the copyright holder of a substantial part of jBoss, another copyright holder could sue them.
One would think that a feature of a commercial jBoss license is indemnification. Users under the Open Source license are on their own.
Connect this with Red Hat's recent statement to the U.S. Patent Office telling them to stop granting software patents, although the result in the Bilski case gives them no reason to do so.
Red Hat lost. They caved and paid for their own license, and everybody else has to negotiate separately.
It was obvious that if Acacia went after them again, they would not do so in a way that would allow the same outcome as their first case.
The sad thing about this is the way Red Hat has screwed the Open Source developer community. Not with this case, but with their conduct over the past decade. They refused to stick their neck out by lobbying aggressively for an end to software patenting, both in the industry and with government. Then, there was no sentiment in favor of ending software patenting in the industry when the Bilski case came about, and the court followed the BSA's amicus curae statement extensively while paying little attention to the Free Software / Open Source side.
What Red Hat did was court the biggest patent holders extensively for their business. And they got it in part by not rocking the boat on software patenting. So, they made that money on the backs of the community.
And now it's open season on open source. Thanks, guys.
But given that the case settled, there's little chance those judges had much to do with it. Also, the reputation is that the court is extremely plaintiff-favorable - so it would not simply be that the judges are well versed in patent law. The implication is prejudice.
There is no reason that you can't send a packet for each frame. There isn't any important state, so far, that persists between frames. That's 7 bytes (really 51 bits) 40 times per second. CPU speed doesn't seem to be a problem for latency from what we have seen so far.
One of the fastest ways to ensure its testing and distribution is to use it in Mumble - the low latency voice chat software (with an iPhone client as well).
Mumble is typically used by gaming clans for their chat rooms and it Codec2 would be tested in real-life conditions.
Is there an existing Mumble developer whom we could get interested in this? It might be that we should take some of the Alpha-isms out of the code first.
So far, we've really only compared it to g.729, and it does OK against that. CELT starts at 32 kilobits per second and we're at 2 kilobits, so it's not really for the same application. But I noticed that the Alpha, all-floating-point implementation with some known low-performance code encoded the 3.75 seconds in 0.06 seconds, and decoded them in 0.04, on my 2.4 GHz processor. I would think that a polished implementation could achieve low delay on a DSP chip or some flavors of embedded CPU.
The basic assumptions are based on the mechanics of the vocal tract, and I suspect not high-level enough to differ across languages, but obviously it would be nice to hear from speakers of other languages who test it. We could also use a larger corpus of spoken samples for testing.
There are currently 51 bits in a frame. That is the minimum that you can send, and you'd send 40 of those per second as the codec is presently implemented. A real data radio would add bandwidth for its data encapsulation, but would have to meet the time and bandwidth requirements of the codec payload.
We don't know yet, but I don't see how it could be worse than AMBE in D-STAR, which makes various eructions when faced with large packet loss. I did various sorts of bit-error injection inadvertently while debugging yesterday, and right now you still get comprehensible voice with significant corruption of the LSP data. This, IMO, indicates an opportunity for more compression. Handling the problems of the radio link is more a problem for forward error correction, etc.
Slashdot Mirror
But did you publish? Either paper or code. It's not prior art if it's a trade secret.
We convinced you that software patents are a problem. How did we do that? We presented evidence, and political discussion, and stories told by the people whose businesses were injured, etc.
Some of us understand how to tell that story to people who aren't in Slashdot's demographics. I could do it, if I had the support to do so, and Red Hat could do it with any number of evangelists other than me. But this is not something I can do out of my pocket.
The "popular wisdom" is so confident that we'd fail that nobody with the money to back up the project has tried. This is self-defeating behavior.
The comment by arth1 sheds more light on the prejudice issue.
It didn't seem that formulation was a big deal this time. Do you think otherwise?
The difference between these folks and Red Hat is that their business is not based on Open Source software entirely. Red Hat's is. And thus, I think there is little doubt that Red Hat should do what is right for Open Source. That said, I wish those folks would help us too.
Well, they're the guys making the money. That's the main reason why.
Much as Red Hat has sponsored employees who make copious code contributions, they are not by any means more than a fractional developer of the system they vend. Even in the case of the kernel, one of the projects in which they participate most, they are only about a 15% contributor (11.8% for 2.6.35, similar numbers for each kernel version). It is very clear that Red Hat mostly benefits from outside developers.
The community, unfortunately, would find it a lot harder to fund the lobbies and publicity efforts that Red Hat could handle without trouble with a portion of the money it makes from the community's work.
Red Hat, as the copyright holder, is not held to the license terms regarding their own software. If they are not the copyright holder of a substantial part of jBoss, another copyright holder could sue them.
One would think that a feature of a commercial jBoss license is indemnification. Users under the Open Source license are on their own.
Connect this with Red Hat's recent statement to the U.S. Patent Office telling them to stop granting software patents, although the result in the Bilski case gives them no reason to do so.
Red Hat lost. They caved and paid for their own license, and everybody else has to negotiate separately.
It was obvious that if Acacia went after them again, they would not do so in a way that would allow the same outcome as their first case.
The sad thing about this is the way Red Hat has screwed the Open Source developer community. Not with this case, but with their conduct over the past decade. They refused to stick their neck out by lobbying aggressively for an end to software patenting, both in the industry and with government. Then, there was no sentiment in favor of ending software patenting in the industry when the Bilski case came about, and the court followed the BSA's amicus curae statement extensively while paying little attention to the Free Software / Open Source side.
What Red Hat did was court the biggest patent holders extensively for their business. And they got it in part by not rocking the boat on software patenting. So, they made that money on the backs of the community.
And now it's open season on open source. Thanks, guys.
But given that the case settled, there's little chance those judges had much to do with it. Also, the reputation is that the court is extremely plaintiff-favorable - so it would not simply be that the judges are well versed in patent law. The implication is prejudice.
It amazes me how difficult it is to explain how far 20 light years is. We only see stars because they're big honking lights!
How?
Oops. Thanks!
You still need lots of small packets if you don't want high latency. So this is better but still uses lots of networking.
I think it is 25ms. 51 bit frame 40 times per second. Please read the code.
I hope we get a Mandarin tester. Comprehensible speech with buzzsaw noise etc. is important for emegency services radio and will be tested.
Right. The first is the one used in D-STAR.
The codec work is by David Rowe. I don't know of anyone doing speech recognition.
No significant state between frames so far. 25 miliseconds per frame. That is the minimum delay before the other side starts to hear the audio.
There is no reason that you can't send a packet for each frame. There isn't any important state, so far, that persists between frames. That's 7 bytes (really 51 bits) 40 times per second. CPU speed doesn't seem to be a problem for latency from what we have seen so far.
I have an ip04 on my business phone number, which is a SIP DID.
Is there an existing Mumble developer whom we could get interested in this? It might be that we should take some of the Alpha-isms out of the code first.
So far, we've really only compared it to g.729, and it does OK against that. CELT starts at 32 kilobits per second and we're at 2 kilobits, so it's not really for the same application. But I noticed that the Alpha, all-floating-point implementation with some known low-performance code encoded the 3.75 seconds in 0.06 seconds, and decoded them in 0.04, on my 2.4 GHz processor. I would think that a polished implementation could achieve low delay on a DSP chip or some flavors of embedded CPU.
The basic assumptions are based on the mechanics of the vocal tract, and I suspect not high-level enough to differ across languages, but obviously it would be nice to hear from speakers of other languages who test it. We could also use a larger corpus of spoken samples for testing.
There are currently 51 bits in a frame. That is the minimum that you can send, and you'd send 40 of those per second as the codec is presently implemented. A real data radio would add bandwidth for its data encapsulation, but would have to meet the time and bandwidth requirements of the codec payload.
We don't know yet, but I don't see how it could be worse than AMBE in D-STAR, which makes various eructions when faced with large packet loss. I did various sorts of bit-error injection inadvertently while debugging yesterday, and right now you still get comprehensible voice with significant corruption of the LSP data. This, IMO, indicates an opportunity for more compression. Handling the problems of the radio link is more a problem for forward error correction, etc.