AudioSpectrumAnalyzer displays to early (16 Viewers)

[Lightning303]

Hey,

while looking into the AudioSpectrumAnalyzer to figure out how it is using GetFFTData and what it is doing with it exactly, i noticed that it displays the graph to early.

So lets say you listen to a song with a lot of beats, the bars peak ~1 second before you can hear the actuall beat. Also very mptoceable when listening to an audiobook. While it is quite, you can see that the narrator is going to speak in about a second.
Logs show nothing special, just that its loading a new window.

Spoiler

[2014-11-03 01:08:41,620] [69758  ] [InputMgr ] [INFO ] - WorkflowManager: Pushing workflow state 'AudioFullscreenContent' (id='82e8c050-0318-41a3-86b8-fc14fb85338b') onto the navigation stack...
[2014-11-03 01:08:41,621] [69759  ] [InputMgr ] [DEBUG] - WorkflowManager: Loading GUI model 'd8998340-da2d-42be-a29b-6d7a72aea2dc'
[2014-11-03 01:08:41,622] [69760  ] [InputMgr ] [DEBUG] - WorkflowManager: Using workflow model with id 'd8998340-da2d-42be-a29b-6d7a72aea2dc' for new workflow state '82e8c050-0318-41a3-86b8-fc14fb85338b'
[2014-11-03 01:08:41,623] [69761  ] [InputMgr ] [DEBUG] - WorkflowManager: Entering workflow state 'AudioFullscreenContent'
[2014-11-03 01:08:41,623] [69761  ] [InputMgr ] [DEBUG] - WorkflowManager: Deactivating predecessor workflow model '4cdd601f-e280-43b9-ad0a-6d7b2403c856'
[2014-11-03 01:08:41,624] [69762  ] [InputMgr ] [DEBUG] - WorkflowManager: Entering model context with workflow state '82e8c050-0318-41a3-86b8-fc14fb85338b' (old state was '062952bd-efa5-42fe-bf6b-63af61308a79') in new workflow model 'd8998340-da2d-42be-a29b-6d7a72aea2dc'
[2014-11-03 01:08:41,625] [69763  ] [InputMgr ] [DEBUG] - WorkflowManager: Compiling menu actions for workflow state 'AudioFullscreenContent'
[2014-11-03 01:08:41,625] [69763  ] [InputMgr ] [DEBUG] - WorkflowManager: Tidying up...
[2014-11-03 01:08:41,626] [69764  ] [InputMgr ] [DEBUG] - ScreenManager: Preparing to show screen 'FullscreenContentAudio'...
[2014-11-03 01:08:41,626] [69764  ] [InputMgr ] [DEBUG] - ScreenManager: Loading screen from file path 'C:\Program Files (x86)\Team MediaPortal\MP2-Client\Plugins\Media\Skin\default\screens\FullScreenContentAudio.xaml'...
[2014-11-03 01:08:41,629] [69767  ] [InputMgr ] [DEBUG] - WorkflowManager: Attaching GUI model 'ca6428a7-a6e2-4dd3-9661-f89cebaf8e62' to workflow state '82e8c050-0318-41a3-86b8-fc14fb85338b'
[2014-11-03 01:08:41,643] [69781  ] [InputMgr ] [INFO ] - WorkflowManager: Screen was updated by workflow model
[2014-11-03 01:08:41,643] [69781  ] [AMQ 'ScreenManager'] [DEBUG] - ScreenManager: Showing screen 'FullscreenContentAudio'
[2014-11-03 01:08:41,647] [69785  ] [AMQ 'SwitchBrowseModeAction'] [DEBUG] - WorkflowManager: Attaching GUI model '4cdd601f-e280-43b9-ad0a-6d7b2403c856' to workflow state '82e8c050-0318-41a3-86b8-fc14fb85338b'
[2014-11-03 01:08:41,664] [69802  ] [DX Render] [DEBUG] - ScreenManager: Closing screen 'LocalMediaNavigation'

I was running the FEAT_ConfigSort branch.

Edit:
So i added the VUMeter effect to AtmoLight, using AudioSpectrumAnalyzer as a tamplate. I see the same problem here. So the problem rather is that GetFFTData gives us values from the future. I was expecting the values to be in sync with what i hear.

 

[morpheus_xx]

@hwahrmann do you know the GetFFT function handling of BassPlayer better? I think there might be a gap between playback stream and "statistics" stream

 

[hwahrmann]

Only thing i can imagine is that the GetFFT comes from a decoded string and there is latency with the playback buffer

 

[morpheus_xx]

while looking into the AudioSpectrumAnalyzer to figure out how it is using GetFFTData and what it is doing with it exactly, i noticed that it displays the graph to early.

I've checked the implementation of the "VizStream" (only used for visualization): it creates an additional output stream that uses a RingBuffer to peek samples from. There is a calculation how big the delay should be:
https://github.com/MediaPortal/Medi.../PlayerComponents/PlaybackBuffer.cs#L195-L206

We already have a setting to control the milliseconds to add as offset:
You might change it manually inside C:\ProgramData\Team MediaPortal\MP2-Client\Config\MediaPortal.UI.Players.BassPlayer.Settings.BassPlayerSettings.xml "VizStreamLatencyCorrectionMilliSecs" property.

IMO a manual correction should not be required, but on the other hand I don't know yet how to calculate it better

 

[morpheus_xx]

Das sieht cool aus . Wenn du noch einen Patch für MP2 bereitstellst, der solche Anzeigen erlaubt, wäre das genial!

Kannst du die Sources bereitstellen?

 

[morpheus_xx]

bytesRead := BASS_ChannelGetData(player.Channels[0].hChannel, @newFFT, BASS_LEN);

Das machen wir derzeit im Prinzip genau so:
https://github.com/MediaPortal/Medi...UI/Players/BassPlayer/BassPlayer.cs#L433-L440

Grund für den extra "VizStream" ist, dass beim gleichzeitigen Lesen vom Channel zur Wiedergabe und zusätzlich zur FFT die Wiedergabe nicht passte, sie lief doppelt so schnell.

Hier wird der "VizStream" angelegt: https://github.com/MediaPortal/Medi.../PlayerComponents/PlaybackBuffer.cs#L225-L269

 

[morpheus_xx]

Die frage wäre warum benötigst du 2048 (linker Kanal) und das selbe nochmal für den rechten also 4096 Samples für das Spectrum?
würden da nicht so wie bei mir MAX (0..512 -1 * 2) 1024 Samples
für jeden Kanal also 512 vollkommen ausreichen?

Gute Frage, hätte ich den Code selber geschrieben, könnte ich sie vielleicht beantworten

Ich denke, ich werde die FFT-Daten besser vom Mixer abgreifen, da wir diesen sowieso für Kanal-Mapping von 5.0 Streams einbauen müssen (@Helios61, war es das Problem?)

@EWeiss: Hättest du Lust, ein paar Änderungen am MP2 BassPlayer-Code vorzunehmen? Kennst du dich mit C# aus?

 

[azzuro]

Emil, we know you have make big rework on Viz & Also Atmowin ( for mine ) .
I hope you can help morpheus on MP2 side, for improve it, on Audio support / Viz and maybe other stuff .

Emil, wir wissen, haben Sie machen große Nacharbeit auf Viz & Auch Atmowin (für meine).
Ich hoffe ihr könnt Morpheus auf MP2 Seite helfen, denn zu verbessern, auf Audio-Unterstützung / Viz und vielleicht andere Sachen.

 

[morpheus_xx]

Da die Visualisierung derzeit zu früh kommt, müssten wir dort eine entsprechende Verzögerung berechnen, basierend auf dem aktuellen Wiedergabe-Stream?

Der aktuelle Code benutzt einen AudioRingBuffer (https://github.com/MediaPortal/Medi...I/Players/BassPlayer/Utils/AudioRingBuffer.cs), welcher einfach eine Menge an Daten zwischenspeichert.

Die Frage ist nun, sollten wir die vorhandene Implementierung so ändern, dass das Delay zum Stream passt? Oder sollten wir die FFT-Daten von einem Mixer abgreifen, wie es hier steht: http://www.un4seen.com/forum/?PHPSESSID=2cqekr4h17otreck502t3fbe34&topic=15552.msg108391#msg108391.

Der Mixer wird allerdings derzeit nur für WASAPI-Ausgabe im "Shared" Mode (nicht exklusiv) verwendet, um die Samplingrates anzupassen: https://github.com/MediaPortal/Medi...OutputDevices/WASAPIOutputDevice.cs#L172-L182

Ich denke, die richtige Stelle für den Mixer ist https://github.com/MediaPortal/Medi...rs/BassPlayer/PlayerComponents/UpDownMixer.cs. Die Klasse ist derzeit nur ein "Passthrough"-Stream, der noch nichts macht.

 

[morpheus_xx]

Wo liegt der letzte Source?

Der aktuellste "stable" branch ist "dev": https://github.com/MediaPortal/MediaPortal-2/tree/dev

Welche Vis (Spectrum) verwendet ihr zum testen?

Die Darstellung selbst verwendet ein eigenes Control, welches Balken generiert und über RenderTransforms animiert: https://github.com/MediaPortal/Medi...a/Controls/AudioSpectrumAnalyzer.cs#L474-L554