watson-personal-assistant / audioclientsamplecodejava Goto Github PK

The simple interface currently indicates when the client is listening and when it is responding (using the blue LED). The simple interface includes a red and a green LED that can be used to indicate other status of the client.

The suggestion is that the following indicators be used with the simple interface:

• Solid red: Client is muted (not listening or playing)
• Blinking red: Client does not have a server connection and is trying to connect
• Solid blue: Client is listening (after wake-up)
• Blinking blue: Client is playing response
  (green is currently unused)
  The simple interface assumes the use of a single RGB LED, such that a full hue of colors can be displayed. This might be used in the future to display various status. This will not work well if the simple interface is constructed using three separate LEDs (red, green, and blue).

Change the default port used for the Controller Interface Command socket to not be the same as the default port used by a NodeJS server running on the same machine.

The default of 10010 is the default for the Command socket and for a NodeJS server.

Users of the client indicated that the LED blink rate was too slow when playing the response.
It is on for 1/2 second and then off for 1/2 second. It has been suggested that it be twice as fast.

Also, the Console Status indication was using too many characters.

The 'simple' interface uses 5 GPIO pins (2 input switches and 3 output LEDs). Some controllers use a Sense-HAT to display much more information than the RGB LED does. It has been requested that both interfaces be able to coexist and be connected and used at the same time.

The GPIO pins used were selected before knowing that a Sense-HAT would be used.

Change the GPIO pins used so that they don't conflict with the Sense-HAT to allow both to be connected and used together.

The audio client today only uses the "prompt" value from the attribute in the "action": "text" message as below:

{
	"speech": "I am not trained for this",
	"voice": "https://stream.watsonplatform.net/text-to-speech/api/v1/synthesize?voice=en-US_LisaVoice&text=I%20am%20not%20trained%20for%20this&watson-token=xc9D......ATB",
	"id": "aa16b1e9-xxxx-xxxx-xxxx-58b7f7df23d7",
	"language": "en-US",
	"audioFormat": "ogg;codecs=vorbis",
	"prompt": true,
	"action": "text"
}

It does NOT however take notice of the value in audio_end:

{
	"action": "audio_end",
	"id": "aa16b1e9-xxxx-xxxx-xxxx-58b7f7df23d7",
	"prompt": true
}

They should arguably always be the same however maybe there is also a bug in the AudioGateway as we are seeing differences in these values.

The client and Audio Gateway currently use a Base64 encoded audio data transfer format. This adds overhead to the audio data transfer.

Consider using a pure binary audio data transfer format to reduce the data stream overhead and improve performance.