Repository for Generated Code

[kidplug]

Example class:
https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/transcribestreaming/TranscribeStreamingAsyncClient.html

Why is there no source for this (or any other classes in that package) here in this repo?

[kidplug]

Interestingly on maven repo there is a source jar:
https://mvnrepository.com/artifact/software.amazon.awssdk/transcribestreaming
http://central.maven.org/maven2/software/amazon/awssdk/transcribestreaming/2.2.0/

[zoewangg]

All service model classes are generated in the build time, although it would be nice to have them available in the repo. Marking it as feature request.

[kidplug]

Generated from what? I'm looking at this source code:

TranscribeStreamingAsyncClient.txt

You're saying that is a generated file? If so where is the content coming from?
For instance - the string "Starts a bidirectional HTTP2 stream where audio is streamed to Amazon Transcribe and the transcription results"
I don't see that anywhere in the whole project.

[kidplug]

Also then what about this file:

DefaultTranscribeStreamingAsyncClient.java
in: package software.amazon.awssdk.services.transcribestreaming;

Where does it come from?

[zoewangg]

Yes, all service clients and model files are all generated from the service model files, for instance, transribestreaming model: https://github.com/aws/aws-sdk-java-v2/blob/master/services/transcribestreaming/src/main/resources/codegen-resources/service-2.json

You can clone this repo and run mvn clean install -pl :transcribestreaming -P quick and it will generate the transcribestreaming classes.

[kidplug]

OK, thank you for clarifying that.

From the service.json you referenced above, I'm trying to figure out how these types work together to create the actual "message" event frame(s) that is sent to the server.

StartStreamTranscriptionRequest
AudioStream
AudioEvent
AudioChunk
referenced here

I've looked at: Message.java and I understand how to craft and sign a binary message, but I cannot figure out how the AudioEvent/Chunk should be represented in the "payload" of the Message.

The online AWS doc makes it look like JSON object with a base64 encoded blob for the chunk, but that approach hasn't worked for me. And in the generated class: AudioEventMarshaller.java doesn't seem to agree.

I know this is off topic from the original question, but could you offer me any help in figuring out how to encode the AudioStream/Event/Chunk into an eventstream message?

[varunnvs92]

For the StartStreamTranscription API, you send the audio as a stream of events. SDK accepts the audio through AudioEvent class through audioChunk field of type SdkBytes. Service accepts multiple AudioEvents until the client indicates transmission is complete.
Each event should be of format:

:message-type: event
:event-type: EventType (AudioEvent in this case)
:content-type: application/octet-stream (for raw payload)
====payload====

You can refer to this integration test for making a API call and sending the audio events. You can step through the code to see how the events are generated and encoded.

Here are service docs that might be useful:
https://aws.amazon.com/blogs/machine-learning/amazon-transcribe-now-supports-real-time-transcriptions/
https://docs.aws.amazon.com/transcribe/latest/dg/streaming.html

There is not lot of public documentation on the spec on how to marshall/unmarshall events.

[kidplug]

Cool - i understand all of that except the ===payload===. I'm implementing the client side in nodejs, and I am able to construct the event - but I keep getting a response: "Could not decode the audio stream...".
How is the actual PCM audio data encoded in the payload? The docs say "blob" and in other places it says "base64 encoded binary data". The docs also show it wrapped in a JSON structure. I've tried every combination I can think of, and keep getting the "could not decode" message.

(I've also looked into the JAVA code and have run the sample example app).

I also know an "empty" frame needs to be sent to terminate the stream, and I am able to do that.

[millems]

There has not been a large amount of demand expressed by other customers on this feature request. It's certainly nice to have, but would be a reasonable resource investment so it is hard to prioritize it with the amount of demand we are currently seeing.

I'm inclined to close this so that we can focus on other features until more demand is expressed.