It is very good that you have given the ham community a well
done sound over IP program. There already was a program like
this called IP Sound written by SM5VXC, however, the OM seems
to have vanished, and his last release has been passed around
the internet. It will be good to get a supported program
again.
I could never get IP Sound below 150 to 200 ms at my QTH.
Perhaps it was limited by my computer. One of the problems
with VOIP programs is that the designer seems to think that
the figure of merit is how low he can reduce the data rate.
It seems logical that doing this will increase the absolute
latency (even with no processor delays) and will also increase
the processing workload for the computer.
I also tested Remote Rig, which has its own hardware. It could
get down to about 100 ms on a good day. The problem you have is
that if you make the buffer size small to get good latency, you
increase drop outs. I can get pings of less than 20 ms, MOST of
the time. The problem is that I will get a non zero number of
200 or 300 ms pings. You end up having to trade off latency for
drop outs.
I will try out your software and see how it compares to IP Sound
and Remote Rig.
Rick N6RK
DF3CB wrote:
>> I have found that this limits latency to something like 50 ms and the
>> audio is relatively high fidelity because the standard 56k codex is
>> quite good, compared to any kind of VOIP, which is optimized for, guess
>> what, voice, not weak signal CW. In general, you cannot get this kind
>> of latency over the internet, and if you could, it would require BOTH
>> the remote internet and the control point internet to have low latency.
>
> I can agree to some point. However, it's a fact that most of the latency
> is
> not generated on the internet line itself but on your own (client)
> computer
> and in particular with soundcard processing of the remote audio. I am also
> operating my station fully remote-controlled for DX, the station is 30km
> away from home. I've gone very deep into the problems around latency (it's
> almost a science) and developed my own VoIP software called RemAud
> (available at http://df3cb.com/remaud/). Another important factor are the
> right audio buffer sizes. More to read about that at
> http://df3cb.com/remaud/concept.php.
>
> The internet line latency can be as low as 20ms in my environment but can
> be
> as high as 80 or 100ms in the evening time. Not much to do about that. But
> I
> was surprised how long soundcard processing can take. I measured it and
> found out that there is a steady soundcard buffer overrun on my computers
> adding another 50 or even 200 or 300ms latency. The soundcards are not
> able
> to process a high number of small audio chunks - necessary for low latency
> -
> in an appropriate time. What I do with my software is to watch the number
> of
> audio chunks going into the soundcard and counting the number of processed
> audio samples at the same time. If a certain buffer overrun, set by a
> software parameter, is exceeded I begin to omit some of the incoming audio
> chunks and let them **not** process by the soundcard. This doesn't play
> any
> matter for CW or SSB. It might for digital modes. You might not even
> notice
> the dropped-out audio samples but latency can be absolutely reduced and
> minimized. (To whom it may concern, the next step are ASIO soundcard
> hardware drivers).
>
> I've also experimented with other VoIP software and different Codecs,
> compressed and uncompressed and my favorite is PCM, 8kHz needing a rather
> low internet bandwidth and reaching an estimated radio audio quality of
> 95%.
>
> 73 Bernd DF3CB
>
>
> _______________________________________________
> Topband reflector - topband@contesting.com
>
>
_______________________________________________
Topband reflector - topband@contesting.com
|