0
0

From an older thread:
[quote:2if0zlof]If you want to push data from outside , you would have to buffer it up yourself in another buffer and let the fmod stream feed from it. [/quote:2if0zlof]

In looking at the UserCreatedSound example, I can see what you’re describing. As the sound is playing, it uses the callback to get data to feed the stream.
In the case of the UserCreatedSound example, the callback [i:2if0zlof]creates[/i:2if0zlof] the requested sound "on the fly" via sine waves.

In a voice-over-internet app, we would provide sound data to the caller that was obtained from incoming internet packets.

What I’m not seeing is how to tell the caller that we don’t have ALL of the data he requested. When I run the UserCreatedSound example,
I see that the stream is requesting 16K bytes (4K stereo samples) at a time.

Through what mechanism can we tell the stream that we have (for example) 3800 samples in reply to this request, not the full 4000?

We’re of course at the mercy of the incoming ethernet data, but assuming we don’t lose data, we can indeed keep up with playback, but not
necessarily give the caller EVERYTHING he wants this pass (i.e., we can feed him ahead of his playback ‘cursor’, but maybe not give him 100%
of his request each callback – but if he continues to play what we give and comes back later, we’ll be able to keep him fed for seamless sound).

What’s the "correct" method for using this callback to handshake with the caller in the case where we have (perhaps slightly) less data than requested?

Regards,

Bill

  • You must to post comments
0
0

[quote:3lihvuk5]If you have less data than is requested then simply memset the remaining bytes with 0. [/quote:3lihvuk5]

But that will be played as a silent gap in the stream, right?

The issue I’m looking to address is a callback request for, say, 4000 samples and at the time of the callback, I have 3800.
But as those 3800 are being played, the rest of the sound data will arrive in time to be seamless.

In other words, over a 3-request period, we want 12000 samples, and the callback would ideally like 4000, 4000, 4000.
And I will indeed have all 12000 within that time frame, but perhaps 3800, 4100, 4100 and in time to keep up with the actual playback.

Is there any way to accommodate this?

  • You must to post comments
0
0

yes it will be silence, but if you want to feed it real data, then buffer it yourself offline and make sure you feed fmod data as it needs it, as i said earlier.

  • You must to post comments
0
0

[quote:fl6n8o1b]if you want to feed it real data, then buffer it yourself offline and make sure you feed fmod data as it needs it[/quote:fl6n8o1b]

Unfortunately, "offline" isn’t possible – this is all real-time station-to-station voice chat.

There is a real possibility of getting incoming packets a little "late", but still "in time" for playback, provided we can handshake a little.

Question: How far in advance of the sound’s current playing position does FMOD issue a pcmreadcallback() for the next stream chunk?

Thanks!

  • You must to post comments
0
0

all ‘offline’ means is ‘a little bit ahead’. Its not really fmod’s job to handle this.
Think of a soundcard that outputs at 44khz constantly and requires 44100 samples per second, no less, no more. What would you do in that case? This is exactly the issue with fmod.

You just have to buffer ahead and cop the latency. so that when it is starving it can feed from a prebuffered block of memory that you have prepared in advance. Otherwise, just feed silence.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.