Gladia browser sample: wrong sample rate breaks audio on some devices

TL;DR

In the JS browser example you set both sampleRate and desiredSampleRate of RecordRTC to the same value. Removing the sampleRate line fixes it, and we put up a PR to change the sample accordingly.

Steps

1. In the JS browser example you set both sampleRate and desiredSampleRate of RecordRTC to the same value. Setting sampleRate tells RecordRTC to parse the source audio as if it were already that rate, which breaks on devices whose mic runs at a different rate, like a MacBook with AirPods. I followed the docs exactly and my requests work on other endpoints. Is there something different about how this endpoint validates input?
2. You are right, that was a bug in the sample. desiredSampleRate is the one that asks RecordRTC to resample toward the rate you send to Gladia, but forcing sampleRate to the same value makes it misinterpret the source audio on any device whose mic runs at a different rate. Removing the sampleRate line fixes it, and we put up a PR to change the sample accordingly. Thanks for the report.

When to use

You are seeing this: Setting sampleRate tells RecordRTC to parse the source audio as if it were already that rate, which breaks on devices whose mic runs at a different rate, like a MacBook with AirPods. Use this skill when you run into "Gladia browser sample: wrong sample rate breaks audio on some devices".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

In the JS browser example you set both sampleRate and desiredSampleRate of RecordRTC to the same value.

In the thread Gladia browser sample: wrong sample rate breaks audio on some devices, the question was: In the JS browser example you set both sampleRate and desiredSampleRate of RecordRTC to the same value. Setting sampleRate tells RecordRTC to parse the source audio as if it were already that rate, which breaks on devices whose mic runs at a different rate, like a MacBook with AirPods. I followed the docs exactly and my requests work on other endpoints. Is there something different about how this endpoint validates input? The verified resolution: You are right, that was a bug in the sample. desiredSampleRate is the one that asks RecordRTC to resample toward the rate you send to Gladia, but forcing sampleRate to the same value makes it misinterpret the source audio on any device whose mic runs at a different rate. Removing the sampleRate line fixes it, and we put up a PR to change the sample accordingly. Thanks for the report. Original discussion: https://vectle.com/threads/thr_SnS2rKocbgT3Vynh9PbQGw