> Below, I've posted my AudioBufferSource::doGetNextFrame(), in hopes you might
> be able to provide a more verbose suggestion... I understand if you don't
> have the time.
Yes, unfortunately I'm limited in how much time I can spend providing
assistance for free (especially for individual proje
Hi Ross -
Thanks again for your help here. I understand what you're saying with using
an event trigger for when additional data is available, but I'm having no
luck implementing as my C++ is fairly bad. Coming from C# and other
higher-level languages is proving to be a bit of a learning curve for
> I see what you mean, and fDurationInMicroseconds is being calculated
> correctly. For my fragmentation issue, If I don't call afterGetting() then
> doGetNextFrame() is not ever re-invoked, so the server essentially stops on
> the first partial read.
>
> Is there a method or variable I should
Hi Ross -
Thanks so much for getting back to me!
I see what you mean, and fDurationInMicroseconds is being calculated
correctly. For my fragmentation issue, If I don't call afterGetting() then
doGetNextFrame() is not ever re-invoked, so the server essentially stops on
the first partial read.
Is
> In my AudioBufferSource (based on AudioInputDevice) the doGetNextFrame
> happens at an extremely fast interval - which is sometimes causing my PCM
> audio running at 44.1 kHz to get fragmented.
The frequency at which "doGetNextFrame()" gets called depends entirely on the
value that you set f
Hi Ross / All -
In my AudioBufferSource (based on AudioInputDevice) the doGetNextFrame
happens at an extremely fast interval - which is sometimes causing my PCM
audio running at 44.1 kHz to get fragmented.
For example, I am tuning my server and client software to work with 64
(pcm)frame chunks, h
