Hallo Tobias,
da gebe ich dir vollkommen Recht. Bei den Linux Ansätzen für ARM Architektur ist für jeden was dabei. Inzwischen habe ich noch den Treiber für den rtl8192cu Chip auf die blacklist gesetzt, da ich sonst das wlan ständig verliere. Seitdem blinkt die LED des wifi dongle, so wie es sein sollte, vorher leuchtete sie ständig. Dann läd ArchLinux (auf dem Archphile basiert) den treiber zweimal, was dann zu Verwirrung führt. Am besten ist also, wenn man ein ArchLinux basiertes System verwenden will einen wifi dongle zu verwenden, der einen anderen Chip benutzt, wie zum Beispiel:
https://wikidevi.com/wiki/TP-LINK_TL-WN722N
Inzwischen habe ich mpd auch so konfiguriert, dass es mit sox auf 96/32 sampelt. Je nach Originaldatei wird dann entweder upgesamplet, gar nichts gemacht oder downgesamplet. Die Bittiefe wird dann immer auf 32 bit umgerechnet. Frage an die Spezialisten, sollte das nicht Einfluss auf die Lautstärke nehmen? Bei mir bleibt es gleich laut (oder ist sox schlauer als ich vermute?).
Mit:
kann man überprüfen, ob das Upsampling funktioniert. Auf dem iphone verwende ich MOPD zum steuern von Archphile, da dieses ja keine eigene GUI hat wie Runeaudio oder Volumio. Man darf sich nicht davon täuschen lassen, das in MOPD immer noch die ursprüngliche Samplingfrequenz angezeigt wird. Da mpd keine Informationen über die transportierten Daten bezüglich Frequenz und Bittiefe weitergibt, vermute ich, dass MOPD diese Information aus den Metadaten auf der festplatte bezieht. Das Upsmpling statt findet, merkt man auch, wenn man top laufen lässt. Bei Volumio 1.55 lag die CPU-Auslastung, bei 176,4 kHz/32 bit bei meinem Odroid C1 bei schlappen 2,5 bis 3 % über alle 4 Kerne. Beim Upsampling von Redbook Format auf 96/32 läuft Archphile mit 10 bis 12 % CPU-Auslastung über alle vier Kerne und das obwohl ja keine Kapazität für die nicht vorhandene GUI benötigt wird.
Insofern Jörg (Jörhag) kann ich dir nur empfehlen, das auf deinem Pi mal aus zu probieren. du kannst dann ohne Qualitätsverlust die Laustärke digital regulieren und schwupps rein in die Genelecs direkt vom Pi aus. Raumanpassung machst du ja per GLM.
Da ich aber auch gerne Raumanpassung mit dem Odroid machen möchte, muss ich mich an brutefir ran wagen. Die pipe out ist in Archphile schon implementiert. Aber man muss sich seine brutefir_config selbst basteln. Dazu hätte ich ein paar Fragen an die Spezialisten (Tobias, Andrée, Simon, Frank etc.):
Ich habe auf dem Odroid das Verzeichnis
angelegt und darin folgende brutefir_config angelegt:
Code: Alles auswählen
float_bits: 32; # internal floating point precision
sampling_rate: 96000; # sampling rate in Hz of audio interfaces, da ich mit 96 kHz reingehe oder meint brutefir jetzt, dass mein DAC max. 96 kHz kann?
filter_length: 4096,16; # length of filters
overflow_warnings: true; # echo warnings to stderr if overflow occurs
show_progress: true; # 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
convolver_config: "~/.brutefir_convolver"; # location of convolver config file
logic: "cli" { port: 3000; };
## INPUT OUTPUT ##
input "left-in", "right-in" {
device: "file" {path: "/dev/stdin";};
sample: "S32_LE";
channels: 2/0,1;
};
output "left-out", "right-out" {
device: "alsa" {device: "hw:1"; ignore_xrun: true;};
#device: "file" {path:"/dev/stdout"; };
sample: "S32_LE"; # Ist das richtig? Ich möchte das brutefir 96/32 an also (und alsa an meinen DAC ausgibt)
channels: 2/0,1;
dither: false; # Tipp von Simon hier im Forum
};
## FILTER DEFAULTS ##
filter "l_filter" {
from_inputs: "left-in"/8.0;
to_outputs: "left-out"/0.0;
process: 0; # process index to run in (-1 means auto)
coeff: -1; # -1 means "copy"
delay: 0; # predelay, in blocks
crossfade: false; # crossfade when coefficient is changed
};
filter "r_filter" {
from_inputs: "right-in"/8.0;
to_outputs: "right-out"/0.0;
process: 0; # process index to run in (-1 means auto)
coeff: -1;
delay: 7; # predelay, in blocks
crossfade: false; # crossfade when coefficient is changed
};
Hier nochmal meine Fragen dazu:
Ist es richtig, die brutefir_config im Ordner /home abzulegen?
Ist es richtig als sampling rate die 96 kHz anzugeben, die brutefir von mpd immer geliefert bekommen wird?
Bezieht sich die sampling_rate auf denn Eingang oder den Ausgang?
Beim Output habe ich als sample "S32_LE" angegeben. Ist das richtig, wenn ich möchte, dass brutefir die Daten im Format 96 kHz/32 bit an alsa weiter gibt? Oder bezieht sich sample "S32_LE" auf etwas anderes? Und wenn ja auf was?
Zur Erklärung: Der Filter für den rechten Kanal verzögert den Kanal um sieben Blöcke, das klingt dann schräg, beweist aber das die pipe und brutefir funktionieren. Dann kann man richtige Filter einstellen.
Da ich das Umschalten zwischen den Filtern für verschiedene sampling rates nicht sehr kommod finde, lass ich erst alles auf 96/32 rechnen, um dann in brutefir nur einen Filter zu brauchen.
Wenn ich auf 32/192 hochrechnen ließe, könnte ich den DAC im NOS Modus betreiben, da ergäbe sich ndann eine Schnittmenge mit Bernd Peter, allerdings wäre ich dann darauf angewiesen, dass sox die beim Upsamplen verwendeten Filter gut wählt, da ich nicht weiß, ie ich diese Wahl beeinflussen könnte, oder selber welche erstellen könnte, die sox dann einsetzen würde.
Ich habe ja schon verstanden, dass man für jede Abtastfreuenz einen eigenen Filter braucht. Gilt das auch für verschiedene Bittiefen?
Muss die Bittiefe des Filters mit der Bittiefe des Datenstroms (in meinem Fall 32 bit) überein stimmen?
Falls ja müsste ich mal schauen, ob DRC oder REW es erlauben Filter mit 32 bit zu erstellen.
Oder kann ich einen Filter mit 24 bit erstellen und ihn dann auf 32 bit hochrechnen (unter Beibehaltung der Abtastrate)?
Da fällt mir gerade siedend heiß ein, dass mein Steinberg UR12 sowieso nur 24 bit kann.
Man sieht, man kann soweit kommen wie man will, als Linux Dilletant tun sich dann immer wieder neue Fragen auf.
Sollte mir das Ganze gelingen käme dann vor den Odroid C1 noch eine gute Stromversorgung und dann würde ich den gerne mal gegen einen mircorendu oder dergleichen antreten lassen.
Gruß
Uwe