Im trying to do voice-over UDP for a multiplayer game.
I’ve created a sample and using FSOUND_Record_StartSample() to begin recording when the user speaks with the speak key, now all I need to do is grab the sound data as the user is speaking which then I will pack into a UDP packet and send it over the network where it will be reassembled and pushed into a playback buffer.
Can someone tell me if its possible to grab the data from the sample as its recording and how?
- MeshMan asked 12 years ago
Thats exactly what I was thinking too but just needed a second opinion
I’ll go have fun setting all the buffers up dynamically now, no doubt it will take me a while to learn with the help of the samples of course.
Thanks for your help again Brett.
My question remains unaswered. I’m asking for specifics of how to dynamically create a sound buffer and read from it at the same time. Is it possible and if so, with what functions? I’m worried about the overlap on a forever looping buffer and how often should I take a sample snapshot etc…
Recording into a looping buffer is the only way, I believe, to record continuously in FMod. Take a look at the sample program entitled ‘record’ for how to do this.
The size of the looping buffer should not be a problem for what you’re doing, since you will want to grab data as often as possible anyhow. If you’re very concerned about looping over, make the buffer longer – 1 second or more if your program really needs it. Spending an extra hundred K of memory is not a huge deal.
I’m wondering about how I should record / send / and play. Not coding wise, but theory. For example, do I wait until I get 1 second of recorded voice then begin sending the data and play it at exactly the same rate I’m recording it at?
Thanks for your response.
I’ve never done this sort of thing over the network in real-time. However, I imagine you’d want to sample and send data moderately often. The more often you send samples, the less of an impact any delays or lost packets (you’re using UDP so success is not guaranteed) would have. On the other hand, if you send too tiny an amount of data, the packet header will become an undesirable overhead.
Unless your requirement for real-time is very strict, I would introduce a playback delay of 200-800ms on the receiving end. Set up a little buffer of somewhere around that size, so if some network packets arrive late you’ll still have something to play back in the meantime.
A lot of systems I’ve seen will cut off audio entirely if there is not enough in the buffer. One interesting feature might be to adjust the frequency instead, so you can make the existing data play back slower while waiting for more to arrive.
You will probably want to implement some form of compression in between the sample and the UDP packet, since raw data is too big to send over most networks.
Please login first to submit.