VOIP java program slow?

[Sam111]

I am hoping somebody on this forum knows why my program is choppy.
Note I posted the thread on allaboutcircuits forum initially but maybe their are be here that can answer the question.
link is
http://forum.allaboutcircuits.com/showt ... hp?t=28560

I am using udp for transporting so it should be as fast as possible.
Thanks for any help.

[earlz]

are you sure UDP isn't your problem?

audio packets that get out of line or are missing can make things sound choppy.. I would recommend at least trying TCP

[pcmattman]

Have you had a look at your CPU usage while this is running?

Also, I don't suggest using TCP over UDP for audio. It's ok to lose a couple of packets when you're receiving a steady stream of data, but with TCP that means the transmission is paused until that missed packet is received again (choppier than ever!).

[Brendan]

Hi,

Also, I don't suggest using TCP over UDP for audio. It's ok to lose a couple of packets when you're receiving a steady stream of data, but with TCP that means the transmission is paused until that missed packet is received again (choppier than ever!).

The main problem with UDP is that packets can arrive in a different order, so (unless the receiver is sending an "ACK" for each received packet, which would be insanely slow) the receiver needs to sort them.

With either TCP or UDP I'd expect the receiver to maintain a large enough buffer so that short pauses in the incoming data can be tolerated (which would also make it easier to sort the packets for UDP). Of course if a "future" packet gets lost, you should have plenty of time before that packet is heard to get it re-sent (and avoid the audible glitch). You'd also want flow control - e.g. when the buffer is close to becoming full the receiver would send a "slow down" packet to the server, and when the buffer is close to becoming empty the receiver would send a "go faster" packet to the server.

It does depend on what it's being used for though. For something like "internet radio" the receiver can have a huge buffer and be able to tolerate very long pauses in the incoming data (and unreliable networking). For something like "teamspeak" you'd need to keep the buffer small (nobody wants a 5 second delay before what they've said is heard) so you're going to require fast (low latency, rather than high bandwidth) networking (and you probably won't be able to tolerate much more than about 200 ms of pause).

Of course the original poster is probably testing this where the sender and receiver are on the same computer (or maybe on the same LAN) so I doubt that network latency (or out-of-order packets) is the problem. I'd assume that the problem is that no buffering is done at all, and that both the sender and the receiver are getting their butts kicked by the OS's scheduler and I/O (using high priority tasks with asynchronous I/O wouldn't hurt).


Cheers,

Brendan

[quok]

I'd say the entire problem here is that the OP is using Java

[earlz]

I'd say the entire problem here is that the OP is using Java

very likely.. the OP needs to look at his CPU usage.. if it's 100%, you either need to make algorithms more efficient and such(if possible) and if everything is about as efficient as possible, then Java simply is not fast enough to do realtime things like this... (Java seriously? why did you choose this language at all for such a thing?)

[quok]

I'd say the entire problem here is that the OP is using Java

very likely.. the OP needs to look at his CPU usage.. if it's 100%, you either need to make algorithms more efficient and such(if possible) and if everything is about as efficient as possible, then Java simply is not fast enough to do realtime things like this... (Java seriously? why did you choose this language at all for such a thing?)

Really, it should be doable in java. I just have a (probably not well justified) dislike of the language. But that's a story for another time.

The OP isn't using any algorithms at all, which is the ENTIRE problem. VOIP and any other kind of streaming audio are always compressed, encoded, and even buffered. There is none of that here. The code the OP linked to is capturing audio via the mic and then sending it raw via UDP, where he tries to play it back with zero buffering. Without making use of any algorithms at all, it's quite premature to lay the blame on java itself as the reason this isn't working.

When I said "the problem is you used java", I was really trying to say "Go back and look at your code, it's entirely incorrect for what you want to accomplish."

[earlz]

I'd say the entire problem here is that the OP is using Java

very likely.. the OP needs to look at his CPU usage.. if it's 100%, you either need to make algorithms more efficient and such(if possible) and if everything is about as efficient as possible, then Java simply is not fast enough to do realtime things like this... (Java seriously? why did you choose this language at all for such a thing?)

Really, it should be doable in java. I just have a (probably not well justified) dislike of the language. But that's a story for another time.

The OP isn't using any algorithms at all, which is the ENTIRE problem. VOIP and any other kind of streaming audio are always compressed, encoded, and even buffered. There is none of that here. The code the OP linked to is capturing audio via the mic and then sending it raw via UDP, where he tries to play it back with zero buffering. Without making use of any algorithms at all, it's quite premature to lay the blame on java itself as the reason this isn't working.

When I said "the problem is you used java", I was really trying to say "Go back and look at your code, it's entirely incorrect for what you want to accomplish."

ah.. well I still don't like the language lol..

If he was doing this with a local loopback though, there really shouldn't have been any problem with it being uncompressed.. unless the network interface drivers add that much latency

Code: Select all

[earlz@EarlzBeta-~] $ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.043 ms

which I very highly doubt .043ms is a noticable lag for audio..

his code is wrong, but it should work in this special local loopback case..

[Solar]

The OP isn't using any algorithms at all, which is the ENTIRE problem. VOIP and any other kind of streaming audio are always compressed, encoded, and even buffered. There is none of that here. The code the OP linked to is capturing audio via the mic and then sending it raw via UDP, where he tries to play it back with zero buffering.

Funny enough, that's about what I pictured when I read the header.