@Boerge1 Zunächst mal vielen Dank für issue_195 und die zügige Antwort auf mein „Testergebnis“. Leider hast Du Recht, dass ich den langsamen Player habe. Bei der Bestellung eines DF-Players habe ich keine Möglichkeit gefunden, Player mit einem bestimmten Chipsatz zu bestellen. Schein ein wenig wie „Bingo“ zu sein.
Da aber vermutlich viele andere das gleiche Problem mit dem Player haben, sollten wir uns in der SW auf Funktionen beschränken, bei denen diese Trägheit des Players nicht so sehr offensichtlich wird. Mit diesem Ergebnis würde ich den Wunsch nach einem negativen Quittungston wieder fallen lassen, da das Feature im Zusammenhang mit dem trägen Player auf mich eher störend als hilfreich wirkt.
Zum abschließenden Test, habe ich meinen TonUINO noch auf einen Player der Leiterkartenpiraten umbauen können (natürlich mit Anpassung des defines und des Timings), aber selbst das brachte kein befriedigendes Ergebnis:
Man kann zwar kurz das Anspielen der Tracks vor und nach dem Quittungston hören, den Quittungston (263.mp3) selbst aber nicht (ist hier der Player dann zu schnell ?). Das kurze Anspielen der Tracks wirkt so eher wie ein Störgeräusch in der Ausgabe.
Muss es denn tatsächlich ein Advert-Track sein, wenn es so aufwändig ist, diesen zu starten ?? Ausschlaggebend sind aber m. M. nach die ca. 4 Sekunden bis zur Reaktion - so geduldig sind meine User eher nicht (und ich auch nicht).
Da der DF-Player ein kritisches Bauteil mit hoher Variabilität ist, denke ich, wir sollten die Idee des negativen Quittungstones an dieser Stelle begraben und die Funktion wie im issue_188 implementiert beibehalten.
Bei ungeduldigen Usern könnte es daher auch zu einem unbeabsichtigten „long press pause“ kommen, durch den dann der TonUINO „schlafen gelegt“ wird.
Sollten es nur wenige Codezeilen sein, wäre es ev. einen Versuch mit der erweiterten Logik zu „long press pause“ , wie weiter oben beschrieben, wert, um zu sehen, wie sich das anfühlen würde.
Vielen Dank an @Boerge1 für’s „mitgehen“ bei dieser Idee und die Unterstützung.
