brutefir - Störgeräusche bei double precision

Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

brutefir - Störgeräusche bei double precision

Beitrag von Buschel »

Hallo zusammen,

in meinem Setup habe ich gestern überrascht festgestellt, dass brutefir Störgeräusche erzeugt, wenn ich eine interne Rechengenauigkeit von 64 bit aktiviere:

Code: Alles auswählen

float_bits: 64;
Die Störgeräusche äußern sich als Spratzeln/Klicken und hören sich ähnlich an wie Übersteuerungen, allerdings signalisiert brutefir keinerlei Übersteuerungen. Sie sind stark abhängig vom Titel (besonders anfällig ist hier "Don't give up" von Peter Gabriel) und hängen vom anzuwendenden Filter ab. Bei Acourate-Filtern mit Exzessphasenkorrektur fallen die Geräusche stark störend auf, bei der minimalphasigen Version dieser Filter sind die Geräusche kaum wahrnehmbar. Ich nehme mal an, dass das an der Struktur der Impulsantwort liegt (Maximum in der Mitte oder am Anfang des Filters). Die Störgeräusche scheinen keine drop-outs zu sein, die CPU-Last liegt bei 5-10% (nur wenig höher als bei 32 bit Genauigkeit) und auch andere Partitionsgrößen haben keinen nennenswerten Einfluss.

Weitere Infos zur Umgebung:
- i3 NUC
- Ubuntu 14.04 64 bit (lowlatency)
- FIR mit 65k taps bei 48 kHz

Habt ihr eine Idee woran das liegen könnte? :roll:

Viele Grüße,
Andree
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Andree,

welche Partitionsgröße verwendest Du?
Du kannst mir auch mal gern das Filter zusenden.

Grüsse
Uli
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Uli,

die Partitionierung ist auf

Code: Alles auswählen

filter_length: 512,128;
gesetzt. Wie gesagt, auch größere Partitionen (gestestet bis 4096) verändern das Verhalten nur unwesentlich.

Nachvollziehen kann ich das mit allen Filtern, die ich noch auf dem NUC habe. Ich habe dir über PM zwei aktuell von mir verwendete Filter zugesendet.

Soll ich noch einen Ausschnitt vom Titel hochladen?

Viele Grüße,
Andree
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Die Filter sehen erst einmal ok aus.
Also ich hab da eigentlich immer lieber 4096,16 oder sogar 8192,8 verwendet als 512,128.

Es wäre im übrigen noch zu prüfen, mit welcher Buffersize die Soundkarte arbeitet. Insofern würde ich da mit 1024 samples buffersize arbeiten.

Zumindest macht man damit erst einmal nichts falsch. Kleinere Puffer kann man dann immer noch realisieren, solange eben bis es droppt.

Grüsse
Uli
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Uli,

daran, dass die Filter ok sind, hatte ich auch nicht wirklich gezweifelt -- ist aber gut zu wissen, dass du das auch so siehst. :wink:

Die Partitionierung ist deswegen so klein, weil ich auch den Ton zu Filmen über brutefir laufen lasse. Bei größeren Partitionen wird sonst der delay zu groß.

Der Knackpunkt ist ja, dass erst mit double precision die Fehler auftreten, mit single precision sind sie zumindest nicht spontan wahrnehmbar. Und das, ohne dass es zu irgendwelchen Fehlermeldungen durch brutefir kommt. Um interne Übersteuerung auszuschließen, habe ich gestern auch die Filter selbst mit einer Attenuation von 2 dB versehen, die Spratzler bleiben hörbar...

Ratlose Grüße,
Andree
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Andree,

float_bits: 64; kann ja auch eine entsprechend höhere CPU-Last bedeuten.
Insofern würde ich mich wie bereits geschildert von oben nähern, also zuerst große Puffer verwenden. Und schauen ob es damit problemlos klappt. Dann die Buffer solange verkleinern, bis Störungen auftreten.

Danach kannst Du entscheiden, ob Du den nötigen Puffer bei 64 bit akzeptieren kannst, andernfalls eben auf 32 bit umsteigen. Meines Erachtens sollte das für Film auch reichen.

Grüsse
Uli
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Uli,

die Last bei 64 bit und einer 512x128 Partitionierung liegt bei nur 5-10%. Wie von mir im Eingangsbeitrag beschrieben tritt der Fehler auch bei größeren Partitionen auf -- getestet mit 1024, 2048 und 4096. Das Geräusch ist außerdem stark abhängig vom Titel und vom Filter. Das passt nicht zu deiner Theorie, dass die Puffergröße die wesentliche Rolle spielt...

Viele Grüße,
Andree
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Andree,

ich hab aber zumindest noch was zum Puffer der Soundkarte geschrieben. Der kann ja evtl. auch zu klein sein.
Und soweit ich mich erinnere maht es immer Sinn mal mit amixer die Soundkarteneinstellungen zu checken.

Grüsse
Uli
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo nochmal,

wenn ich über

Code: Alles auswählen

$ cat /proc/asound/card.../pcm.../sub.../hw_params
die Puffergrößen anschaue, sehe ich krumme Werte, während ich brutefir laufen lasse. Bei allen Partitionsgrößen N<=4096 sehe ich

Code: Alles auswählen

period_size: N
buffer_size: 14563
Bei Partitionsgrößen N>=8192 (dazu muss <allow_poll_mode: true;> gesetzt sein) ergibt sich

Code: Alles auswählen

period_size: 7281
buffer_size: 14563
Anmerkung: Selbst bei N>=8192 ist das Geräusch nur schwach, aber weiterhin hörbar.

Wenn ich eine 44,1 kHz wav-Datei über den Standardplayer wiedergebe, sieht die Konfiguration wie folgt aus:

Code: Alles auswählen

period_size: 44100
buffer_size: 88200
Viele Grüße,
Andree
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Andree,

es tut mir leid, das übersteigt meine schwindenden Linux-Kenntnisse. :(
Es soll ja hier noch ein paar Brutefir/Linux-Spezialisten im Forum geben., vielleicht können die helfen.

Grüsse
Uli
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Trotzdem Danke für deine Hilfe :cheers:
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hi Andree

Könntest Du Deine Brutefir-Config mal einstellen?

Ich habe schon wüste Scherereien gehabt mit
dither: true;
in Kombination mit
device: "alsa" { device: "hw:0,0"; };

Deshalb mal 2 verblindete Schüsse in die dunkle Nacht des Output-Moduls hinaus:

- 1. Falls Du Dithering eingeschaltet hast, dann schalte dies doch mal probeweise aus
- 2. Versuche mal, statt über den ALSA Ausgang (device: "alsa" { device: "hw:0,0"; }) über eine Pipe an aplay zu übergeben. So à la

output "OUT_L","OUT_R" {
# device: "alsa" { device: "hw:0,0"; };
device: "file" { path: "/dev/stdout"; };
channels: 2/0,1;
sample: "S32_LE";
# sample: "FLOAT64_LE";
# dither: true;
dither: false;
};

und dann auf der shell brutefir in einer pipe gemeinsam mit aplay aufrufen.
$ brutefir blahconfig -quiet | aplay --buffer-size=1024 --channels=2 --device=hw:1,0 --format=S32_LE --rate=96000 -t raw

... natürlich mit den bei Dir passenden Parametern für die brutefir-config und für aplay

Sehr hübsche und erweiterte Konfigurationsoptionen bietet Dir (leider aktuell(?) bloss 2-kanalig) playhrt von Frankl, anstatt aplay.
$ brutefir ... | playhrt ...
Es lohnt sich, sich mal auf seiner Site umzusehen: http://frank_l.bitbucket.org/stereoutils/player.html

Grüsse
Simon
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Simon,

meine problematische brutefir config sieht wie folgt aus:

Code: Alles auswählen

##
## DEFAULT GENERAL SETTINGS
##
float_bits: 64;			# internal floating point precision
sampling_rate: 48000;		# sampling rate in Hz of audio interfaces
filter_length: 512,128;		# length of filters: 65536 = 512 * 128
overflow_warnings: true;	# echo warnings to stderr if overflow occurs
show_progress: false; 		# echo filtering progress to stderr
max_dither_table_size: 0; 	# maximum size in bytes of precalculated dither
allow_poll_mode: false; 	# allow use of input poll mode
modules_path: "."; 		# extra path where to find BruteFIR modules
monitor_rate: false; 		# monitor sample rate
powersave: true; 		# pause filtering when input is zero
lock_memory: true; 		# try to lock memory if realtime prio is set

##
## LOGIC 
##
logic: "cli" { port: 3000; };

##
## OUTPUT 
##
output "out_left", "out_right" {
  device: "alsa" { device: "usbaudio"; ignore_xrun: true;};
  sample: "S32_LE";
  channels: 18/0,1;
  delay: 0,0;
  maxdelay: -1;
  individual_maxdelay: -1,-1;
  mute: false,false;
  dither: false;
};

##
## INPUT
##
input "in_left", "in_right" {
  device: "alsa" { device: "usbaudio"; ignore_xrun: true;};
  sample: "S32_LE";
  channels: 18/4,5;			# number of open channels / each channel
};

##
## FILTER definition
##
coeff "drc_left" {
       filename: "./sink_6dB_boost_1dB/Cor1L48.dbl";
       format: "FLOAT64_LE";     # file format
};
coeff "drc_right" {
       filename: "./sink_6dB_boost_1dB/Cor1R48.dbl";
       format: "FLOAT64_LE";     # file format
};

##
## FILTER application
##
filter "main_left" {
  from_inputs: "in_left";
  to_outputs: "out_left";
  process: -1;
  coeff: "drc_left";
  delay: 0;
  crossfade: false;
};
filter "main_right" {
  from_inputs: "in_right";
  to_outputs: "out_right";
  process: -1;
  coeff: "drc_right";
  delay: 0;
  crossfade: false;
};
Das alsa device "usbaudio" ist wie folgt definiert:

Code: Alles auswählen

#
# USB audio
#
pcm.usbaudio {
	type hw
	card 2
	device 0
	format S32_LE
	channels 18
	rate 48000
}
Soweit ich das beurteilen kann ist das ziemlich straight forward, ohne dither und andere Spielereien. Sobald ich die config wieder auf

Code: Alles auswählen

float_bits: 32;
setze -- damit höre ich jetzt gerade -- läuft die Wiedergabe soweit ich beurteilen kann problemlos.

Der Versuch mit der Pipe zeigt das gleiche Verhalten. Auch wenn ich nicht mehr von der Soundkarte lese, sondern nur noch von einer Datei lese. Sobald double precision benutzt wird, treten die Störgeräusche auf...

Viele Grüße,
Andree

PS: Habe heute nochmal die Focusrite 2i2 angeschlossen. Dort tritt das Phänomen genauso auf.

PPS: Deine Idee mit der Pipe hat mich darauf gebracht, dass ich einfach mal die gesamte USB-Audiointerface-Mimik ausblende. Ich habe als Input für brutefir eine Datei genommen, den Output habe ich wiederum in eine Datei geschrieben. Und siehe da: Der Fehler tritt weiterhin auf! Damit ist wohl klar, dass das Problem irgendwo innerhalb der double precision Verarbeitung selbst liegt... Als Schmankerl hier mal Screenshots der Spektrogramme des Outputs bei single und double precision. Die Unterschiede sind deutlich sichtbar (und hörbar).

Bild
single precision

Bild
double precision

Und nu? :roll:
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo nochmal,

nachdem jetzt klar war, dass irgendetwas mit brutefir selbst nicht in Ordnung war, habe ich mir die installierte Version genauer angesehen. Die bisher laufende vorkompilierte Version v1.0l von brutefir hatte ich per Ubuntu Software-Center installiert. Diese Version ist nicht aktuell. Darüberhinaus wurde auf der brutefir homepage wurde darauf hingewiesen, dass es Probleme mit Artefakten gegeben hat, falls kein offizieller gcc Compiler eingesetzt wurde.

Selbst ist der Mann: fftw-3.3.4 heruntergeladen, für double und single precision kompiliert und installiert. Dann brutefir 1.0m heruntergeladen und installiert (benötigte zum Compilieren noch flex, libjack-dev und libjack0). Und jetzt der Lohn der Arbeit: Der Fehler ist damit behoben! :cheers:

Allerdings ist auch die CPU Last im Betrieb sowohl bei single als auch double precision fast doppelt so hoch. Mal schauen, ob ich da noch an den Compileflag herumschrauben kann... Aber das mache ich erst morgen...

Gute Nacht,
Andree
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Hallo Andree,

schön, dass Du eine Lösung gefunden hast. Nach der brutefir Dokumentation wurde in der neuesten Version v1.0m insbesondere ein Problem mit SSE/SSE2 gefixt, vielleicht war das bei Dir relevant. Teilweise wurde alter Assemblercode ausgebaut, das könnte das Programm eventuell etwas langsamer machen. (Manchmal auch schneller, weil Compiler besser optimieren können).

Ich benutze immer selbst kompilierte brutefir, auf einigen Systemen konnte ich die Geschwindigkeit durch gcc-Optionen verbessern, z.B. mit den passenden Argumenten für -mcpu und -mfpu oder dem Schalter -funsafe-math-optimizations.

Viele Grüße,
Frank
Bild
Antworten