[DECtalk] It's time to bust some DECtalk myths

[Don]

Chime,

Looking through sources without a clear understanding of what is actually
happening is an exercise in futility.  If it was that easy, the maintainers
would already have stumbled across it!

Note that whenever you have two devices talking to each other, there
are many variables that come into play.

For example, if we assume the problem is an overrun in the DECtalk's
input buffer (coupled with not being handled properly), one has
to assume the code -- on both ends -- *tried* to work correctly.

But, sending characters out of the PC involves some hardware buffering;
while one character is "on the wire", another character (or characters(
are sitting in the transmitter waiting to be sent.

At the same time, the receiver in the DECtalk can be receiving the
character that is on the wire, while still holding onto the character
that was sent just prior -- waiting for the software to accept it.

So, when the DECtalk sees that *prior* character as being received,
it must be accommodated along with at least two more characters that
are already queued up -- one that's on the wire and another waiting
in the PC's transmitter.

If the PC can queue more than one character (some can queue a dozen!),
then these must also be accounted.  Likewise for the receiver in the
DECtalk.

If the DECtalk uses "hardware pacing" to inform the PC that it
needs the PC to slow down, then it has to twiddle that signal and
hope the PC sees it before it queue up yet another character.

If, on the other hand, the DECtalk uses XON-XOFF signalling to
convey this information, then the DECtalk has to queue the XOFF
character for transmission -- which may have to wait for any other
characters to be transmitted to the PC that have been enqueued,
previously.  Once that character actually hits the wire, it
has to be received by the PC and recognized as "stop transmitting".

But, while it was "on the wire", another character from the PC
could have been "on the wire" to the DECtalk.

I.e., just "doing the right thing" is fraught with potential for
slight misunderstandings -- that manifest only in circumstances
of high traffic, etc.  You have to see that this is happening
before you can look at where (and how) to prevent it.

On 9/18/2022 7:04 PM, Chime Hart wrote:
> Hi Don-and-All: Don, you are most likely correct on all your comments, but I
> still think its an error in 1 or more of those Speakup drivers. Looks like
> names are
> speakup_dtlk.c
> speakup_dtlk.h
> speakup_dtlk.ko
> speakup_dtlk.mod
> speakup_dtlk.mod.c
> speakup_dtlk.mod.o
> speakup_dtlk.o
> You could probably find them online, or I could send them off-line?
> Please consider when I was in windows with this same device, I didn't have
> these issues, but certainly there are windows drivers. So Speakup is the common
> denominator. Thanks in advance
> Chime
>
> _______________________________________________
> Dectalk mailing list
> Dectalk at bluegrasspals.com
> https://bluegrasspals.com/mailman/listinfo/dectalk