AudioSpectrumAnalyzer displays to early (1 Viewer)

[Lightning303]

Das ganze hat mit AtmoLight erstmal garnichts zu tun. Ich habe mir den SpectrumAnalyzer angeschaut und festgestellt das er nicht 100% richtig funktioniert. Zu diesem Zeitpunkt hatte ich in Sachen SpektrumAnalyzer/VUMeter noch garnichts in AtmoLight für MP2 implementiert.

Habe mal ein Video gemacht wie es bei mir aussieht.
Wie man gut erkennen kann, ist es nicht synchron.

 

[Lightning303]

Bin ich der einzige der sieht das das nicht synchron ist? Die Balken fallen ab bevor der Typ aufhört zu reden, genauso steigen sie wieder an bevor er anfängt zu reden... Wenn ich die gleiche Datei in deinem kleinen Programm von Seite 1 (FFTGrid) benutzte ist alles super synchron.

Hab leider kein solche Datei, habe auch nicht wirklich Musik rumfliegen um etwas rauszusuchen dass das Problem besser darstellt.


Zum Thema AtmoLight, ja, ich brauche keine 2048 Samples, mir reicht einer . Ich möchte kein Spektrum verwirklichen, sondern ein VUMeter. Während MP1 hier eine Methode zur Verfügung stellt um den ChannelLevel abzugreifen (https://github.com/MediaPortal/Medi...sicPlayer/BASS/BassAudioEngine.cs#L2711-L2750), hat MP2 eine solche Methode noch nicht implementiert. Also habe ich mir den integrierten SpektrumAnalyzer angeschaut und diesen nachgeahmt.
Dieser arbeitet mit der GetFFTData Methode (https://github.com/MediaPortal/Medi...UI/Players/BassPlayer/BassPlayer.cs#L433-L440) welche im BassPlayer implementiert ist.
Und wenn mich nicht alles täuscht, ist diese mit 2048 Werten hardcoded (https://github.com/MediaPortal/Medi...ource/UI/Players/BassPlayer/BassPlayer.cs#L73).

Aber meine Implementierung ist erst einmal zweitranging, ich wollte einen Bug in einem MP2 eigenem "Produkt" aufzeigen .

 

[Lightning303]

Deine Test Datei:

 

[Holzi]

Bin ich der einzige der sieht das das nicht synchron ist?

Nee.

 

[Lightning303]

Es läuft also nicht vor sondern hinterher.
Der erste Ausschlag ist korrekt.

Ja, der erste Ausschlag sieht korrekt aus.
Aber das der Graph dem Sound hinterher läuft, dem muss ich widersprechen. Nach dem ersten Bing sehe ich doch den Graphen nach oben schneller bevor ich das 2te Bing höhre... also ist der Graph dem Sound vorraus!

Nicht unbedingt..
Denn wenn du einen VUMeter implementierst benötigt man kein FFT um diesen darzustellen.
Dem source vom AudioSpectrumAnalyzer dafür zu verwenden ist dann schlichtweg falsch.

Das mag ja gut sein das meine Implementierung in mein Plugin dann falsch ist, ändert aber rein gar nichts daran das der SpektrumAnalyzer Visualisierungs Effect in MP2 falsch ist. Und um diesen geht es hier hauptsächlich. Nicht um mein schlecht programmiertes Plugin.

 

[Lightning303]

Habe ich nichts von gesagt.
Wollte dir nur sagen wie man es richtig macht so das du nicht alles 2x fach machen must.

Ne, habe ich gesagt .

Ich habe jedenfalls eine GetChannelLevel Methode in ISpectrumPlayer implementiert und es damit versucht.
Leider habe ich es nicht hinbekommen das AtmoWin Dummy Fenster UND Audio gleichzeitig aufzunehmen, die verschiedenen Tools die ich versucht habe, haben alle immer nur entweder das eine oder das andere hinbekommen .
Jedenfalls sehe ich hier das gleiche Problem. Die Ausschläge kommen zu früh (vor dem Sound).
Ich gehe davon aus das die eigentlichen Audio Ausgabe gepuffert wird, während die FFT and ChannelLevel Daten nicht gepuffert werden.

Etwas was mir aufgefallen ist, bei der Umrechnung der Werte in dB mit Hilfe von LevelToDB, sagt die Seite die du verlinkt hattest (http://www.bass.radio42.com/help/html/5f031dfc-effe-35a9-c60d-21856e15a59e.htm) das der maxValue 32768 beträgt. Und wenn ich mir die Werte so ansehen, kommt das auch hin. MediaPortal1 hingegen benutzt 65535 (https://github.com/MediaPortal/Medi...sicPlayer/BASS/BassAudioEngine.cs#L2744-L2745).
Kannst du dazu was sagen? Ist es in MP1 falsch implementiert?

 

[Lightning303]

Jetzt nicht mehr mit meiner neuen DLL zur zeit nur für WASAPI. Rest kommt noch.

Jop mit WASAPI ist der SpektrumAnalyzer nun synchron

 

[Lightning303]

Super, Danke BassFan!!
Kann bestätigen, wenn wir UpdateVizLatencyCorrection() aus PlaybackBuffer entfernen, ist alles synchron!
Die Änderungen aus diesem Post (https://forum.team-mediaportal.com/...-displays-to-early.128263/page-4#post-1108618) sind also anscheinend nicht notwendig.

Ich habe ausserdem den max Wert in meinem Patch für GetChannelData von 32768 auf 65535 erhöht, wie BassFan vorgeschlagen hat. Gibt mir auch schönere Werte.
@morpheus_xx Würde mich freuen wenn du dir diesen Patch auch mal anschauen könntest und falls du keine Einwände hast zu MP2 hinzufügen würdest. Damit ich auch die richtigen Daten für meinen Effekt benutzten kann .

 

[morpheus_xx]

Super Ergebnisse soweit

Allerdings gibt es Probleme mit dem STOP Event einmalig wird immer noch auf BASS_ChannelGetData zugegriffen obwohl der Song schon zu ende ist.

Passiert das beim manuellen "Stop", oder auch wenn der Song endet? Lässt sich das nicht über ein Locking des Streams lösen?

41 Bars werden mit 2048 Samples analysiert. Das ist was ich nicht verstehe.
Warum? Das geht voll auf die Latency.. Na ja was soll's

Das ginge und ist resourcen schonender wenn man hier 256 nehmen könnte.

Davon ist nichts in Stein gemeißelt, wenn also andere Werte sinnvoller sind, passe ich es gerne an. Wir sollten uns aber auf was pratikables vertändigen.

Habe deinen Patch addiert kann aber keinen eigenen erstellen da ich nicht auf GitHub länger angemeldet bin.

Selbst ohne GitHub-Konto kannst du einen Patch erstellen lassen: entweder mit TortoiseGIT -> create patch (http://tortoisegit.org/docs/tortoisegit/tgit-dug-patch.html). Ich schaue dann die Änderungen komplett durch.

 

[morpheus_xx]

@morpheus_xx Würde mich freuen wenn du dir diesen Patch auch mal anschauen könntest und falls du keine Einwände hast zu MP2 hinzufügen würdest. Damit ich auch die richtigen Daten für meinen Effekt benutzten kann .

Ich sehe es mir noch im Detail an, aber ich denke wir übernehmen es so!