Optimierung von Pixel

[Medium]

Zitat von EWeiss:

Aber ich verwende davon nur 160 Floats.

Du ja, aber die Bass.dll der du genau diesen Buffer zum rein Schreiben gibst schert sich nicht darum. Mit dem Parameter "BASS_DATA_FFT512" forderst du explizit 256 (danke für die Klärung) Werte (Floats) an, und so viele schreibt die DLL dann auch. Völlig egal auf welche Länge das übergebene Array gesetzt wurde. (Genau genommen weiss die DLL nichtmals, dass es ein Array ist. Nur, dass sie ab Speicheradresse X (=Pointer(Buffer), aber das weiss nur dein Code, nicht die DLL) seine 256 Floats schreiben darf. Dass sie das auch wirklich darf, das ist in deinem Verantwortungsbereich.)

[EWeiss]

Zitat:

Dass sie das auch wirklich darf, das ist in deinem Verantwortungsbereich.)

Ah ok jetzt weiß ich was ihr meint.
Ich bin nur von meinem Code ausgegangen die Bass.dll hat mich dabei weniger interessiert
Gut das macht die Profis (Informatiker) aus.

Letztendlich habe ich mich nur um meinen Code gekümmert so das dieser Fehlerfrei läuft.
Wie oder ob die Bass.dll das abfängt liegt nicht in meinem ermessen.

Zumindest werden keine Exception geworfen.

Zitat:

Übrigens: Der Buffer-Overflow schlägt gnadenlos auf das Scanlines-Array zu. Der Code funktioniert nur, wenn man SetLength(Buffer, 256); verwendet.

Habe ich bedacht..
Und ja wird verwendet.

SetLength(Buffer, BUFFER_SIZE);

Zitat:

Würde es nicht mehr Sinn machen, nur die ersten paar Sekunden zu visualisieren und danach on-demand jeweils die nächsten paar Sekunden ab aktueller Abspielposition?

Das mache ich ebenfalls schon nur nicht in diesen Code vom Spectrogram.
Ich möchte nicht zur Laufzeit in Realzeit Rendern sondern erst das komplette Bitmap erstellen deshalb dieses Example.

Also ich möchte erst sehen wie das Spectrogram aussieht und dann mit "LineTo" anzeigen wo man sich gerade an welcher Position im Stream befindet.
Mit einem Loop könnte man dann später einen bestimmten Bereich immer wieder spielen. (Dafür muss ich aber vorher schon sehen wo ich mich befinde)

Realzeit Render, was ich nicht möchte

Delphi-Quellcode:

        begin
          OffsetX := 2; // normal 256x512
          for i := 0 to pred(Height) do
          begin
            MagLn := round(Sqrt(FFTData[i + 1]) * 3 * Width);
            k := Height - i - 1;

            x := BuffBMP.ScanLine[k];

            if bRTLScroll then
            begin
              //copy original scanline
              Move(x[OffsetX], x[0], (Width - OffsetX));

              //draw new pixels
              for m := 0 to pred(OffsetX) do
                x[Width - OffsetX + m] := MagLn;
            end
            else
            //Left to right
            begin
              //copy original scanline
              Move(x[0], x[OffsetX], (Width - OffsetX));

              //draw new pixels
              for m := 0 to pred(OffsetX) do
                x[m] := MagLn;
            end;
          end;
        end;

Zitat:

Eventuell kannst du noch etwas Performance herausholen, wenn du die Scanlines cached:

Werde ich mir mal genau anschauen.. Danke für den Code

Ich könnte das Bitmap noch verkleinern\zusammenschrumpfen und zusätzlich noch interpolieren
Aber ich möchte jedes Pixel sehen (etwas fürs Auge) und nicht alles zusammenstauchen nur damit es auf dem Bitmap beliebiger länge passt.

Mir ist auch klar das ich nur die ersten 512 Blöcke verwende und diese nicht den gesamten Frequenzbereich zurückgeben.
Deshalb kann ich für 44100 Hz, den Bereich von 22,5 kHz bis 0 (Nyquist-Transformation) nicht anzeigen.
Aber das sind bekannte Probleme.
Wichtiger ist erst mal die Performance (Geschwindigkeit)

Andere frage kann es sein das ScanLine nicht richtig funktioniert
weil das Spectrogram vertikal zeichnet und ScanLine horizontal arbeitet?

gruss

[Medium]

Zitat von EWeiss:

Wie oder ob die Bass.dll das abfängt liegt nicht in meinem ermessen.

Implizit schon, da ab dem Moment klar ist, dass keine (tatsächlichen) Längeninformationen übergeben werden, ab dem ein typloser Pointer übergeben wird. Aber das muss man natürlich erst mal wissen.

Zitat:

Zumindest werden keine Exception geworfen.

Wie gesagt: Glück! Solche Dinge sind nicht selten die Ursache für richtig fiese, extrem schwer zu findende Fehler, weil sie gerne Symptome an Stellen verursachen, die augenscheinlich so überhaupt nichts mit der eigentlich fehlerhaften Stelle zu tun haben.

[EWeiss]

Zitat:

Wie gesagt: Glück! Solche Dinge sind nicht selten die Ursache für richtig fiese, extrem schwer zu findende Fehler, weil sie gerne Symptome an Stellen verursachen, die augenscheinlich so überhaupt nichts mit der eigentlich fehlerhaften Stelle zu tun haben.

Danke für deine ausführliche Erklärung werde ich mir merken
Habe das Bitmap auf 256 hochgesetzt dauert jetzt zwar 5 Sek länger aber was soll's
Ich denke da kann man noch an verschiedenen stellen schrauben.

Wenn ich analysiert habe warum ScanLine nicht das gewünschte Ergebnis liefert.
wenn Pixel und ScanLine das gleiche liefern +- 1 Sec kann was nicht stimmen.

gruss

[Uwe Raabe]

Zitat von EWeiss:

Habe das Bitmap auf 256 hochgesetzt dauert jetzt zwar 5 Sek länger aber was soll's

Die Bitmap muss gar nicht größer werden, nur der Buffer. Allerdings musst du dann die Schleife anders aufbauen

Zitat von EWeiss:

Wenn ich analysiert habe warum ScanLine nicht das gewünschte Ergebnis liefert.
wenn Pixel und ScanLine das gleiche liefern +- 1 Sec kann was nicht stimmen.

Ich habe mal eine MP3-Datei (320kBit/s, 4:52 Dauer, 11,1 MByte) geladen. Die auf meinem System gemessenen Zeiten:

SetPixel: 4,0 s
ScanLine: 1,5 s
ohne Grafik: 1,3 s

Rechnet man die Basiszeit von 1,3 s runter, ergeben sich 2,7 Sekunden bei SetPixel und 0,2 Sekunden bei Scanline. Das ist immerhin ein Faktor von 13,5!

[EWeiss]

Zitat von Uwe Raabe:

Zitat von EWeiss:

Habe das Bitmap auf 256 hochgesetzt dauert jetzt zwar 5 Sek länger aber was soll's

Die Bitmap muss gar nicht größer werden, nur der Buffer. Allerdings musst du dann die Schleife anders aufbauen

Zitat von EWeiss:

Wenn ich analysiert habe warum ScanLine nicht das gewünschte Ergebnis liefert.
wenn Pixel und ScanLine das gleiche liefern +- 1 Sec kann was nicht stimmen.

Ich habe mal eine MP3-Datei (320kBit/s, 4:52 Dauer, 11,1 MByte) geladen. Die auf meinem System gemessenen Zeiten:

SetPixel: 4,0 s
ScanLine: 1,5 s
ohne Grafik: 1,3 s

Rechnet man die Basiszeit von 1,3 s runter, ergeben sich 2,7 Sekunden bei SetPixel und 0,2 Sekunden bei Scanline. Das ist immerhin ein Faktor von 13,5!

Die frage wäre mit meinem Example?
Wenn ja wie sieht die Aktualisierung aus?

Mariah Carey - Breakdown.mp3 320k, 10,8 MB
Pixel 5:97 sec (liegt daran weil mein Bitmap jetzt 256 Hoch ist)
ScanLine kann ich im Moment nicht testen.. muss erst den Fehler vom Medium Code beheben.
Fehler "Bereichsüberschreitung bei ZeilenIndex" wenn mein Buffer 256 groß ist.

gruss

[Uwe Raabe]

Zitat von EWeiss:

Die frage wäre mit meinem Example?

Hast du das irgendwo hier angehängt? Ich kann gerade nichts finden.

[Medium]

Zitat von EWeiss:

Fehler "Bereichsüberschreitung bei ZeilenIndex" wenn mein Buffer 256 groß ist.

Dann ist dein Buffer größer als das Bitmap hoch ist. (Oder du übergibst aus irgend welchen anderen Gründen eine Y-Koordinate ausserhalb des Bitmaps. Ohne konkreten Code schwer zu sagen.) Was diese Meldung sagt: "Du forderst eine Zeile im Bitmap an, die das Bitmap gar nicht besitzt." Also entweder eine Zeile < 0 oder >= Bitmap.Height.

Letztlich ist aber die Variante, die die Scanlines puffert, sicherlich schneller. Mich würde aber dennoch interessieren, wo das Problem mit meinem Vorschlag war, wo ein 1-zeiliges Bitmap gedreht ge-PlgBlt-ed wurde. Mangels Delphi kann ich das gerade nicht weiter testen, aber noch sehe ich mildes Potenzial darin.