AudioSpectrumAnalyzer displays to early (1 Viewer)

[Lightning303]

Die Änderungen aus diesem Post (https://forum.team-mediaportal.com/t...-displays-to-early.128263/page-4#post-1108618) sind also anscheinend nicht notwendig.

Doch sind sie, sorry!
Ich habe gerade nochmal mit Wasapi probiert und die Änderungen für GetFFTData von BassFan sind notwendig. Genauso muss GetChannelLevel angepasst werden um mit Wasapi zu funktionieren (habe ich gemacht, siehe Patch unten).
Jedoch funktoniert bei mir der Exklusive Modus von wasapi noch nicht synchron.

Ich habe mal einen Patch für alle bisherigen Änderungen gemacht, damit es übersichtlich bleibt.

 

[morpheus_xx]

Der Patch ist meiner Meinung nach noch nicht "richtig": er vermischt die Zuständigkeiten in der Prozesskette: die Klasse BassPlayer greift auf das Ausgabegerät zu und muss demzufolge alle unterstützen Ausgaben kennen (derzeit DirectSound und WASAPI).

Derzeit ist die Kette doch so:

      _upDownMixer.SetInputStream(_outputStream);
      _vstProcessor.SetInputStream(_upDownMixer.OutputStream);
      _winAmpDSPProcessor.SetInputStream(_vstProcessor.OutputStream);
      _playbackBuffer.SetInputStream(_winAmpDSPProcessor.OutputStream);
      _controller.OutputDeviceManager.SetInputStream(_playbackBuffer.OutputStream, _outputStream.IsPassThrough);

Input - > VST -> WinAmp DSP -> PlaybackBuffer -> Ausgabe Gerät
                               -> Mixer -> VizStream

Im Ausgabe Gerät über WASAPI wird noch ein eigener Mixer angelegt, wenn der Shared Mode verwendet wird.

Ich denke also, von der Kette her ist das in Ordnung. Das Problem wird aber in die Synchronisation (oder Kompensation der Latenzen) zwischen VizStream und Ausgabegerät sein.

 

[Lightning303]

Könntest du dir vielleicht die synchronität mit WASAPI im Exklusive Modus anschauen? Denn hier ist es bei mir immernoch asynchron.

DirectShow Direct Sound = Synchron
WASAPI = Synchron
WASAPI Exclusive = Asynchron

 

[morpheus_xx]

Verstehe ich jetzt nicht.
In welcher weise?
Du kommst nicht Drumherum einen Buffer zu verwenden und die Daten vom richtigen Device zu übernehmen.

Das hat nichts mit den tatsächlichen Funktionsaufrufen zu tun, sondern mit der Stelle im Code, wo sie erfolgen. Wenn also ein aktives OutputDevice (DirectSound/WASAPI) eigene Funktionen verwenden muss, um Daten mit *GetData zu liefern, muss der Code dort hinein. Ich kann das anpassen.

Du must Unterscheiden:
Bass = Kein Buffer, BASS_ChannelGetData
Mixer = BASS_MIXER_BUFFER, BASS_Mixer_ChannelGetData
Wasapi = BASS_WASAPI_BUFFER, BASS_WASAPI_GetData
Du verwendest Wasapi und versuchst dann Daten eines Streams zu analysieren?
Das funktioniert nicht Wasapi benötigt keinen Stream es holt sich die Daten direkt von Device.

Hier muss ich noch mal nachfragen: auch WASAPI wird mit einem Stream "gefüttert", so dass die ganze Processing-Kette vorher genau so abgearbeitet wird wie auch bei DirectSound.

Die Implementierung des VizStreams "zweigt" Daten parallel in einen eigenen Puffer ab, so dass dort immer Daten per *GetData abgegriffen werden können, ohne sich um das Ausgabedevice zu kümmern. Das ist unabhängiger (gut), beachtet die Latenzen der unterschiedlichen Ausgabegeräte nicht (schlecht). Daher die Delays.
Im Device wird das schon vorgesehen, denn es gibt ein passende Property:
https://github.com/MediaPortal/Medi...tputDevices/AbstractOutputDevice.cs#L111-L114
Die verwenden wir nur noch nicht und für WASAPI müsste ein passender Wert berechnet werden.

Ich werde am Wochenende noch etwas Zeit in das Thema investieren. Wir haben immerhin schon zwei Ansätze

 

[morpheus_xx]

Ich stelle gerade die Änderungen fertig, habe aber noch zwei Fragen:

• Wofür soll "GetWaveData32" genau verwendet werden?
• Ist es korrekt, dass WaveData.data = new float[1024]; and later accessed with Bass.BASS_ChannelGetData(..., WaveData32.Data32, 2048); ? Sieht aus, als passen die Größe?

 

[morpheus_xx]

Ich habe folgende Änderungen vorgenommen: https://github.com/MediaPortal/MediaPortal-2/commit/9ec99821c0ef7734fefb381d4624f7c551e47cb9
GetWaveData hat ein Argument, dass die gewünschte Menge an Daten festlegt.

 

[Lightning303]

Dank dir!
Ich habe mal FEAT_DSD_Support compiliert und getestet.
Jetzt ist alles synchron .

Eine Sache ist mir aber aufgefallen. Wenn ich WASAPI nutzte, höhrt es sich so an als ob nur der linke Kanal benutzt wird (kann ich leider nicht 100% bestätigen, da ich nur Laptop Boxen hier habe). Außerdem gibt GetChannelLevel auch nur für den linken Kanal Werte zurück.
Hab die beiden Werte mal in die log ausgegeben:

[2014-11-07 18:38:14,378] [22775  ] [AtmoLight VUMeter] [ERROR] - AtmoLight: -45,3004661158475, -unendlich
[2014-11-07 18:38:14,430] [22827  ] [AtmoLight VUMeter] [ERROR] - AtmoLight: -42,1780625533463, -unendlich
[2014-11-07 18:38:14,495] [22892  ] [AtmoLight VUMeter] [ERROR] - AtmoLight: -39,7305321564723, -unendlich
[2014-11-07 18:38:14,548] [22945  ] [AtmoLight VUMeter] [ERROR] - AtmoLight: -38,1383454904815, -unendlich
[2014-11-07 18:38:14,599] [22996  ] [AtmoLight VUMeter] [ERROR] - AtmoLight: -37,854226858731, -unendlich

 

[morpheus_xx]

Warum verwendest du BASS_SAMPLE_FLOAT ?
Wenn du es weist sollte dir klar sein das mit dem Setzen dieses Flag die Sample Daten zu 32-bit floating-point (Sytem.Single[]) konvertiert werden.

Ok, wenn das so ist, müssen wir die Argumente wie im restlichen Code anpassen:

  public bool GetWaveData32(int length, out float[] waveData32)
  {
  waveData32 = new float[length];
  // Note: length parameter is in bytes, but we like to get 32bit floats, so we need to multiply length with FloatBytes
  return _vizStream != null && Bass.BASS_ChannelGetData(_vizStream.Handle, waveData32, length * BassConstants.FloatBytes) == (int)BASSError.BASS_OK;
  }

Damit legt der Aufrufer fest, dass er 512 Float Samples will und wir fragen 512 * 4 bytes ab. Schon passt es, oder?

 

[morpheus_xx]

Was mir auffällt
Warum wird hier der wert nochmalig auf 0 gesetzt wenn dass schon vorher geschieht..
WASAPIOutputDevice

Ist ganz einfach, da im Fall, wo der Stream null ist, auch die Ausgabewerte gefüllt sein müssen. Frag den Compiler Und 0 für double wird intern konvertiert. Aber gut, sollte gleich als 0d geschrieben werden, da die Argumente doubles sind

 

[morpheus_xx]

Na gut mir scheint wohl niemand zu glauben.. aber egal.

Das hat nichts mit "nicht glauben" zu tun, ich kann dir nur manchmal sehr schwer folgen

Da du mehr Erfahrungen mit dem BassPlayer hast, versuche bitte die nötigen Änderungen vorzunehmen und einen Patch bereitzustellen. Ich sehe mir das ganze dann an!