Poor audio quality

[atanasmatev]

Hi,
I wrote that in Discord and will also paste it here:

I integrated with Elevenlabs and noticed issues with recognition. When I did a play back from 11Labs portal, I heard that the audio quality for the speech to text part was a bit robotic. I believe the core issue is with the AudioSocket which only accepts 8kHz sampling. Same needs to be set on 11Labs. However when I googled for AudioSocket updates, I found out that 2 weeks ago a new commit in github was done which allows higher sampling rate. Are there plans to add this new version of AudioSocket to the core container?

[atanasmatev]

Looking at the core container (no cheating), I think that 0x12 (SLIN16) should be added as option in the data handling function. Currently only 0x10 exists as audio input, which I believe is the legacy 8KHz.

[CryptoDragonLady]

You are correct. Afaik the new res_audiosocket changes are not yet fully supported in AVR but plans are in the works to support it. @git-avr can correct me if im wrong.

But honestly it also sounds like there's either a buffering issue or codec mismatch potentially on your end, my money is on buffering issue.

[atanasmatev]

Well, I also changed the avr-sts-openai index.js in a way that it saves the audio buffer that is sent to OpenAI gpt-realtime STS to a file and then I played it back with a software that supports PCM raw audio (Audacity) and I can confirm that the audio is a bit robotic and the quality is not the same, compared to what it should be like with high-end codec (e.g. Opus). And it makes a difference. For example, if I use one of the OpenAI Realtime Agents demo (github.com/openai/openai-realtime-agents/), which creates a browser session to gpt-realtime, using 48kHz sampling, the recognition rate of my voice in Bulgarian language is much higher, compared to the AVR audio, which is limited to 8kHz by the Asterisk AudioSocket.

[gcareri]

Yes, we’re actively working on this.

We’re aware of the recent AudioSocket update that supports higher sampling rates, and it’s already on our radar. There are plans to evaluate and integrate this newer version into the core container.

We’re doing our best to move things forward while trying to accommodate everyone’s needs.

Thanks for the detailed feedback — it’s really helpful.

[gcareri]

Thank you for the detailed report, @atanasmatev! This is very helpful feedback.

Current Status

You are correct that the current AudioSocket implementation uses 8kHz sampling. This is indeed a limitation that affects audio quality, especially for languages with complex phonemes.

Available Workaround

For STS connectors (like avr-sts-openai), we have implemented upsampling to handle this:

• Input: Converts 8kHz audio from AudioSocket → 24kHz for the upstream API
• Output: Downsamples 24kHz API response → 8kHz for AudioSocket

This provides better quality while maintaining compatibility.

Upcoming Improvements

The team is actively evaluating the newer AudioSocket versions that support higher sampling rates. We are working on integrating these improvements into the core container.

Documentation Update

I am adding a section to the docs explaining audio codec limitations and the upsampling workaround. Thank you for helping us identify this gap!

For real-time updates, follow our Discord channel.