[hpsdr] CW operation

[Chris Albertson]

Number below are "about right" but your typical off the shelf Windows
audio driver keeps about 512 samples in its buffer.  This is almost an
order of magnitude worse then the USB buffer problem.     All of these
delays could be addressed but it would take some redesign to move the
tone generation closer to the user.   That is the solution used in all
profesional music recording systems.   It is simply a matter of logic
that the "turn around point" can't be at a place where there is
communications delay.

The abilty of human ears to detect latency varies.  But people with
some training, such as musicians or CW ops who spend time listeening
to exact timing of sound can hear a 20ms delay easy.  Some ssay thay
can detect a 15ms delay bout I doubt it.  At 50ms it is obvious to
anyone

The speed of sound in air is about one foot per ms.  So if there is a
drummer 15 feet away there is a 15ms delay between when you see the
stick hit and when you here the sound.  Notice that small bands always
keep together within this distance.   Large ground like a symphony
orchestra need a visual beat and so always use a conductor as the
sonic delay from percussion to violin can easy be 50ms on a large
stage.  50ms is to long to keep time by ear.

I bring all this up just to point out that latency is a problem that
was well understood long before the electronic age and there is much
data to use to reset requirements.  I'd say that y must keep the
latency below 15ms and have a goal to be lless than 10ms.   If you
share this goal then it is pretty clear that the "turn around" needs
to be moved closer to the user.



> Remember that there's a low limit on the responsiveness of the paddle connected to the DB-9 based on the sample rate.  The PTT/DOT/DASH bits are sent in the header of the packet coming in over USB.  How fast those packets come in depends on the sample rate you are using, because they're fixed at 63 samples per packet.  My back of the envelope calculations are:
>
> 48000 samples/sec:   1.2msec
> 96000 samples/sec:   0.66 msec
> 192000 samples/sec: 0.33 msec
>
> I'm not saying that those are unacceptable, or that they're causing your problem, but it's something to consider when we're talking about latency.
>
> Also consider on the other end of things that Penelope is always at a 48000 samples/sec rate.  You have to queue up 63 samples before you even get to send the packet across the USB.  So you could potentially have another 1.2 msec before the first sample of your CW signal gets across the USB to Magister.
>
> I'm not sure what you're meaning by "low tens" of milliseconds latency.  If you're meaning "between 10-15", then consider that 20-25% of that latency is merely USB protocol overhead both ways.  You'll encounter the same overhead if you use Mercury's audio output because those samples get back in the same packet that the Penelope transmit samples do.  You could try to push the audio out the system speakers, but there's not telling how much latency there is in that audio device.

=====
Chris Albertson
Redondo Beach, California

 1294417972.0