#mu law encoding through Twilio call always has a loud tick right at the beginning

1 messages · Page 1 of 1 (latest)

copper yew
#

I have a very basic call the deepgram Aura:

      const response = await deepgram.speak.request(
        { "Hello" },
        {
          model: "aura-asteria-en",
          encoding: "mulaw",
          container: "wav",
        }

However, when I base64 encode and send to twilio it always plays with a tick at the beginning. It's weird because when I play it locally there's no tick. Any ideas on what could be happening?

dry sparrowBOT
#

Thanks for asking your question. Please be sure to reply with as much detail as possible so we can assist you efficiently. Such as:

  • Provide the request_id if you've a question about a transcription response.
  • The options you used or the api.deepgram.com URL you sent your request to, including parameters.
  • Any code snippets you can include.
  • Any audio you can include, or if you can't share it here please email it to us at [email protected] and provide a link to this thread.
lost rapids
#

Base64 encoding pads the output with '=' characters at the end to ensure the length is a multiple of 4. It assists decoding to know the correct length.

Is it possible that Twilio is incorrectly decoding it? Maybe trim the string of the padding (which is technically bad), but it should still successfully decode. If that gets rid of the clicks, it would be an issue to raise with Twilio.

#

The alternative is that they're not quite using the same playback settings as you

copper yew
#

Thank you for your response! I'll check out to see if there's = at the end of the base64 encoding string & get back to you!

It is odd given that I am playing back the base64 encoded audio in my browser and it works...

copper yew
#

@lost rapids that worked like a charm!!! Thank you thank you!!

lost rapids
#

No way 🤣 why are Twilio not trimming valid audible characters 🤣

copper yew
#

No idea! I'm not sure how audio works but did not expect trimming the end of the base64 encoded string would fix audio that only appears at the beginning of the clip 😆

sturdy kiln
lost rapids
#

Yes, my colleague Damien was just telling me that if you remove the wav container before encoding, it should play without ticks.

It IS making audio out of non-audible characters, just not the =. It is the container header 😁

copper yew
#

@lost rapids what do you mean remove the wav container?

      const response = await deepgram.speak.request(
        { text },
        {
          model: "aura-asteria-en",
          encoding: "mulaw",
          container: "wav",
        }
      );

I have this now!

copper yew
sturdy kiln
copper yew
copper yew
lost rapids
lost rapids
copper yew
copper yew
# lost rapids yup 🙂

Hmm I did this:

      const response = await deepgram.speak.request(
        { text },
        {
          model: "aura-asteria-en",
          encoding: "mulaw",
        }
      );

And this still has the ticks 😦 Did you mean to do something differently?

Actually now that I reverted that I'm still getting the ticks... let me play around with it some more

#

I don't see any = appended at the end of the encoded message now so it's not stripping anything

lost rapids
#

Yes there is potential it is not the =, but the audio headers. By removing the wav container it shouldn't have any headers now. I'll double check with my colleague to see if you need to do something else

copper yew
#

Thank you!