Il vero push-to-talk
Un pulsante che si tiene dovrebbe mantenere il microfono aperto finché lo si tiene. Il nostro non lo faceva davvero: il problema non veniva dal nostro codice, ma da un limite che non potevamo vedere prima di incontrarlo.
Un pulsante che prometteva più di quanto mantenesse
Il principio del push-to-talk è semplice: premi, parli, rilasci, viene trasmesso. Solo che il riconoscimento vocale integrato in Android ha il suo cronometro, invisibile dal nostro codice: dopo circa un secondo e mezzo di silenzio, considera che hai finito di parlare e interrompe l'ascolto, che il tuo dito sia ancora sul pulsante o meno. Un'esitazione, un respiro un po' lungo mentre si cercano le parole, e la frase veniva troncata senza preavviso. Peggio: per continuare ad ascoltare nonostante questa interruzione, bisognava riavviare il motore di nascosto, il che produceva dei bip udibili e dei buchi nella trascrizione. Il pulsante diceva «ti ascolto finché mi tieni», ma in realtà, ti interrompeva dopo una pausa un po' troppo naturale.
Un muro che non si può spostare
Abbiamo prima cercato di aggirare questo cronometro: disattivarlo, allungarlo, nasconderlo dietro un riavvio più discreto. Niente ha funzionato. È un limite fissato dal sistema, documentato come tale, e riprodotto identicamente su diversi telefoni Android recenti. Un push-to-talk degno di questo nome deve poter durare quanto l'utente decide, pause incluse: un promemoria dettato, una lista della spesa pensata ad alta voce, un pensiero che esita prima di formulare. Nessuna impostazione permetteva di ottenere questo da quel motore. Bisognava uscirne.
Catturare, inviare, trascrivere altrove
Abbiamo quindi cambiato approccio alla radice. Invece di far riconoscere la voce direttamente sul telefono, XNeuronal ora registra l'audio grezzo, in un formato compatto, per tutto il tempo in cui il pulsante è tenuto, senza alcun limite di durata imposto dal sistema. Al rilascio, questo file parte verso il server, accompagnato dal tuo identificativo, per essere trascritto dal nostro riconoscimento vocale nel cloud. Durante la registrazione, una bolla «🎙 ascolto…» rimane visualizzata direttamente nel flusso della conversazione; al rilascio, diventa «trascrizione…» il tempo del viaggio di andata e ritorno della rete, poi si trasforma nel tuo messaggio finale: un unico riferimento visivo dall'inizio alla fine, dove prima l'indicazione fluttuava sotto l'orb, separata dal flusso.
Questo cambiamento è stato anche l'occasione per rendere il gesto più rigoroso: finché il pulsante è tenuto, nessun avviso di errore disturba l'ascolto, e il rilascio innesca l'invio senza ambiguità, anche se hai tolto il dito un istante troppo presto o troppo tardi. È questo gesto, tenuto e affidabile, che rimane al centro della voce e della conversazione con XNeuronal. Inviare un file piuttosto che ascoltare in diretta sposta anche il rischio: il guasto non è più nel microfono, può venire dalla rete. Senza rete, la dettatura non può semplicemente essere trascritta. Dietro le quinte, il modulo vocale incassa le disconnessioni passeggere della connessione: se la sessione si interrompe durante il percorso, la riavvia con un tempo di attesa crescente, fino a otto tentativi, affinché una micro-interruzione isolata non si trasformi in una dettatura persa.
Cosa si guadagna, cosa si paga
Il guadagno è netto: la trascrizione non dipende più da un motore limitato da un cronometro che non controlliamo, e la sua fedeltà ne risulta migliore, anche su frasi lunghe, esitanti, o piene di nomi propri che un motore generico integrato riconosceva male. Il prezzo, lo assumiamo: poiché l'audio va a un server, non c'è più un feedback istantaneo mentre parli, nessuna parola visualizzata in diretta, solo la promessa di una trascrizione fedele una volta rilasciato il pulsante, e una dipendenza di fatto dalla rete affinché questa trascrizione arrivi. Preferiamo questa onestà a un pulsante che sembrava reattivo in facciata ma ti interrompeva senza dirlo.