3

I have a server that passes the client PCM or ADPCM data.

I initially decided to use PCM because I did not want to deal with encoding and decoding.

I got PCM to work however between each chunk of audio I heard glitches.(Sort of like clipping)

So I thought maybe the reason is latency/high quality audio and all that stuff.

So I decided to use ADPCM to reduce the data amount. I wrote a adpcm to pcm decoder in javascript. It was a hassle. I was hoping that since the data count reduced maybe that would stop the glitches(data would catch up with what is being played)

But I was wrong. I still get the glitches.

Can this even be done with TCP ? Or is it a lost cause. I dont have UDP over websockets.

Do I need to implement a buffering algorithm ? I don't want to do this as it is real time audio and i just want to process it as fast as I can.

Do you guys know a good link to read about real time audio over the web.

I can give code example but this is a high level question.

PS: I tried to use tabs but we get a buffering issue and we cant control it. I also dont get any flow control from the server. It does not say that Audio starter or audio stopped our paused. It is a push protocol and All I get is ADPCM and PCM data

Evren Bingøl
  • 1,306
  • 1
  • 20
  • 32

1 Answers1

1

Yes, of course you can use TCP. UDP is often used in telephony applications as the lower overhead makes everything faster, and for this application it doesn't matter if packets are dropped or arrive in the wrong order. But since UDP isn't an option, you can use TCP.

As you have suspected, it seems to me that your problem is buffer underruns. Either your connection to the server is not fast enough (or at least consistently fast enough), or you are not providing data from the encoder at a fast enough rate. This can happen if you are recording data in real time, and trying to play it back in real time.

A solution is to buffer data server-side before sending it to the client. Have as large of buffer as your latency requirements allow. For internet radio purposes, I usually pick a 30-second buffer, as latency doesn't matter. For your purposes, you will probably want a buffer of at least 64KB. This is the maximum size allowed in a TCP packet. This packet will get fragmented along the way, but that is okay.

You might also look into how your server is sending data. Experiment with disabling the Nagle algorithm so that your server isn't waiting for ACKs before sending more data.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • Thank I am gonna take a look at it tomorrow. But what i tired is, I tried the cache the data client side. – Evren Bingøl Jun 17 '13 at 05:45
  • N number of seconds, i don't remember what it was. But it was 30 chunks (22050,16bit cpm), I had to convert it to 32 bit floats(that is what Web audio api take) I am going to do all that math on the server side and see how that works). http://stackoverflow.com/questions/6593738/audio-data-streaming-in-html5/6955769#6955769 Some think like that, but I still get the click at every sample. But I am going to try what you said anyway, because Right now I use web sockets and it is just pushing the data, But I also need to implement this system for http (with out missing any audio samples) – Evren Bingøl Jun 17 '13 at 05:51