Software-Experimente mit Linux

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

Beitrag von frankl »

Daihedz hat geschrieben:In Deinem Beispiel wandelst Du mit einer ersten Instanz von SOX von 16Bit nach 64Bit, und dann mit einer gepipten zweiten Instanz von SOX von 44.1kHz nach 192kHz:
frankl hat geschrieben: ...
sox -t raw -r 44100 -c 2 -e signed -b 16 - -t raw -e floating-point -b 64 - | \
sox -t raw -c2 -r 44100 -e floating-point -b 64 - -t raw -e floating-point -b 64 - vol 0.4 rate -v -I 192000 | \
...
Frage nun: Warum machst Du die gesamte Wandlung nicht gleich in einem Rutsch, z.B. so:

sox -t raw -e signed -b 16 -r 44100 -c2 - -t raw -e floating-point -b 64 - vol 0.4 rate -v -I 192000

Das sollte eigentlich mit SOX doch möglich sein? Siehst Du vielleicht prinzipielle Vorteile bei Deiner gepipten Zwei-Sox-Einzelfunktions-Lösung gegenüber einer Ein-Sox-Doppelfunktions-Lösung? Es leuchtet mir schon ein, dass mit Deiner Lösung sichergestellt ist, dass auf alle Fälle 64-Bit-Daten zum Upsampling kommen, ditto zur Volumenregelung. Aber vielleicht ist diese Intelligenz in SOX bereits eingebaut? Weisst Du etwas davon?
Hallo Simon,

sorry, ich bin im Moment auf Reisen und habe nur gelegentlich Möglichkeit und Zeit im Forum zu lesen.

Der Doppelaufruf von sox in diesem Beispiel liegt daran, dass der vol-Filter vor der Konvertierung durchgeführt wird. Probier mal folgendes:

Code: Alles auswählen

sox orig.flac -t raw -e floating-point -b 64 - vol 0.000001 | sox -t raw -e floating-point -c 2 -r 44100 -b 64 - -e signed -b 16 v1.wav vol 1000000.0

sox orig.flac -t raw -e floating-point -b 64 - | sox -t raw -e floating-point -c 2 -r 44100 -b 64 - -t raw - vol 0.000001 | sox -t raw -e floating-point -c 2 -r 44100 -b 64 - -e signed -b 16 v2.wav vol 1000000.0
Dann schau mal v1.wav und v2.wav mit audacity an (v1.wav nicht abspielen!).
Daihedz hat geschrieben: Frage: Ist PLAYHRT und BUFHRT von der Theorie/Programmierung her einwandfrei dergestalt verwendbar, z.B. in einem 4-Weg-Stereo-Frequenzweichen-Rechner:

SOX (2-Kanal) | BUFHRT (2-Kanal) | BRUTEFIR (2-Kanal-in/8-Kanal-our)| PLAYHRT (8-Kanal) -> HW
Bisher habe ich nur Stereo-Signale verarbeitet. Deswegen kann ich aus dem Stegreif nicht sagen, ob PLAYHRT das in der jetzigen Form kann, oder eine Modifikation nötig ist. Wir können das per PN klären, wenn ich wieder zuhause bin (in 2-3 Wochen) und dann hier berichten.

Viele Grüße,
Frank
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo Experimentierfreudige

Ich finde die Programme Bufhrt, Playhrt und Volrace von Frank sehr interessant und äusserst erfolgsversprechend. Die sind ja bekannlich incl. deren Beschreibung hier zu haben:
http://frank_l.bitbucket.org/stereoutils/player.html. Da ich Frank's Ansatz spannend finde, habe ich drei Skripte getextet, welche um diese Programme gestrickt sind, und deren Anwendung in meiner heimischen Musikstube hoffentlich mit etwas Komfort ausstatten werden.

Mein Ansatz funktioniert dergestalt, dass auf einem Linux-PC ein Master-Skript läuft, und im Vollausbau auf einem anderen Linux-PC ein Slave-Skript. Der Slave hört auf den Master und bezieht vom Master einige Parameter zur Einstellung seiner Funktion, und spielt dann den Audio-Datenstroms ab. Das System ist universell aufgesetzt, sodass der Master entweder sogar ganz ohne Slave auf seine eigene Soundkarte ausgeben kann, oder aber die Audiodaten auf den Slave überträgt. Der Slave kann, wie schon gesagt, ganz weggelassen werden, oder auf demselben PC wie der Master aufgesetzt werden, oder aber auf einem zweiten PC laufen und die Daten über das Netzwerk empfangen:

Variante 1: Master_PC1 -> Soundkarte_PC1
Variante 2: Master_PC1 -> Slave_PC1 -> Soundkarte_PC1
Variante 3: Master_PC1 -> Audiostream_übers_Netz -> Slave_PC2 -> Soundkarte_PC2

Im Master geschieht dabei folgendes:
Variante 1: Audiodatei -> SOX -> Volrace -> Brutefir -> SOX -> Playhrt/Aplay -> Soundkarte
Variante 2: Audiodatei -> SOX -> Volrace -> Brutefir -> Bufhrt -> Audiostream_an_einen_internen_Port
Variante 3: Audiodatei -> SOX -> Volrace -> Brutefir -> Bufhrt -> Audiostream_ins_LAN

Im Slave:
Variante 1: Entfällt
Variante 2: Audiostream_vom_int._Port -> Bufhrt -> (ev.Brutefir) -> SOX -> Playhrt/Aplay -> Soundkarte
Variante 3: Audiostream_vom_LAN -> Bufhrt -> (ev.Brutefir) -> SOX -> Playhrt/Aplay -> Soundkarte

Das lässt viele Möglichkeiten offen. Im Endausbau werde ich im Master eine erste Bearbeitung der Stereo-Audiodaten (Race, DRC, Flow mit Volrace und Brutefir) vornehmen, das 2-Kanal-Signal über das Netz dem Slave übergeben und im Slave die Mehrwegweiche (8-10-Kanal mit Brutefir) rechnen.

Das Ganze funktioniert ausschliesslich auf ALSA-Ebene, ohne unerwünschte und/oder unkontrollierbare weitere Modifikationen des Datenstroms. Also kein Pulseaudio, Jack und dergleichen.

Das Bundle umfasst aktuell drei Skripte:
- audiofile_player_master.sh
- audiofile_player_slave.sh und
- audiofile_player_system_setup.sh.

Zur Einstellung der Rechtevergabe muss audiofile_player_system_setup.sh einmal auf dem/den Hosts mit Administratorenrechten laufen gelassen werden. Dann kann das Master-Skript und das Slave-Skript als nicht-root-User aufgestartet werden.

Bei mir laufen die Skripte schon beinahe tadellos. Wenn der Datenstrom jedoch 2-kanalig als 64-Bit(Float)/192kHz übers Netz geht, dann stottert (vorerst noch) die Wiedergabe. Dies hat nichts mit einem Fehler zu tun, sondern mit der Bedächtigkeit meines WLans (aktuell 802.11b/g). Da braucht's noch etwas Aufrüstung.

Ich liefere gerne die Skripts per email, an wen's konkreter interessiert. Etwas Linux-Kenntnisse sind jedoch zwingend Voraussetzung, damit Freude aufkommen kann. Und auch gleich ein dämpfender Hinweis: Ich bin zeitlich ausserstande und auch nicht gewillt, Linux-Nichtsahnern den Steigbügel zum audiophilen Linux-Vergnügen hinzuhalten. Wer also noch nie einen Brutefir-Faltungsrechner aufgesetzt und durchgespielt hat, und bei SOX an etwas für an die Füsse denkt, wird wohl aussen vor bleiben müssen.

Vom-Skripten-Fingerwunde Grüsse
Simon
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Hallo Forenten und potentielle Linux-Audio-Nutzer,

auch bei mir ist die Entwicklung bezüglich Player-Software nicht stehengeblieben. Es gibt nun eine neue Version 0.7 meiner Audio-Programme für Linux-Rechner [url=http://frank_l.bitbucket.org/stereoutils/player.html]http://frank_l.bitbucket.org/stereoutils/player.html[/url]

Auf den ersten Blick sieht es aus, als wenn sich nicht viel getan hätte, aber im Detail gibt es eine ganze Reihe von Neuerungen, von denen ich hier einige erwähnen möchte:
  • Für Leute mit Multikanal-Setup: 'playhrt' kann jetzt auch mehr als 2 Kanäle abspielen, solange die Soundkarte die Daten im "interlaced" Modus annimmt.
  • Um den Einstieg zu erleichtern, gibt es jetzt ein Verzeichnis 'scripts/' mit verschiedenen Skripten zum Abspielen einer Musikdatei. Einige sollten so wie sie sind oder mit minimaler Anpassung (richtige Soundkarte) auf den meisten Rechnern funktionieren. (Nicht vergessen, bei den ersten Tests leise zu drehen!) Ausführliche Erläuterungen gibt es auf der [url=http://frank_l.bitbucket.org/stereoutils/player.html#getstart]angegebenen Webseite[/url].
  • Das eigentliche Player-Programm 'playhrt' hat jetzt eine Option '--mmap'. Es wird empfohlen, diese zu benutzen, da dadurch die Audiodaten direkt in den Speicher des Treibers geschrieben werden. ('aplay' hat auch diese Option, implementiert das aber mit unnötigem zusätzlichem Kopieren der Daten, deswegen konnte ich da früher nie einen Unterschied hören).
  • Mehrere Programme haben jetzt eine Option '--shared' und benutzen dann statt Dateien (etwa in einer Ramdisk) Speicherblöcke im RAM (shared memory) zum Austausch von Daten. Dadurch wird Dateisystem-Overhead und die Einrichtung mehrerer Puffer vermieden. (Neu sind 'cptoshm/shmcat' zum Abspielen aus dem RAM.)
  • Zu der schon vorher in diesem Thread beschriebenen Hauptidee der Programme, nämlich dem blockweisen Schreiben der Audiodaten in präzisen Zeitabständen, ist jetzt eine weitere Idee gekommen: Bevor Daten an einen anderen Rechner oder die Soundkarte weitergereicht werden, bekommen sie durch (logisch unnötige) Lese- und Schreiboperationen einen "Refresh". Für Rechner mit ARM-Architektur gibt es dafür sogar Assemblercode. Hiervon hatte ich ja neulich schon im Rewrite Data Thread etwas geschrieben.
  • Das Programm 'bufhrt' hat jetzt eine Option '--interval', womit es in Intervallen ohne Ausgabe seinen Puffer mit der Eingabe füllt und dann ohne Eingaben zu lesen den Puffer rausschreibt. Das kann dazu genutzt werden, um Dateien auf einer Festplatte zu kopieren, oder beim Vorfalten von Musikstücken das Ergebnis auf eine Festplatte zu schreiben. Dazu werde ich an anderer Stelle noch etwas mehr schreiben.
Die Sache mit dem Refresh von Daten im RAM ist sehr interessant und auch kompliziert. Dieser Tage gab es zum Beispiel Meldungen zur Rowhammer Attacke, die aufzeigen, dass Speicherzellen im RAM ganz weit davon weg sind, nur zwei Zustände für 0 und 1 anzunehmen. Da werde ich mich weiter informieren und experimentieren.

Ich habe Varianten der Programme ausführlich in meinem Haupt-Stereosetup selbst genutzt und getestet (und auch so manche Versuche wieder verworfen). Insgesamt ergibt sich bei mir durch die diversen Optimierungen nochmal eine deutliche Klangverbesserung.


Außerdem habe ich die Beispielskripte in verschiedenen Setups ausprobiert. Recht erstaunt war ich, dass selbst auf meinem Notebook oder am Desktop-Rechner, jeweils mit den im Bildschirm eingebauten "Lautsprechern", sehr deutliche Klangunterschiede zum Beispiel zwischen 'audacity' und dem Skript 'play_writecatloop' gibt. Auf dem Notebook benutze ich neuerdings ein Skript ähnlich zu 'play_volrace', das zusätzlich einen beeindruckenden 3D-Effekt a la ambiophonics erzeugt.

Zum Ausprobieren sollte jedes Linux geeignet sein. Will man der bestmöglichen Klangqualität nahe kommen, ist es eher besser mit einem möglichst schlanken System zu beginnen und nachzuinstallieren, was man wirklich benötigt, als in einem umfangreichen System viele unnötige Prozesse zu stoppen.

Das Abspielprogramm, das ich in der Praxis selbst verwende, ist mit Python geschrieben und nicht im Paket enthalten. Vielleicht komme ich irgendwann mal dazu, das zu einem vorzeigbaren Zustand aufzuräumen . . . Oder doch mal ein Webinterface?

Vielleicht haben ja einige Leute Lust, mit diesem Paket zu experimentieren.

In diesem Fall, viel Spaß,

Frank
Bild
Martin
Aktiver Hörer
Beiträge: 116
Registriert: 15.03.2012, 14:23

Beitrag von Martin »

Hallo Frank,
Hut ab, da hat sich wieder einiges getan bei Dir. :cheers:
Sobald ich dazu komme werde ich die neue Version testen.

Viele Grüße
Martin
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

modmix hat geschrieben: mir geht gerade ein anderes Experiment duch den Kopf - wäre klasse ein paar Hinweise zu bekommen (zu lange her, daß ich mit Linix 'gespielt' habe; weiß daher nicht, welches Linux prima wäre und welche Audio-Archtiketur angesagt ist...)

Hintergrund: seit JPlay.v6 fällt der Klang aus dem SAT-Receiver qualitätsmäßig wieder deutlich ab - das SPDIF-Signal zu verbessern, könnte helfen...

Idee: die Mutec MC-1.2 kann ein SPDIF-Signal per USB an einen Rechner geben. Der Rechner könnte diese Daten postwendend per USB an die MC-1.2 zurückschicken, wo sie mit der internen Clock des MC-1.2 neu getaktet per SPDIF ausgegeben werden können - die MC-1.2 aus DCC ist ziemllich fein... vielleicht kommt dies ja auch hier zum Zuge.

Also:
SAT -SPDIF-> MC-1.2 -USB-> Linux mit z.b. sox (oder was ?) -USB-> MC-1.2 -SPDIF-> Anlage

BruteFIR ist ja ähnlich aufgebaut. Macht es Sinn, BruteFIR anzupassen (Filter will ich ja gar nicht verwenden)?

Hoffe, meine Idee und meine Fragen rübergebracht zu haben ,-)
Hallo Ulli,

ganz habe ich nicht verstanden, was Deine Absicht ist. Ich kenne die MC-1.2 nicht, verstehe die Beschreibung aber so, dass dort irgendein Signal hineingegeben wird (SPDIF über verschiedene Eingänge, AES, USB-Audio) und dieses eventuell gewandelt und reclockt wieder als SPDIF, AES oder über USB herausgegeben wird. Meinst Du mit der oben beschriebenen Idee, dass Du zwei MC-1.2 einsetzen willst, eine um das SPDIF vom SAT-Receiver auf den Rechner zu bekommen, und eine als hochwertigen DDC, der aus den USB-Daten vom Rechner wieder SPDIF erzeugt?

Ist denn das direktere Reclocking SPDIF -> SPDIF der MC-1.2 nicht gut genug?

Wenn Du das Signal über einen Rechner schickst, kannst Du natürlich potentiell mit den von mir beschriebenen Programmen experimentieren und versuchen, das Signal in diesem Schritt zu verbessern.

Ich muss hier etwas spekulieren, da es die Beschreibung der MC-1.2 nicht hergibt: Ich vermute, dass die MC-1.2 auf dem Rechner als Standard USB-Soundkarte (UAC2) erkannt wird? Dann könntest Du zum Beispiel mit 'arecord' das Eingangssignal lesen, eventuell per sox upsamplen und/oder mit brutefir falten und dann mit 'aplay' oder vielleicht besser mit meinem 'playhrt' wieder abspielen.

Viele Grüße,
Frank
Bild
matze81479
Aktiver Hörer
Beiträge: 81
Registriert: 18.04.2012, 21:33
Wohnort: Rheinstetten (bei Karlsruhe)

Beitrag von matze81479 »

Hallo,

mich würde mal interessieren, warum sich der ganze Aufwand noch lohnt, alles mit sox, brutefir etc. selbst zu bauen. Ich hatte vor einem Jahr auch damit experimentiert, da ich online falten wollte und es einfach keinen Player wie z.B. jRiver MC gab. Aus Experimentieren wurde aber damals auch schon bald frust ... Ich blieb dann erst mal einige Monate bei Win7 mit jRiver MC19 + JPlay ... Doch dann kamen die ersten Betas von jRiver für Linux heraus, und schon diese waren sehr vielversprechend. Mittlerweile ist die MC20 Linux Version in meinen Augen ausgereift, und ich weiß schon nicht mehr, ob sich meine Windows Partition überhaupt noch starten lässt. Kurzum, mich würde interessieren, warum ihr alle diesen Aufwand treibt bzw. ob ihr euch damit tatsächlich klangliche Vorteile gegenüber sowas wie jRiver verspricht. Am Preis kann es wohl kaum liegen, denn der liegt so ca. bei ner guten Highend-Feinsicherung :wink:

Gruß
Matthias
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

matze81479 hat geschrieben: .. mich würde mal interessieren, warum sich der ganze Aufwand noch lohnt, alles mit sox, brutefir etc. selbst zu bauen. ..."
Weil, so wie beim Kochen, alles nach Gusto abgeschmeckt werden, und erst noch mit verschiedenen eigenen Ideen und Zutaten versehen werden kann. Fertigfood kann sicherlich durchaus auch bekömmlich sein, für all jene, welchen Kochen keine rechte Freude bereitet.

Verschleckte Grüsse aus der Hausküche
Simon
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

modmix hat geschrieben:Ok, wenn ich mit Linux experimentieren will, braucht es wohl einen Rechner mit Linux :wink:
Da nehme ich doch mal ein Audiophile Linux und packe es auf ein Notebook - klappt ganz gut, wie in der Installationsanleitung beschrieben.
Hallo Ulli,

Audiophile Linux ist wohl ein vorkonfiguriertes Arch-Linux mit einer besonders resourcen-schonenden graphischen Oberfläche.
modmix hat geschrieben: Nun brauche ich nur noch Musik zum Abspielen... Na gut... automount des USB-Sticks ist nicht... mein monut /dev/sdb1 /mnt ignoriert das... Also ein paar Tracks per CD rübergeholt - schön, daß es diese alte Technologie noch gibt :roll:
... vielleicht so resourcen-schonend, dass kein Hintergrundprozess gestartet wird, der ständig checkt, ob ein USB Stick eingesteckt wird.

Mit 'dmesg | tail -40' solltest Du sehen, ob ein Stick erkannt wurde und welche Partitionen er hat (vielleicht ist es bei Dir ja /dev/sdc1 oder so). Wenn es '/mnt' gibt, sollte 'sudo mount /dev/sd?1 /mnt' eigentlich gehen ...
modmix hat geschrieben: Player gestartet - steht auf ALSA. ALSA wandelt 44k1 nach 48k - grrrrr...
Also, ALSA als solches resampled nicht, aber es lassen sich natürlich grässliche Dinge konfigurieren. Diese sollten sich umgehen lassen, indem man direkt die Hardware-Devices benutzt (typischerweise 'hw:0,0' oder ähnlich).
modmix hat geschrieben: Im JACK Settings kann ich immerhin 44k1 einstellen - paßt das etwa nicht automatisch die SampleRate an?...
Zum einfachen Abspielen braucht man jack nicht. Ich schalte das immer ab, oder deinstalliere es sogar.
modmix hat geschrieben: Und nun spielt da auch etwas durch die Mutec MC-1.2 :D

Photo, weil ich ja einen Screenshot nicht auf den nicht gemountete USB-stick bekommen hätte - da macht es auch nichts, daß ich nicht rausbekommen habe, wie den ein Screenshot erstellt werden kann... Wer sagt, Windows sei kompliziert :mrgreen:
Na ja, wenn man Windows nicht kennt, ist das auch zum Verzweifeln (und wenn man es kennt, immer noch ...)
modmix hat geschrieben: Im DAC setup / List Cards steht u.a.:

Code: Alles auswählen

card 1: M20 [MC-1.2 USB 2.0], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0:  subdevice #0 
Was immer mir das auch sagen soll...
Irgendwo da müßte aber wohl sox o.ä. das Device zum Lesen vom SPDIF-Audio per USB finden...
Wenn Deine Idee von der Funktionalität der MC-1.2 richtig ist (das konnte ich durch einen kurzen Blick in die Anleitung nicht nachvollziehen), dann sollte diese als CAPTURE und als PLAYBACK Device ansprechbar sein. Dies kann man mit 'arecord' oder 'aplay' in einem Terminalfenster überprüfen. Bei der internen Soundkarte in meinem Notebook sieht das zum Beispiel so aus:

Code: Alles auswählen

notebook> arecord -l
**** Liste der Hardware-Geräte (CAPTURE) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC283 Analog [ALC283 Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
notebook> aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC283 Analog [ALC283 Analog]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karten- und Gerätenummer sind hier jeweils Null, deswegen kann ich die mit 'hw:0,0' ansprechen.
Ein einfaches Lesen und wieder Rausschreiben sollte dann ungefähr so gehen:

Code: Alles auswählen

arecord -D hw:0,0  -t raw -c 2 -f S16_LE -r 44100 | aplay -D hw:0,0 -t raw -c 2 -f S16_LE -r 44100
Falls das so geht, ist die Grundidee in Ordnung. Danach könntest Du an diesem Kommando herumoptimieren.

Viele Grüße,
Frank
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo Frank,

hast Du schon über eine armv7-Version Deiner Programme nachgedacht? (wegen raspberry 2)

Liebe Grüße

Klaus
Bild
Tinitus
Aktiver Hörer
Beiträge: 1322
Registriert: 10.11.2013, 21:48

Beitrag von Tinitus »

Hallo Klaus,

Franks Programme laufen unter Linux. Wenn also auf dem rapsberry ein Archlinux installiert ist oder Debian oder oder oder sollten Franks Programme laufen. Ich habe für meinen Odroid C1 auch eine SD-Karte mit Archlinux. Archlinux gibt es sicherlich auch für den rapsberry. Frank hat mir in einem anderen Thread auch schon mitgeteilt, dass ich seine Programme auf den mit Archlinux laufenden Odroid per ssh (Terminal) aufspielen kann. Auch wenn ich armer Tropf nicht weiß, wie ich diese Programme dann starte (händisch?) müßte und wie ich sie (falls gewunscht) beim booten starten könnte. Aber noch habe ich andere Baustellen.

Gruß

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

Beitrag von frankl »

Sire hat geschrieben: hast Du schon über eine armv7-Version Deiner Programme nachgedacht? (wegen raspberry 2)
Hallo Klaus und andere Interessierte,

wie Uwe schon richtig angemerkt hat, können meine Programme auf jedem Linux genutzt werden.

Um die Hürde noch etwas zu senken, habe ich für einige Rechnertypen auch vorkompilierte Programme auf der Webseite. Es ist aber nicht schwierig, die Programme auf anderen Rechnern selbst zu kompilieren.

Wie das geht, steht in der Datei "INSTALL", wenn man das Quellcode-Archiv heruntergeladen und ausgepackt hat. Hier sind noch ein paar Erläuterungen dazu. Benötigt werden ein C-Compiler wie 'gcc', die ALSA Header-Dateien (Infos über die Funktionen in der ALSA-Bibliothek für den C-Compiler) und optional 'wget' oder 'git'.

Auf Debian/Raspian/Ubuntu/Mint und anderen Linux-Varianten kann man die so installieren, falls noch nicht vorhanden:

Code: Alles auswählen

sudo apt-get install gcc libasound2-dev wget git
(oder als 'root' ohne das 'sudo' vorneweg). Auf Arch sollte es so gehen (als root):

Code: Alles auswählen

pacman -S gcc alsa-lib wget git
Jetzt brauchen wir den Quellcode meiner Programme (von [url=http://frank_l.bitbucket.org/stereoutils/player.html#download]hier[/url]):

Code: Alles auswählen

wget http://frank_l.bitbucket.org/stereoutils/frankl_stereo-0.7.tar.gz
tar xzvf frankl_stereo-0.7.tar.gz
cd frankl_stereo-0.7
oder alternativ direct aus dem git-Repository, das immer die aktuellste (und auch jede alte) Version enthält:

Code: Alles auswählen

git clone https://frank_l@bitbucket.org/frank_l/frankl_stereo.git
cd frankl_stereo/
(später kann in diesem Verzeichnis immer mit 'git pull' alles auf die neueste Version aktuallisiert werden).

Und jetzt kompilieren:

Code: Alles auswählen

make

oder auf dem Raspi 2 auch eine bessere Variante:

Code: Alles auswählen

make REFRESH=VFP
Jetzt stehen die Programme im Unterverzeichnis 'bin/'. Damit sie allgemein auf dem Rechner verfügbar sind, könnte man die so kopieren (als 'root' oder mit vorangestelltem 'sudo'):

Code: Alles auswählen

cp bin/* /usr/local/bin/
Im Verzeichnis 'scripts/' gibt es verschiedene Skripte, die [url=http://frank_l.bitbucket.org/stereoutils/player.html#getstart]auf dieser Webseite[/url] erklärt werden - das Rumspielen kann beginnen.

Viele Grüße,
Frank

PS: Ich habe keinen Raspi 2, aber ich vermute, dass die Programme, die ich auf meinem Odroid-XU kompiliert habe, auf dem Raspi 2 laufen. (Falls Du einen Raspi 2 hast und es ausprobieren willst, schick mir PM mit einer Mail-Adresse. Wenn das geht, kann ich diese vorkompilierten Programme auch auf meine
Webseite stellen.)
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Ein gut gelauntes Guten Morgen in die Runde.

Meine Begrüßung lässt es schon ahnen, ich hatte/habe Gelegenheit Franks Programme in meinem Setup anzuwenden und bin begeistert. Vorausschicken möchte ich, dass meine Kette auch mit Optimierungen nicht als audiophiler Maßstab dienen kann.

Mein Setup sah bisher so aus:
NAS Synology-->LAN-->Router-->WLAN-->Raspberry B+ (weiterhin RPiB)-->I²S-->IQuadiO DAC+-->miniDSP 2x4-->2x Indeed TA2021S-->DIY Lautsprecher, zwei Wege ohne passive Weiche. Vor einiger Zeit habe ich eine Belkin Pure AV gekauft, die brachte eine deutliche Verbesserung mit mehr Ruhe im Klangbild.
Nun ist noch ein Raspberry 2 (RPi2) hinzugekommen. Geplant ist, diesen per direkter LAN-Verbindung mit dem RPiB zu verbinden. Im Moment sind die beiden per WLAN verbunden, was aber auch schon erstaunlich gut funktioniert.

Für die Versuche auf dem RPi2 habe ich die Odroid-Programme von Franks Homepage verwendet. Sie laufen einwandfrei. Nach anfänglichen Schwierigkeiten mit der Einrichtung der Scripte (siehe nächsten Abschnitt), konnte ich mit dem Experimentieren beginnen.

Dieser Abschnitt kann übersprungen werden, er schildert nur meine Irrungen und Wirrungen, ich füge ihn ein, damit andere nicht die gleichen Fehler machen müssen.
- Fehler 1: Beim Aufruf von play_remote auf dem RPi2 gab es Fehlermedlungen die mich verwirrten. "ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card, ALSA I/O: Could not open audio output "hw:1": No such file or..." Ursache war eine alte .brutefir_config auf dem RPi2. Die war so konfiguriert, dass sie lokal an eine testweise USB-Karte den Sound ausgeben sollte. So konnte das ja nix werden mit dem remote...
- Fehler 2: Wieder die alte .brutefir_config. Ich hatte nicht bedacht, dass VOLRACE einen FLOAT64_LE-Output hat. Dies muss in der .brutefir_config entsprechend in der Input-Sektion anpassen.
- Fehler 3: Die Option --mmap musste ich leider im play_remote Script auskommentieren. Eine kurze Internet-Recherche ergab, dass die Raspberrys die mmap-Option derzeit nicht über I²S unterstützen.

Frank hat mich bei der Fehlersuche und Einrichtung sehr gut unterstützt und dabei auch eine einfache angepasste .brutefir_config geschickt, die das Signal unverändert duchlässt. Er gab mir auch den Hinweis auf eine Filter-Datei, die auf seiner Homepage zu finden ist. Stichwort LoCo.

Momentan nutze ich eine Konfiguration, die playhrt, bufhrt, writeloop, catloop, volrace, cptoshm und shmcat nutzt, sowie Franks LoCo-Filter. Auf dem RpiB lässt sich während des Hörens die Datei /tmp/VOLRACE editieren und das Ergebnis bestaunen. Als derzeit beste Variante haben sich die Werte 0.6 8 0.20 derzeit bei mir erwiesen.

Hörerfahrungen:
Es ist für mich schier unglaublich, wie sich meine einfache Anlage mit Franks Programmen verbessert hat. Der Klang ist klarer geworden und aufgeräumter. Die räumliche Präzision hat deutlich gewonnen. Die Bühne ist definitv besser in der Tiefe. Die Instrumente sind fest an ihrem Platz und genau zu lokalisieren. Besser kann ich es kaum beschreiben.
Ein Beispiel: Vor zwei Wochen hatte ich auf Anregung eines Freundes die neue CD von Mark Knopfler erworben. Und ich war vom Klang ziemlich enttäuscht. Schon der erste Track "Laughs and Jokes and Drink and Smokes" war nur ein grausliger Matsch irgendwo in der Mitte zwischen den Lautsprechern. Jetzt ist es schon viel besser. Die Bühne ist breiter ist zudem in der Tiefe gestaffelt. Daran, dass es gerade bei diesem Stück noch nicht optimal klingt, zeigt aber auch, dass da noch Optimierungspotential ist... Das Experimentieren mit verschiedenen Einstellungen und Optionen macht mir neben dem Hören jedenfalls sehr viel Spaß.

Fazit:
Ich kann das Experimentieren mit Franks Programmen nur empfehlen.

Herzlichen Dank an Frank!

Viele Grüße

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

Beitrag von frankl »

Sire hat geschrieben: Momentan nutze ich eine Konfiguration, die playhrt, bufhrt, writeloop, catloop, volrace, cptoshm und shmcat nutzt, sowie Franks LoCo-Filter. Auf dem RpiB lässt sich während des Hörens die Datei /tmp/VOLRACE editieren und das Ergebnis bestaunen. Als derzeit beste Variante haben sich die Werte 0.6 8 0.20 derzeit bei mir erwiesen.
Hallo Klaus,

danke für Deine Rückmeldung! Dann hat es sich ja gelohnt, die Anfangsprobleme zu überwinden.

Zu den volrace Parametern: der zweite Parameter ist ja der Zeitversatz (in Anzahl Samples) im RACE Algorithmus. In einem typischen gleichseitigen Stereodreieck sollte der eher so 11 oder 12 Samples (bei 44100) sein. Die 0.20 (-14 dB) nutze ich auch bei vielen Aufnahmen. Erlaubt ist natürlich alles was gefällt.

Viel Spaß beim Hören,
Frank
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo Frank,

ich habe da mit verschiedenen Einstellungen experimentiert. Am Ende war es meist immer die 0.8, die mir am besten erschien. Aber ich werde weitere Versuche machen. Im Moment ist die Auswahl der zu spielenden Stück noch etwas unkomfortabel. Wäre ganz gut, wenn das Abspielen mit einem geeigneten Programm möglich würde... Leider bin ich nicht in der Lage so etwas zu programmieren. Vielleicht findet sich ja jemand hier im Forum.

Bei der Gelegenheit: Ich habe gestern noch ein paar Versuche mit einem USB-Plattenspieler gemacht. Den habe ich einfach an einen USB-Port des RPi2 angeschlossen. Per

Code: Alles auswählen

rec  -t raw -r 44100 -c 2 -e signed -b 16 - | nc -l -q 0 -p 3456
auf dem Server und einem zu

Code: Alles auswählen

nc 192.168.170.33  3456 | playhrt \
geänderten Eintrag im play_simple-script auf dem Audiorechner geht es schon. Das müsste doch auch mit dem play_remote-script des Servers möglich sein, um eben die ganzen Schmankerl zu genießen. Aber wie müsste das script angepasst werden?

Viele Grüße

Klaus
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Sire hat geschrieben:Am Ende war es meist immer die 0.8
Sollte natürlich "8" heißen...
Bild
Antworten