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

[Don]

Sorry, I don't always check the headers to see if a message was addressed
specifically to me or to the list.  I figure others may have an interest
AND may be able to catch any assumptions I may be making before I get
too far afield.

I went looking for the "DECtalk USB" and see it has a USB "A" connector
as well as a DB-9 serial port.  So, I now assume you are using a serial
port cable to connect it to the computer?  Previously, I had assumed
the hardware connection was via USB but it was just implementing a
serial port protocol *on* the USB connection.  This is important because
the designers might have chosen to do things differently if they fully
exploited the USB interface.

I also went looking for information on SpeakUp as your comment suggested
that it was a kernel module.  I'd assumed it was a stand-alone application
that was started by the operating system at boot time and "wired into"
the display device.  Now, it seems that the integration is inside the
kernel.  That muddies the interface assumptions -- compared to a simple
serial port.

The original DECtalk had a pair of serial ports -- one that connected it
to the host computer and one that connected it to a terminal.  This allowed
it to be added to an existing "time sharing" connection without having to
do anything special -- it just LOOKED like a terminal.

In that configuration, one could tell the DECtalk to "log" various details
about the current "session".  So, you could see -- and, theoretically,
capture -- the data that was being sent to the DECtalk.  This would be
an aid to debugging applications that targeted the DECtalk's capabilities.

In that case, one could kludge a connection from the "terminal" back to another
serial port on the computer and run a program to capture all of the text coming
*in* from the DECtalk -- which is actually a copy of everything that was sent
OUT to it!

This would be a poor man's way of watching the data stream while the DECtalk
was "gagging" -- to see if the SpeakUp was sending something that it shouldn't
(e.g., an RIS instruction).  Or, if it was violating some other possible
constraint (like not waiting for the DECtalk to finish processing previous
data and overflowing the buffer inside the DECtalk).

It could also help identify if the DECtalk was possibly misbehaving.  For
example, failing to tell the computer to "slow down".  Or, claiming to
be able to buffer N characters but, actually, only able to buffer N-1.
In which case, the computer could think it is obeying the constraints
imposed by the DECtalk but, in fact, the DECtalk isn't properly handling
those limits.

Imagine if you could carry N items in your hands.  What would you do
if given one more?  You could:
- drop that item
- drop the item you've held onto for the longest amount of time (oldest)
- drop everything except this most recent
- pull your hair and scream
- etc.
But, you have to do *something* because you can't prevent that next item
from coming along!

This is the situation for the DECtalk.  It can't prevent the computer from
doing something that it doesn't like.  So, it all boils down to how it
reacts to that situation, if it occurs.

If you can sort out, in your mind, what the "default" conditions for
the DECtalk are and then decide if this is what the DECtalk "drops to"
when it gags, that would strongly suggest a reset is occurring -- either
explicitly commanded or a side-effect of something misbehaving.

Then, the question will be to determine where the fault lies.

Know that it's not possible to change the behavior of the DECtalk.
But, it is likely that the SpeakUp interface could be bastardized
to accommodate any "problem" that may exist inside the DECtalk.

Its unfortunate that folks are maintaining a codebase without the
proper tools to *test* their changes to it.  At the very least,
they should have one of every device that they claim to "support".

AND, they should be thoroughly testing every change they make
to the codebase against every one of those devices.  If not,
then what's to stop them from CLAIMING they work with all sorts of
devices that they've NEVER tested?!

On 9/18/2022 1:14 PM, Chime Hart wrote:
> Hi Don: First, I was surprised our current discussion was going to an entire
> list, but this is good as others much more experienced than myself will have
> analysis. Next, yes, there is a volume wheel-and-toggle switch on the unit.
> When I try your echo command, it says stty permission denuyed, even with sudo.
> I would think some1 would need to analise the Speakup drivers, which if some1
> wanted, I could probably send, but now Speakup is in staging in the kernel
> since maybe Debian 5.0.9? There was an `anoying issue whenever there were a
> hardware change, would reboot-and since flush time was set a 400MS, there would
> be a 4second delay after any typing. Anyway, now it is set at 10. Really, the
> nice thing back in the Vocal-Eyes days, many were useing DecTalk PC or Express,
> so if there were bugs they would be noticed along the way. Not sure if there
> aren't more than 5 of us on the Speakup list running any kind of DecTalk. I was
> going to try-and-record an audio sample of those drops to share with the Debian
> Speakup maintainer, as this unit has an ear-phone jack
> Chime
>
> _______________________________________________
> Dectalk mailing list
> Dectalk at bluegrasspals.com
> https://bluegrasspals.com/mailman/listinfo/dectalk