make translation audio depend on main audio connection / echo test
current state
when leaving the audio connection via 
, the connection to the translation audio stays active or is in undefined state
also it is possible to join as "listen only" and have translation audio active
goal
- the translation audio should only be available when the main audio is successfully connected (not via "listen only")
- translation audio buttons should only be shown when there is an active main audio connection
- the user should leave both, the main audio and the translation audio when clicking on
- upon reconnecting to audio, both connections should be established using the device settings from echo-test
- in case there are errors, when connecting to main audio, do not make translation audio available
Activity
- A deleted user
changed milestone to %WE update 21-2
assigned to @toni.beier
mentioned in issue #55 (closed)
this would mean, choosing a language channel is not possible if a user chooses "listen only".
@christian.zange What do you think about it? how should "listen only" be handled here?
@toni.beier @Beier what would be the technical implications, e.g. concerning output devices?
i added #68 (closed) for this
mentioned in issue #68 (closed)
Usability and predicability is the main goal for me, meaning:
-> If I listen only - I can of course not be a translator - but I can very well listen to the audio from the translation. If we change this, and say: No you cannot listen to translation - we add additional confusion to the whole BBB topic - and the UI becomes worse (you can listen only - but if you want to listen to languages, you need to select the mic?!)
-> Yes, the translation devices should be bound to what ever is selected during the echo test. I understood this is now the case @Beier? We will have a testing session on this one tomorrow.
-> when leaving the audio, translation devices should also be disconnected.
-> in case of any error during connection? What type of errors are you referring to - and if you do not provide audio then, how will we understand what is going on, if some people fail to have translation.
With the listen only business: I personally do not like this option, because I have made the experience that it simply confuses people. The moderators can deactivate mic if needed. But as long as it is a fixed feature, it should work as expected.
My understanding is that the listen-only option is implemented differently, so that it scales better with many users. It is like listening to web-radio instead of participating in an audio-conference with muted mic. Thats why there is no echo-test. I am not sure, if it is (easily) possible to assert that the same output device is used for the translation channels for this.
if it is feasible, i would like to have listening to translation channels available in "listen-only" mode.
I would like to avaoid having issues with multiple output devices in "listen-only" mode that are solved in "normal" mode. That would lead to confusion..
to better separate the issues lets continue this discussion in #68 (closed) after the developers have given their opinion.
Please find our latest test attached. I think that I managed to handle the default device etc. and it was working (but I could not hear myself unfortunately) - but listening to the other translators of our team was not working as well. (a) Susanna was almost not hearable (b) Franziska was okay - but not the same as in the room.
It was quite the same experience like in our last test - so I did not recognise any change. I was able to enforce the right mic by using the default mic setting on the Mac - which is then recognised by BBB and I can see that BBB identifies this as the default Mic - and proposes this as the Mic to use.
For my colleagues it seemed impossible to enforce any Mic - also they also changed this configuration. But it was not like that the system would take the Mic identified in the echo test. The system takes the default Mic.
Okay - yes sorry, you are right. So this is useless - but to keep the story short:
Same / worse result than on our session:
- Susanna was impossible to hear . just some faint noises - while totally fine on the floor
- Franziska was OKAY to hear - but less quality as on the floor
- Only myself managed to be hearable with equal quality on floor and translation, using the default mic setting.
Susanna and Franziska tried to do so was well - but it was not successful. The system did not take the right mic automatically - I had to set even mine on default in system settings to achieve this. Otherwise my sound was also different. So no change so far from the last test, that we did together.
We are again not able to reproduce this. Could we please have a description of
- hardware used
- operating system and version
- browser and version
- attached microphones
- screenshot of input devices that can be selected in system settings
Ideally Susanna or Franziska are available for another session and share their screen with us, so that we can follow in the Javascript Console (F12) which input is being selected or how the browser is choosing a device on their hardware.
-
I have now access to a Lenovo with Windows 10 and activated again auto recording of all channels https://git.fairkom.net/clients/wechange/bbb-livetranslation/-/issues/20#note_28369 so that we can better hear what happens. Will do some further testing later today and tomorrow.
I do not expect, that it is the LENOVO or Windows 10 specifically - I guess those are very common devices. But it might be a problem, if you predominantly work with LINUX devices, that might work different. Most of our users use Windows unfortunately ;-). I am a Mac-User - and I also have usually better control on device settings etc. - which makes my user experience usually better, than what windows colleagues experience. But Windows is, what matters - as most users have Windows.
I will invite to another test - only with testing we will fix this issue.
-
Eine etwas schlechtere Tonqualität konnte reproduziert werden, wenn gleichzeitig am Floor gesprochen wird und Übersetzerin an einem Windows Laptop sitzt (aktueller Edge Browser).
Hier bei ca Minute 3:44 counting 50-59 in English (listen here https://translation.meet-modular.com/downloads/64579100_2021-02-11-21-24-19.wav) was with parallel floor counting (listen here https://translation.meet-modular.com/b/rol-ago-ckc-2te), after 60 was without.
A) Wir hatten das unabhängig von Chrome oder Edge. Tatsächlich war das Ergebnis immer das gleiche.
B) "Gleichzeitig am FLOOR gesprochen" ist vermutlich der Standard-Anwendungsfall - oder? Denn schließlich wird das dort gesprochene ja übersetzt - oder verstehe ich da was falsch?
C) Was die "etwas schlechtere Tonqualität" angeht:
- Sprechen wir hier von einer anderen Tonquelle - und die Änderungen in der Tonqualität durch die Verwendung eines falschen Mikrofons?
- Oder sprechen wir von einer bisher unbekannten Einflussnahme auf die Tonqualität?
Wichtig dabei:
- Wir hatten auch einige Fälle, wo die Tonqualität anfangs halbwegs gut war - aber doch anders - und sich dann die Störungen doch gehäuft hatten.
- In 50% der Fälle war die Tonqualität von Beginn an so schlecht - also unverwendbar - siehe die von uns geteilten Videos.
Nun kann man schlecht voraussehen, was im jeweiligen Meeting passiert - aber wenn die Tonqualität nicht stabil ist, kann man das in einem größeren Übersetzungsevent - wo eh schon viel Stress ist - nicht einsetzen.
Edited by Zange Christian-
Klar ist dies ein Standardfall, dass jemand am Floor redet und gleichzeitig übersetzt wird.
Es klingt diesmal nicht nach Mikrofonwechsel, wenn ein Übersetzer auf Windows übersetzt, sondern nach einer Einschränkung bei der Audioverarbeitung. Bei unserem Test war der Unterschied gering, also durchaus noch verständlich, aber merkbar. @Beier schaut sich das heute an.
Edited by Roland Alton -
Testaufbau unter Laborbedingungen
440 Hz Sinuston per Lautsprecher
Lenovo Yoga Windows 10 mit Edge 88 ist Übersetzer EN (Roland)
HP Laptop mit Linux und FF 85 ist Floor (Roland)
Empfänger Windows 10 Chrome und Variante Firefox (Dennis)
-> wenn Floor an, war Übersetzung nicht / kaum mehr zu hören
Irgendwo passiert eine Noise Cancellation also der Floor wird beim Übersetzer subtrahiert.
Zusätzlich SuSe Linux Laptop mit FF (Dennis) -> der selbe Effekt
Das ist reproduzierbar.
Arbeitshypothese: Windows rechnet eine noise cancellation, also meint der Floor sei ein Störgeräusch und zieht das vom Mikrofon (Übersetzer) ab.
Next step: wir schauen uns an ob wir das noise cancellation für den Translation use case in Windows deaktivieren können.
Hier nochmal ein Audio-Sample https://workspace.think-modular.com/index.php/s/3PRy3nbS5qaS35r Code: BMNNTj7W
Diesmal kann man das halbwegs verstehen - aber die Qualität ist sicher nicht die gleiche wie im Floor. Außerdem wieder ein Problem mit dem Mischen - also Minute 1:28 Translator macht eine kurze Pause ... der Hauptraum kommt wohl für eine Sekunde durch - und anschließend bleibt es für ein paar Sekunden gemischt - dann "erholt" sich das System wieder und es ist wieder besser.
Wir haben hier eine ganze Reihe von Tickets, die sich mit der Audio-Qualität und den damit verbundenen Problemen beschäftigen. Ich kenne mich da nicht mehr ganz aus, schlage aber vor, alles was diese Frage angeht, in einem Strang zu bearbeiten - etwa hier - und die anderen alten Tickets dazu hiermit zu verknüpfen.
Ziel wäre aus meiner Sicht:
- Gleiche Qualität wie im Floor
- Keine Mischung zwischen Floor und Übersetzungskanälen
ich habe eine beschreibung von audioproblemen mit webrtc und Lösungsvorschlägen gefunden und hier gepostet: https://git.fairkom.net/clients/wechange/bbb-livetranslation/-/issues/55#note_30902 In den code hier habe ich noch nicht reingeschaut..
