Petr Peller: no

Brent Vatne: I'm trying to read blob data from a local file (an audio recording) and send to Amazon Lex. I would use this Blob support if it worked. What I'm doing works in the simulator but not on the actual phone:

const uri = this.recording.getURI();

const response = await fetch(uri);

const blob = await response.blob();

...

inputStream: blob,

await lexRuntime.postContent(params, this._handleLexResult);

I get back an error from Lex that the inputStream is "not a string, Buffer, Stream, Blob or typed array object". Seems fine + works in the simulator. Any advice? Can I use the new blob support somehow to solve this?

When I serialize my blob, it looks like this (in both the simulator and the phone): {"_data":{"size":48944,"blobId":"2151A...","type":"application/octet-stream","offset":0,"name":"recording-C446....D00.caf"}}

Does that look like a valid blob? I get the same result whether or not I strip off the "file:" prefix from the URL.

Mark Torrance: Hi Mark, you try using base64?

const uri = this.recording.getURI();

const response = await fetch(uri);

const blob = await response.blob();

const reader = new FileReader();

reader.readAsDataURL(blob);

reader.onloadend = () => {

let base64 = reader.result;

console.log(base64);

};

Rodrigo Tessarollo: Thanks for this suggestion! I've tried this and it seems to work as far as producing a base64 result in a string, but that does not seem compatible with the Amazon Lex endpoint for me; it responds as if I just sent it an empty sound file.

This is what it wants to receive as content-type; I have to declare one of these:

PCM format, audio data must be in little-endian byte order.

* audio/l16; rate=16000; channels=1

* audio/x-l16; sample-rate=16000; channel-count=1

* audio/lpcm; sample-rate=8000; sample-size-bits=16; channel-count=1; is-big-endian=false

Any idea about which of these choices I could make to have it send the data in a way it expects? So far I've just tried the first one audio/l16. I guess I can dig into the code for Lex client API to see how it processes the blob...

Someone else pointed me to this recent pull request for aws-sdk, which solves my problem. https://github.com/aws/aws-sdk-js/pull/2201/commits/d7c0724a05fd9b41f4fff74d3c857ec5d538f9ef

The issue was that the minifier was changing the name of the Blob datatype (or something), and this logic checks the type by name against a string list of names for validation. The fix involves inserting 3 if statements into the code of files in aws-sdk, to just "return" if the type is Blob.

Brent Vatne: Where can I find the related announcement?

John Baek: https://blog.expo.io/expo-sdk-v26-0-0-is-now-available-2be6d9805b31

Frederic Le Bris: I saw that PR was merged to the react-native core. So, maybe we can use it with Expo at SDKv27. (SDKv26 will release with RN@0.53)

Chenglu Li: Does it work now?