conference interpreter mode

[marcellen]

It would be great to have a real-time "interpreter" mode that provides real-time translation during a conference. This feature should include the following capabilities:

• Choose the audio source: either A) an ambient microphone for live conferences, or B) embedded audio output for online conferences.
• Select the known language in advance to bypass language detection, allowing for faster translations.
• Display the detected audio transcript in both the original and translated languages.
• Real-time
• Save the full transcript for later use.

During a 30 minutes or 1 hour conference, is not practical to press a reconding button, upload audio and have it translated. All work should happen in real time with a reasonable time delay.

[niedev]

Hi, thank you for the suggestions, the problem is that with a WalkieTalkie-like mode a real-time translation would be practically impossible, because the speech recognition has to stop when the TTS speaks (both because it would be captured by the microphone and because it would interrupt the speaker).

The mode that comes closest to a real-time translation is the Conversation mode with a bluetooth headset connected (it is not exactly real-time but the interlocutors can speak and hear the translation as if it were), although that can only be used for live conferences and with a maximum of 4 phones connected (to make it work with multiple phones and for a remote conference I would have to have a server, but this would involve costs so this feature should have a subscription fee, and for now I prefer to make everything run locally and for free).

However some of the feature you mentioned will definitely be implemented in the future (like the option to save the transcriptions and the option to display the transcription and the translation in WalkieTalkie chat).

[anuau]

Following up on the request for a conference interpreter mode. One-way real-time audio interpretation would be enough for a start.

[niedev]

Hi @anuau, first of all, thank you for your donation!
As I said in the comment above, a one device real time translation for more than 2 people (and languages) is impossible. But probably in the future I will extend the number of users that WalkieTalkie and Conversation modes can support. And certainly I will improve the speed and quality of speech recognition and translation 🚀
If I misunderstood you request let me know and explain it in more details.

[anuau]

Hi! What I meant was a one-way translation, for example, to be used during a lecture as a student to understand what the lecturer is saying. I’ve done extensive research, and the only options I’ve found are TransGull, PolyPal, and Felo Translator, but they are very expensive.

…

On Mon, Sep 8, 2025, 8:22 PM niedev ***@***.***> wrote: Hi @anuau <https://github.com/anuau>, first of all, thank you for your donation! As I said in the comment above, a one device real time translation for more than 2 people (and languages) is impossible. But probably in the future I will extend the number of users that WalkieTalkie and Conversation modes can support. And certainly I will improve the speed and quality of speech recognition and translation 🚀 If I misunderstood you request let me know and explain it in more details. — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC246XUD64VGNW47N3S6O3L3RXCPJAVCNFSM6AAAAACF3H4YACVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZUGMZTKNQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[niedev]

Ok, now I get it, this would be very useful. A simultaneous version of this would still be very difficult and not possible in the short term. But I can implement an audio queue on the WalkieTalkie mode to keep listening even during the audio processing. In that way, if you mute the TTS, in practice it will do the same thing (splitting the transcription in messages, but without missing anything), plus the WalkieTalkie mode will be improved in general. I added this to my list of improvements to do 🚀 Thank you for your suggestion!

[marcellen]

I used some other apps meanwhile, like Voiceping and 3PO. But only the first one has Windows version too. Still far from perfection on a desktop computer, but on mobile they are quite good.

[anuau]

From my experience, when it comes to an audio queue that allows continued listening during audio processing, the best results occur when single sentences (around 10 words long) are processed at a time. Some (commercial) apps process entire paragraphs at once, but this is not the best approach, as it creates a significant delay between what is being said and what the user hears.

…

On Mon, Sep 8, 2025, 9:17 PM marcellen ***@***.***> wrote: I used some other apps meanwhile, like Voiceping and 3PO. But only the first one has windows version too. Still far from perfection on a desktop computer. -------- Messaggio originale --------Da: niedev ***@***.***> Data: 08/09/25 20:55 (GMT+01:00) A: niedev/RTranslator ***@***.***> Cc: marcellen ***@***.***>, Author ***@***.***> Oggetto: Re: [niedev/RTranslator] conference interpreter mode (Discussion #67) Ok, now I get it, this would be very useful. A simultaneous version of this would still be very difficult and not possible in the short term. But I can implement an audio queue on the WalkieTalkie mode to keep listening even during the audio processing. In that way, if you mute the TTS, in practice it will do the same thing (splitting the transcription in messages, but without missing anything), plus the WalkieTalkie mode will be improved in general. I added this to my list of improvements to do 🚀 Thank you for your suggestion! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC246XSFIZHH2F5TQVMGY533RXI5JAVCNFSM6AAAAACF3H4YACVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZUGM3TQMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[niedev]

@anuau no problem, the length of the audio processed will still be controllable indirectly by changing the end voice timeout in RTranslator settings. So the user can chose if they want longer or shorter audio split 🚀

[anuau]

Thanks. That's a great idea. Don't feel pressured to implement it. For the time being, I'll try using two phones in conversation mode.

…

On Wed, Sep 10, 2025, 8:26 PM niedev ***@***.***> wrote: @anuau <https://github.com/anuau> no problem, the length of the audio processed will still be controllable indirectly by changing the end voice timeout in RTranslator settings. So the user can chose if they want longer or shorter audio split 🚀 — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC246XUI6NR6LK5T7HSJVLL3SBUPBAVCNFSM6AAAAACF3H4YACVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZWGYYTGNY> . You are receiving this because you were mentioned.Message ID: ***@***.***>