angelo70 at gmail.com
Mon Feb 23 02:25:48 PST 2009
i study on this very precious informations. My first attempt will be to
discard the exceeding amount at the rx (PC) side. Later, since i can
acces to the firmware of the remote sender, i would implement the
variable bitrate streaming.
I have still some doubt on the variable starting latency, the problem
that when i start to receive and play, sometime latency is
other times i have an initial latency of about 1 sec.
Maybe it can depend from the number of AL buffers filled before starting
to play ? But is strange, for the fact that initial latency is variable,
I start to receive data immediately after the tcp connect.
Now i wait for the total number of buffers to be filled before start to
if (QueuedCount == INPUT_BUFFERS)
Chris Robinson ha scritto:
> On Saturday 21 February 2009 4:27:06 am Jarryd Beck wrote:
>> Is it possible to send messages back to the sender to say that you don't
>> want any more data for a while? You could have some sort of "ideal buffer
>> window", you could have say 50 buffers available, and the ideal is between
>> 20 and 30, if it drops above or below you tell the sender to either slow
>> down or speed up respectively.
> Ultimately it comes down to the sound card. If one sound card captures 8khz
> audio faster than another card plays 8khz audio, you will build up more
> samples than you can play, regardless of how it's sent. This happens because a
> sound card (same as a graphics card and the motherboard) has its own internal
> clock, and no two clocks are precisely in sync. It can happen just as easily
> (if not more-so) over a network as it can on the same machine with two sound
> The question is what to do with the build-up. Drop the excess to get back to
> manageable amounts, or play it faster to get back to manageable amounts? Or
> some other thing I haven't thought of.
> Openal mailing list
> Openal at opensource.creative.com
More information about the Openal