-1

I'm creating a VoIP softphone written in Java, and currently I have the G.711 codec implemented (all through Java, no native code).

I want to expand the codecs available, though everywhere I look, such as with projects like Jitsi, instead of writing the algorithm in Java, it's written in C and JNI is used to call it. I know very little about C and nothing about JNI, so I'm not too anxious to have to learn them. Additionally, I like the idea of a pure Java implementation that doesn't rely on native code to run.

My question is this: I'm sure there's a very good reason I haven't been able to find a Java implementation, but I don't know enough about the codecs to know what that reason is. So, how come there aren't any Java implementations of G.722 when another codec like G.711 works so well?

Additionally, if native code is the only way to go, where would be a good place to start? I've tried translating the G.722.c code from ITU-T into Java, but I stopped after a bit of a headache (also since my G.711 translation was working). I've looked into Xuggle, but building the project is a nightmare and I can't use the GPL version (also no handy Javadoc).

FFMpeg looks promising for all the codecs it offers, but I'm not sure about writing my own JNI wrapper, and the ones I've looked at have either been difficult to implement (Xuggle) or seem to be out of date (FMJ).

Bottom line: I'd like to implement new codecs, but I'd like to pick and choose which ones. I don't need an entire AV library when I only want to have 2 or 3 audio codecs. Small footprint, and as pure Java as it can get.

hotforfeature
  • 2,468
  • 1
  • 13
  • 24

2 Answers2

0

I've done it with GSM (very small footprint) pure java implementation on an IAX softphone, are you implementing SIP? is open source? is based on any known implementation (for ex. peers?)

best regards

scgm11
  • 1
  • I got a lot of inspiration from peers and it's using JAIN-SIP (gov.nist reference implementation). However, it is not open source, which is why I've got to be careful with what libraries to use. More often, it's easier for me to write it myself than deal with licensing – hotforfeature Aug 09 '13 at 02:25
  • I've been trying for some time in my spare time to make a really usefull voip phone, I tried peers for example and the delay on the call make its difficult to use, I also tried Asterisk-Java-Iax as it was on the project doensn't work I have a working version with GSM and g711 support working but has some bugs that makes it unstable for production... haven't retake the work cause I wasn't able to fix some of these bugs, if interested in check this let me know – scgm11 Aug 09 '13 at 13:15
0

Codecs tend to be performance critical and have real-time requirements - both of which are more difficult to achieve in a virtual machine based runtime.

When implemented natively, a codec is able to take advantage of CPU-specific hardware acceleration which a general purpose VM cannot. Obvious examples being the use of SIMD instructions for implementing filters and FFTs, and instructions specifically designed for accelerating bit-stream handling (e.g. locating first 1 or 0 bit in a register).

This is a really big deal on ARMv7 CPUs used in most tablets and mobile phones where there's a huge difference in performance between the performance of the FPU and NEON (SIMD) units for floating point operations.

marko
  • 8,640
  • 4
  • 28
  • 43
  • Ok, so that's the big pitch on why to use native code instead of the JVM. For Java, that's probably going to be using JNI. So should I go back to trying to make Xuggle work, or are there some other audio codec libraries that are more active? – hotforfeature Aug 09 '13 at 02:22