Problema audio di ritorno

[davide-ship-it]

Ho provato a integrare il modulo con la mia installazione di FreeSWITCH.

• Ho configurato la mia chiave OpenAI nell’apposito parametro.
• Per il test ho lanciato il comando:

uuid_openai_audio_stream {uuid} start wss://api.openai.com/v1/realtime?model=gpt-realtime mono 24k

In console ricevo correttamente tutti gli eventi provenienti dall’API di OpenAI, quindi la connessione sembra funzionare.
Tuttavia, non viene riprodotto alcun audio in chiamata.

Se successivamente eseguo:

uuid_broadcast {uuid} /usr/share/freeswitch/sounds/music/16000/ponce-preludio-in-e-major.wav aleg

allora viene riprodotto in sequenza tutto l’audio che era stato bufferizzato in precedenza (presumibilmente quello proveniente da OpenAI) e solo alla fine il file audio che volevo mandare.

In pratica sembra che il modulo riceva e accumuli correttamente i pacchetti audio, ma non li invii in tempo reale allo stream del canale.

[dariopellegrino00]

Ottima osservazione la tua intuizione è molto vicina al cuore del problema.

Il comportamento che descrivi è dovuto al modo in cui FreeSWITCH gestisce l'audio e in particolare all’attivazione del media bug, che è il meccanismo usato dal modulo per intercettare e scrivere audio sul canale chiamante (tipicamente il leg-A).

Questo succede perchè FreeSWITCH non attiva il media path in scrittura se non c’è una sorgente audio attiva sul canale (come ad esempio playback, record, bridge, etc.).
In assenza di una sorgente che genera audio verso il chiamante, il media bug non riceve le callback write_frame, quindi l’audio ricevuto da OpenAI viene bufferizzato internamente dal modulo ma non viene mai scritto sul canale in tempo reale.

Quando poi esegui uuid_broadcast, FreeSWITCH inizia a generare audio verso il chiamante e solo a quel punto il media bug si attiva e scrive tutti i frame precedentemente accumulati, come hai notato.

Il workaround che stiamo usando è attivare subito una stream di silenzio, che forza l’inizializzazione del media path in uscita. Uno dei primi dialplan di test per sviluppare il modulo era simile a questo:

    <extension name="openai-audio-stream">
      <condition field="destination_number" expression="^9389$">
	<action application="set" data="STREAM_OPENAI_API_KEY=chiave />
	<action application="set" data="STREAM_BUFFER_SIZE=400" />
	<action application="answer" />
	<action application="set" data="api_result=${uuid_openai_audio_stream ${uuid} start wss://api.openai.com/v1/realtime?model=gpt-realtime mono 24k}" />
	<action application="playback" data="silence_stream://-1//"/>
      </condition>
    </extension>

Stiamo valutando delle alternative più robuste, come ad esempio forzare l’attivazione del media path lato FreeSWITCH anche in assenza di audio generato, ma al momento non c’è un modo ufficiale semplice per farlo senza introdurre effetti collaterali.

Nel frattempo, questo workaround con silence_stream://-1// ha funzionato bene nei nostri test.
Potrebbe essere utile aggiungere una nota nel readme che spiega il problema e la soluzione.

[dariopellegrino00]

Updated docs README at commit ecd4a6a adding a get started section explaining how to avoid this issue.
Opening a dedicated issue #21 for a cleaner and self-contained solution.