Software Experimente mit Linux

Musikwiedergabe über PC und Mac

Beitragvon frankl » 04.06.2014, 18:24

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:

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
frankl
Aktiver Hörer
 
Beiträge: 394
Registriert: 20.01.2013, 02:43
Wohnort: Aachen

Beitragvon Daihedz » 05.07.2014, 22:44

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
Daihedz
Aktiver Hörer
 
Beiträge: 559
Registriert: 25.06.2010, 15:09

Beitragvon frankl » 13.03.2015, 02:40

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 http://frank_l.bitbucket.org/stereoutils/player.html

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 angegebenen Webseite.
  • 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
frankl
Aktiver Hörer
 
Beiträge: 394
Registriert: 20.01.2013, 02:43
Wohnort: Aachen

Beitragvon Martin » 13.03.2015, 20:32

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
Martin
Aktiver Hörer
 
Beiträge: 78
Registriert: 15.03.2012, 15:23

Beitragvon modmix » 21.03.2015, 12:29

Hallo Frank,

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 ,-)

Dank im Voraus
Ulli
Bild
modmix
inaktiv
 
Beiträge: 2412
Registriert: 17.07.2010, 15:58
Wohnort: Nutzung dieses Beitrags außerhalb des Forum ist nicht gestattet

Beitragvon frankl » 22.03.2015, 00:57

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
frankl
Aktiver Hörer
 
Beiträge: 394
Registriert: 20.01.2013, 02:43
Wohnort: Aachen

Beitragvon matze81479 » 22.03.2015, 11:48

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
matze81479
inaktiv
 
Beiträge: 81
Registriert: 18.04.2012, 21:33
Wohnort: Rheinstetten (bei Karlsruhe)

Beitragvon modmix » 22.03.2015, 12:15

Hallo Frank,

danke für Deine Hinweise!

frankl hat geschrieben:ganz habe ich nicht verstanden, was Deine Absicht ist. Ich kenne die MC-1.2 nicht...

Im 1.2-Thread habe ich mein Verständnis von der Funktionsweise der MC-1.2 gezeigt.

Bild

Die Idee ist simpel, das digitale Signal durch die MC-1.2 zu schleifen - z.B. mit sox, daß von einem Audio-Device liest und an ein Audio-Device ausgibt - einfach, um das Signal mit der Clock der MC-1.2 zu takten (ginge auch mit einer MC-3+, aber es geht ja um Experimente ,-).

Beste Grüße
Ulli
Bild
modmix
inaktiv
 
Beiträge: 2412
Registriert: 17.07.2010, 15:58
Wohnort: Nutzung dieses Beitrags außerhalb des Forum ist nicht gestattet

Beitragvon Daihedz » 22.03.2015, 15:13

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
Daihedz
Aktiver Hörer
 
Beiträge: 559
Registriert: 25.06.2010, 15:09

Beitragvon modmix » 22.03.2015, 20:45

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.

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:

Player gestartet - steht auf ALSA. ALSA wandelt 44k1 nach 48k - grrrrr...

Im JACK Settings kann ich immerhin 44k1 einstellen - paßt das etwa nicht automatisch die SampleRate an?...

Und nun spielt da auch etwas durch die Mutec MC-1.2 :D

Bild
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:

Im DAC setup / List Cards steht u.a.:
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...

Beste Grüße
Ulli
Bild
modmix
inaktiv
 
Beiträge: 2412
Registriert: 17.07.2010, 15:58
Wohnort: Nutzung dieses Beitrags außerhalb des Forum ist nicht gestattet

Beitragvon frankl » 27.03.2015, 01:34

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.:
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:
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:
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
frankl
Aktiver Hörer
 
Beiträge: 394
Registriert: 20.01.2013, 02:43
Wohnort: Aachen

Beitragvon modmix » 27.03.2015, 21:04

Danke, Frank.
mount geht jetzt - keine Ahnung, was ich falsch gemacht habe :oops:

Unter ALSA sehe ich eine ganze Reihe von MC-1.2-Einträgen.
Hatte das Default Audio Device gewählt; Surround and the hack will ich ja nicht für CD Audio.
Das Default Audio Device sampelt auf 48k.
Nicht aber der IEC958 (S/PDIF) Digital Audio Output - prima!

So ganz aus Neugier: woher kommen die vielen Einträge zur MC-1.2? von Mutec?

So, nun zum spannenden Teil:
arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC9205 Analog [STAC9205 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: M20 [MC-1.2 USB 2.0], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC9205 Analog [STAC9205 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: STAC9205 Digital [STAC9205 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: M20 [MC-1.2 USB 2.0], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

Gut, card 1 ist die MC-1.2.
Dann müßte das doch so gehen (S32_LE zu finden war einfach...):
arecord -D hw:1,0 -t raw -c 2 -f S32_LE -r 44100 | aplay -D hw:1,0 -t raw -c 2 -f S32_LE -r 44100
Recording raw data 'stdin' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
Aborted by signal Interrupt...
Und eigentlich sieht das ja auch gut aus...
Gebe ich auf den AES-Eingang der MC-1.2 ein 44k1-Signal (aus meinem Rechner mit der L22), kommt nichts...

Also mal den Eingang geändert:
arecord -D hw:0,0 -t raw -c 2 -f S32_LE -r 44100 | aplay -D hw:1,0 -t raw -c 2 -f S32_LE -r
Recording raw data 'stdin' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
Aborted by signal Interrupt...
Juhu! da kommen Geräusche aus meinem Lautsprecher :D
Eine formidable Rückkopplung baut sich da auf - schnell Ctrl-C und neuer Versuch, bei dem ich auf das Notebook klopfe - richtig! das kommt jetzt aus meinen Lautsprechern. Und damit aus der MC-1.2, weil nur die Signale aus dem Notebook als SPDIF an meine MC-3+-Kaskade weitergeben kann.

Also gut!
Die Ausgabe über die MC-1.2 klappt.
Das Einlesen über die MC-1.2 klappt nicht - hoffentlich: noch nicht.

Beste Grüße
Ulli
Bild
modmix
inaktiv
 
Beiträge: 2412
Registriert: 17.07.2010, 15:58
Wohnort: Nutzung dieses Beitrags außerhalb des Forum ist nicht gestattet

Beitragvon Sire » 15.04.2015, 13:51

Hallo Frank,

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

Liebe Grüße

Klaus
Bild
Sire
Aktiver Hörer
 
Beiträge: 258
Registriert: 02.12.2013, 15:01

Beitragvon Tinitus » 15.04.2015, 20:30

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
Tinitus
Aktiver Hörer
 
Beiträge: 796
Registriert: 10.11.2013, 22:48

Beitragvon frankl » 15.04.2015, 22:33

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:
sudo apt-get install gcc libasound2-dev wget git

(oder als 'root' ohne das 'sudo' vorneweg). Auf Arch sollte es so gehen (als root):
pacman -S gcc alsa-lib wget git


Jetzt brauchen wir den Quellcode meiner Programme (von hier):
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:
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:
make

oder auf dem Raspi 2 auch eine bessere Variante:
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'):
cp bin/* /usr/local/bin/

Im Verzeichnis 'scripts/' gibt es verschiedene Skripte, die auf dieser Webseite 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
frankl
Aktiver Hörer
 
Beiträge: 394
Registriert: 20.01.2013, 02:43
Wohnort: Aachen

VorherigeNächste

Zurück zu Computer-HiFi

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste