Big delays receiving output_audio_buffer.stopped event since Apr 18th

Since April 18th, and still happening as of April 26th, we’re intermittently seeing pretty big delays between the model finishing its spoken response and us receiving the output_audio_buffer.stopped websocket event.

Most responses are fine, but suddenly a 2-4s audio response ends up with a 10-12s time window between output_audio_buffer.started and output_audio_buffer.stopped; meaning a 6-10s delay between the model finishing speech and the “stopped” event arriving.

Since the interrupt_response setting doesn’t seem to have any effect, as flagged here months ago: https://community.openai.com/t/issues-with-realtime-turn-taking/1369161

We rely on switching turn_detection on/off with a session.update to avoid the model getting interrupted mid-speech. We disable turn detection after response.create, then re-enable it once we receive output_audio_buffer.stopped.

When received promptly (as it always had been up until Apr 18th), the setup works well. However, when delayed, turn detection stays off way longer than it should. Therefore, the user speaks but their input is not picked up. Some go “hello? hello?”, while most just stay silent and hang up after a while. A very bad experience.

Examples of big output_audio_buffer.started - output_audio_buffer.stopped windows below. Again, all these were concise 2-4s audio responses.

resp_DVzNkceePLK27xkZ33UjJ

resp_DY845PNK8S1rPRY4jYs3G

resp_DYBAMoHOppd5Cx9UmKOj4

resp_DYC3eWgge9qEhZulRXsXY

resp_DYofSJBkOPKPkcNVDdcbg

resp_DYofw8GNnuMhypBEo8rMy

resp_DYohNIYItCxsXWJtc3nX0

@OpenAI_Support , @Sean-Der could anyone look into this issue?

Thank you

Sorry you are hitting this! I stopped working on Realtime API around Jan @victorm750

I will find someone to look at this though!

Wish you the best in your new adventure @Sean-Der :folded_hands: You’ve always been really helpful and valuable to the Realtime community, many thanks!!!

@OpenAI_Support could someone look into this?

We continue to see output_audio_buffer.stopped delays as reported in my previous message. Receiving and processing ws events are decoupled on our end, so we can ensure the delay is happening on OpenAI’s end because the delay happens on the receiving side (not processing).

On top of that, we’re seeing that we do not even receive some expected events at all.

A couple of examples below:

  1. In this call (logs filtered by output audio started/stopped pairs) we missed:
  • output_audio_buffer.stopped for response “resp_DbkeIQC6prVQ6JnCNE5Z9”
  • output_audio_buffer.started for response “resp_DbkeLxHBM3FcNiiEZNz6t”

  1. In this call (logs filtered by output audio started/stopped pairs) we missed:
  • output_audio_buffer.stopped for response “resp_DbmWSyDn27r851mK6nmVJ”
  • output_audio_buffer.started for response “resp_DbmWY397W7W8bVip5d1HA”
  • output_audio_buffer.stopped for response “resp_DbmWh42xtppwKxdNCtuyl”

  1. In another call, we missed the three “input_audio_buffer” events entirely, with turn_detection enabled:

We’d highly appreciate if someone on your team could check whether those events were actually sent on your end. This is critical because we can’t offer a reliable service at all if the core infra fails like that.

If anyone else is experiencing websocket issues, it’d be great to hear about it too.

Thank you

Hi @victorm750

Thanks for sharing these details and examples.

To help investigate this further, could you please create a support ticket if you haven’t already done so, and share the ticket/case ID here once available so that I can take a look at it further from my end.

~Smith

Hi @OpenAI_Support,

Yesterday (May 26th) was horrible. Many calls were impacted by this issue, including multiple delayed output_audio_buffer.stopped events within the same call. The frequency/severity seemed significantly worse than usual.

We’ve now opened a support ticket and provided two full call logs, timestamps, SIP headers, and additional technical details for investigation. Case Number: 09291741.

@Sean-Der, were you able to find someone to look into this?

Thank you

Hi @Victorm750

Thanks for flagging this.

I’m actively working on support case #09291741, and the details you provided and have been shared with the appropriate team for investigation. You should hear from us again very soon.

To keep everything centralized and easier to track, all further communication will continue through the support ticket.

I'll go ahead and close this community thread for now.

~ Smith