Proposal: streamsx.speech2text.starterApps

[Alex-Cook4]

I would like to propose a starterApps repository for the com.ibm.streams.speech2text toolkit.

This would initially contain the generic speech processing application that we are using at customer sites for our "cognitive call center". This application:

• Taps a network adapter to pull packets off of the wire.
• Filters packets to end up with rtp audio.
• Load balances audio streams and can be easily configured for different size environments
• Sends call text via tcp We are already ending up with different versions of this at different customer sites, so having a centralized solution is critical.

Longer term, this would be a location for:

• FAQs
• Centralized issue resolution
• Feature enhancement requests (to the out of box solutions)
• Collaboration between customers, lab services, business partners, and Streams development

Other solutions we are interested in providing in the future:

• .wav file production solution
• Call categorization solution using the streamsx.nlp toolkit

As part of this, I propose removing the streamsx.speech2text repository, since we ultimately went with an internal com.ibm.streams.speech2text toolkit. If support for other S2T engines is added in the future, we can revisit.

As initial committers, I propose @jjbosox and myself.

[ddebrunner]

This doesn't seem like a set of starter apps, instead it's reuseable functionality for speech to text, that could include complete applications or microservices.

E.g. I may want to do the network packet to text, but instead send the text via HTTP to a web-service, or publish as stream for downstream analytics.

So I think viewing this as a toolkit with reuseable functionality rather than starter apps would be better, so maybe just use the existing streamsx.speech2text repository ?

[Alex-Cook4]

@ddebrunner yes, I agree that this will end up being complete applications and microservices.

If we just start adding these to the streamsx.speech2text repository, is that confusing since it's not the actual toolkit with speech2text operators in it? How do you envision the structure of the repository, since I wouldn't see it as a single toolkit (from the Streams definition of a toolkit). The current application that we want to post is already two separate Streams toolkits:

1. Focused on the network tap aspect
2. Focused on the packet filtering and distributed speech processing

[ddebrunner]

Using the existing repository was just an idea, but network tapping doesn't seem specific to speech to text so it should not be in a start app repo for speech to text, but maybe better in existing toolkits that are focused on network packet sniffing.

May main point was to have the mindset that reusable components are being built, not example/starter apps that need to be modified to make work in any situation.

[Alex-Cook4]

At this stage, "reusable components" might be overstating what we currently have. I think the application has components that could (and probably should) be pulled out for this purpose over time though.

[chanskw]

I agree with @ddebrunner that maybe we should treat this more reusable applications / microservices rather than an one-off starter application that customer has to modify to get it to work at their sites. Even if we can't do it now, it maybe worthwhile to clean it up and architect them in such a way that we can do that in the future.

A repository does not have to contain just a single toolkit. I have recently reorganized the streamsx.health repository for it work better in the micrservice architecture. It contains the toolkits as well as the microservices that are built on top of that. Perhaps we can do the same with speech2text. Treat the repository as a repository for general speech2text microservices and contribute the applications for now. Slowly work towards moving the applications to be more reusable. The repository can contain toolkits and services related to speech2text in general.

[Alex-Cook4]

Ok, I am convinced :-) I like the idea of having the full applications and the microservices side-by-side, allowing us to gradually move in that direction. I will leave this issue open for a couple of more days to see if there are any objections to using the streamsx.speech2text repository for the proposal described above, with the long-term goal of having microservices/reusable components.