DEC-TALK USB and speech dispatcher

[Luke Yelavich]

On Sat, Feb 28, 2015 at 09:07:35AM AEDT, Klarich, Terry J. wrote:
> Hello all:
> 
> Obviously, I am new to this list.  My name is Terry Klarich.  I work as a 
> systems analyst for a natural gas company in Oklahoma U.S.
> 
> I am presently experimenting with the DEC-Talk USB under Linux.  I contacted 
> the manufacture and did receive the info to build a driver.  I can send 
> speech and commands to the DEC-Talk.  I can talk to the DEC-Talk either using 
> the libusb libraries or directly using a kernel driver.  I am still trying to 
> get index marks working.  I hope to work more with the manufacturer to get 
> index marks working.
> 
> I have written the beginnings of a speech dispatcher module.  I didn't use 
> the sample module code discussed in the speech dispatcher documentation.  
> Rather, I wrote it from scratch.

Awesome to see someone working on a driver for this.
> 
> I am running into a problem.  I'm hoping someone can assist.  When starting 
> speech dispatcher, it hangs when sending the "INIT\n" command to the sd_dtusb 
> module.  Here is the log:

<Snip>

Speech Dispatcher modules use stdin and stdout to communicate with the speech 
server. When executing a module, the server forks into another process, sets up 
the pipes from stdin/stdout of the module, and then executes with execvp().

I noticed that when you ran the module by hand that you didn't specify its 
config file. The server expects to be able to call the module with the path to 
its configuration file as the only command-line argument, although this likely 
has no bearing on why your module is hanging.

As to the method used to communicate with the hardware, I think libusb would be 
more portable, as Speech Dispatcher is not Linux specific. I don't know of 
anyone who has tried to run it on BSD as such, but I know a while back work was 
ongoing to try and make it usable on OS X. Using libusb would allow users to be 
able to use this hardware on sed platforms.

Not sure what else I can suggest just from seeing your logs alone. Dropping 
debug/printf calls in the server code and your driver would certainly be one 
way of determining the hang point.

Hope this helps.

Luke