Invoking the web API of IBM Watson’s Speech to Text service from .NET

With this blog post, I will try to help you in case you need to use IBM Watson web services in your application and your application is being developed in .NET. The problem is that IBM does not provide .NET development toolkits for accessing their services for some reason. They have only Java and Node. Without a toolkit, the task of accessing IBM Watson’s web API becomes slightly more difficult.

In the following example I will acccess the Speech To Text service using .NET’s HttpClient.aspx) class in order to transcribe audio file.

Before trying to make the first call it is necessary to register for the service and obtain username and password. Next, you will want to create and tune the instance of HttpClient:

Now it’s time to prepare the content to be sent to the IBM Watson. This content must be audio file stream, which must support one of the allowed formats, for details, see docs. Here I will use wav format, because I have discovered that compressed audio formats lead to more errors in the resulted transcripts:

Finally, the created client needs to be called with this content as an input

The continuous is an example of many possible parameters, which can be passed along with content, a complete list of which can be looked up in the documentation. This one actually tells to Watson that it does not have to split text into pieces at the audio pauses.

To observe JSON response:

Note that I basically ignore the async nature of HttpClient here by extracting the result right away. One could easily do the API call asynchronously. But I actually prefer the simplicity of the synchronous solution, trading some execution speed for this.

Anyway, here is the complete code with the call of Watson and the output (don’t forget to replace your username, password as well as your file name):


Troubleshooting Team City NuGet Installer

So you are troubleshooting your NuGet packages retrievement or installing in TeamCity? It is very hard to do because DLLs are cached and NuGet engine does not try to retrieve packages, which are already installed. This leads to the situation where you change some settings to see what happens but nothing really happens. I had this same situation while setting NuGet Installation build step. I was changing the set of NuGet sources, but nothing changed. Then I just removed all NuGet sources, but builds were still successful. I had almost gone crazy, but then I recalled – this kind of problems are usually related to some kind of cache. First I checked if there are any global settings of NuGet in TeamCity, did not find any. And after a while I have learned – in order to be sure that your packages installation runs completely, you have to:

  1. Delete  “packages” folder in your solution. This is to ensure that NuGet actually downloads something and puts it in right place;
  2. Delete all files in C:\Windows\SysWOW64\config\systemprofile\AppData\Local\NuGet\Cache folder (this is for 64-bit architecture, for 32-bit machine everything is in System32 folder). When Team City sees package ID in packages.config file it first looks in this folder for cached packages;
  3. Also, check what is in C:\Users\alexa\AppData\Roaming\NuGet\NuGet.Config if you have Visual Studio installed. Visual Studio uses this file to store NuGet configurations, because they are not saved anywhere in project or solution files.