Convolving/Crossover mit dem raspberry Pi - 6in/8out auf Kickstarter

[Sathim]

Hallo zusammen,

kurzes Vorwort - ich nutze für mein Musikzimmer Acourate von Uli Brüggemann,
Quelle ist hier der PC mit einem externen Interface. Als dann Abacus den PreAmp
mit integriertem Convolver (Pi-Basis) herausbrachte, war ich zunächst angefixt und
wollte das gerne für's Wohnzimmer - leider macht der aber nur Stereo.
Uli Aussage zu dem Zeitpunkt war, dass der Pi für USB-Audio nicht taugt und
via I2S eben nur Stereo möglich ist. Ich brauchte aber mind. 4 Wege wegen der Subwoofer.

Ziel war zuletzt ein MiniDSP 2x4 mit Dirac Live anzuschaffen.
Hindernis: Kostenpunkt und ein gewisser Unwille, die teure Acourate Lizenz nicht zu nutzen.


Bedingt durch den Fund dieser Kickstarter-Seite ist mein Interesse am Pi nun doch
wieder aufgeflammt:

https://www.kickstarter.com/projects/1250664710/audio-injector-octo-surround-sound-for-the-raspber?ref=user_menu

Wer nicht so gut englisch liest/spricht:
Der Entwickler hat ein 6in/8out Plugin Modul für den raspberry pi entwickelt, dass
über I2S funktiert und damit die erste Mehrkanalsoundkarte für den pi "erfunden",
die nicht über USB läuft. Digital In/out ist wohl nicht drin, für mich aber nicht wichtig.
Da die Entwickler schon eine Stereo-Soundkarte für den Pi erfolgreich über Kickstarter
aufgelegt haben, die man nun auch so kaufen kann, kann man denke ich ein funktionierendes
Produkt erwarten.


Mit dem Thread hier möchte ich zum einen auf das Gerät aufmerksam machen,
da ich denke der Bedarf nach einem günstigen und kompakten Mehrkanalkonvolver
welcher auch PC-unabhängig läuft, ist da.


Zum anderen bin ich auf der Suche nach Dokumentationen/Tutorials wie ich einen
Convolver als Blackbox auf dem Pi zum Laufen bringe. Ich habe exakt 0 linux-Kenntnisse,
das gleich vorweg. Ich habe schon mehrfach in dieser Sache angesetzt, bin aber immer wieder
durch ellenlange Konsolenbefehle und Abkürzungen/Fachbegriffe verprellt worden...

Meine zweite Idee war nämlich, einfach zwei Pis zu benutzen und mit einem den Bass
zu betreiben und mit dem zweiten die Satelliten - ein Y-Kabel aus dem Pre-Out des AVR und gut.
Die entsprechenden Filter sind ja mit Acourate schnell erstellt.

[albondiga]

Coole Sache. Liefern die dann auch die Software? Oder muss man das selbst frickeln? Für den Multichannel Support per HDMI auf RPi3 muss man ja die Kernelquellen editieren und neu kompilieren.

Wie zuverlässig funktioniert eigentlich Kickstarter? Hat das schonmal wer gemacht?

[Sathim]

Auf der Website steht zu dem Thema:
Software Requirements : Will be part of the stock Raspbian distribution, with drivers uploaded to the official Raspberry Pi git tree. This is similar to the previous hardware we have released and the drivers ship with standard Raspbian ready and working. We also provide setup scripts on the support forum.

Also wohl nur Treiber, keine weiterreichende Software.

Gerade eben habe ich gesehen, dass nun auch endlich auf der Seite
steht, welcher Chip auf der Platine sitzt - sicher auch für den
einen oder anderen hier interessant:

Cirrus Logic CS42448

[The Alchemist]

Mit Nischenprodukten unter Linux ist das immer so eine Sache...man weiß nie, ob sie unterstützt werden oder nicht.

Aufgrund eines fehlenden digitalen Eingangs find ich die Karte auch nicht so interessant.


Deine Idee 2. Raspberrys zu benutzen halte ich für denkbar schlecht da timing Probleme auftreten werden...

Eine andere Möglichkeit wäre, auch unter dem Hinweis, dass Du keinerlei Kenntnis von Linux besitzt, einen PI mit einer Digi Karte und Aroio OS zu bentuzten. Der Digitale Ausgang der Karte speist einen MINIDSP 2x4 HD. Mit deiner Acourate Lizenz erstellst Du die FIlter für Aroio.

Gruß

[mcdwerner]

Evtl. funktioniert ein Ansatz mit Ecasound, siehe hier:
http://rtaylor.sites.tru.ca/2013/06/25/digital-crossovereq-with-open-source-software-howto/

Ecasound läuft bei mir auf einem kleinen Mainboard mit integrierter CPU und Passivkühlung. Ob der Pi das in Echtzeit stemmt? Ich habe leichte Zweifel...

[Sathim]

Eine andere Möglichkeit wäre, auch unter dem Hinweis, dass Du keinerlei Kenntnis von Linux besitzt, einen PI mit einer Digi Karte und Aroio OS zu bentuzten. Der Digitale Ausgang der Karte speist einen MINIDSP 2x4 HD. Mit deiner Acourate Lizenz erstellst Du die FIlter für Aroio.

Einen normalen MiniDSP habe ich ja schon im Einsatz - da kann man direkt mit I2S rein, aber woher das dann wieder nehmen?

Analog in brauche ich ja auch, da meine Quelle der PreOut des AVR ist.
(Das ganze muss bedienungsfreundlich bleiben... für die Dame des Hauses.)

Wenn ich schon den 2x4HD kaufe, kann ich mir den Rest mit Pi und Co auch sparen und die ~200€ für das Dirac Plugin ausgeben.

[The Alchemist]

Wenn ich schon den 2x4HD kaufe, kann ich mir den Rest mit Pi und Co auch sparen und die ~200€ für das Dirac Plugin ausgeben.

Das sehe ich auch so.

Gruß

[wischem]

Vorsicht vielleicht völlig sinnfrei::denk:

Gibt es denn schon einen Treiber für den RPi der Mehrkanal über i2S liefert? Oder haben die den gebacken?

Ich dachte es gibt bisher nur PCM Treiber und das ist Stereo only.

[sion]

Gibt es denn schon einen Treiber für den RPi der Mehrkanal über i2S liefert? Oder haben die den gebacken?Das würde mich dann auch mal interessieren. Ich konnte jetzt aber nicht widerstehen, und habe mir eine (unbalenced, RCA) Version reservieren lassen....

[Sathim]

Macht euch doch einfach mal die Mühe und guckt auf die Website - dort steht mehr darüber.

Natürlich gibt es einen Treiber dazu... - vom Entwickler des Boards

[sion]

Auf der Website habe ich schon geschaut, aber mir ist noch immer schleierhaft, wie das mit mehr als 2 Kanälen via i2s gehen soll....

[Sathim]

Die schreiben nur, dass halt ein neuer Ansatz verwendet wird, der das möglich machen soll.

Ich kann das nicht bewerten, grundsätzlich scheint es sich ja aber um seriöse Leute zu handeln, da es nicht das erste Projekt ist.

[The Alchemist]

Ich bin da mal gespannt, ob es die Treiber in den Kernel schaffen. Ich weise mal drauf hin, dass die Wolfson Audio, jetzt Cirrus Logic Karte es bis Heute nicht geschafft in den Kernel zu kommen. (3 Jahre)

Mehrkanalfähigkeit via HDMI ist im Kernel wieder deaktiviert worden, weil es durch Änderungen im Channel-Mapping (die meiner Meinung nach unnötig waren, da man sie an andere Stelle als im Kernel hätte angehen können) zu Störungen im Linux Alsa Treiber und bei Anwendung von JACKD gekommen ist. (Nachlesen kann man das hier (https://github.com/raspberrypi/linux/pull/1257))
Von daher ist die Situation spannend. Jemand der keine Linux Kenntnisse besitzt, wird dann schon Schwierigkeiten haben den Kernel zu tauschen, in dem Fall kann ich nur abraten.

Ich werde mir mal ein aktuelles Raspbian herunterladen, einen aktuellen Kernel kompilieren und mal schauen wie die Situation aussieht.

[sion]

Hallo Alchemist,

ich habe letztes Jahr einen 4.4.er Kernel mit HDMI-Mehrkanal-Fähigkeit kompiliert um auf einem RPI3 eine Aktiveweiche nach Deiner Anleitung hier http://www.diy-hifi-forum.eu/forum/showpost.php?p=169856&postcount=87 (http://www.diy-hifi-forum.eu/forum/showpost.php?p=169856&postcount=87)
zu realisieren. Das funktioniert auch sehr gut. Mich würde jetzt interessieren, ob Du vielleicht ein paar Stellschrauben nennen könntest, mit denen ein Kernel idealerweise für die Audioausgabe auf einem Raspberry kompiliert wird. Ich bin damals dieser Anleitung gefolgt https://www.raspberrypi.org/documentation/linux/kernel/building.md
aber vielleicht geht es ja noch besser, bzw. könnte man noch entsprechende Kompilierflags o.ä. mitgeben...

Ansonten um zum Thema hier zurückzukommen, da stimme ich Dir voll und ganz zu, könnte es sein, dass der Audio Injector Octo nicht einfach so in Betrieb zu nehmen ist. Wenn er denn funktioniert. Ich bin gespannt auf das Teil, auch wie die Soundqualität sein wird. Mit nachgeschalteten Class-D-Verstärkern dürfte so ein Setup doch etwas weniger Platz in Anspruch nehmen, als ein AV-Receiver, bzw. auch für mobile Lösungen geeignet sein. Eine aktivierte Boombox hätte ja auch was.

Viele Grüße Klaus

[The Alchemist]

Also mit den andernorts erwähnten Stellschrauben für Audio...

Da hab ich ehrlich gesagt eine andere Meinung zu....:D
(Es ist mir aufgefallen, dass die niemand öffentlich macht)

Der Kernel nimmt sich im wesentlichen dass, was er braucht, wenn mehr da ist , egal.
Fortschritte gäbe es eventuell bei Veränderungen im Alsa Treiber, also Unterstützung höhere Bittiefen etc., ob man das hört?

Zur Zeit lässt mich mein Desktop im Stich, längere Zeit 100% Last und das Ding geht aus, daher kann ich keinen Kernel kompilieren.
Welches war der letzte Kernel den Du kompiliert hast?
Gruß

[sion]

Hallo Alchemist,


Also mit den andernorts erwähnten Stellschrauben für Audio...

Da hab ich ehrlich gesagt eine andere Meinung zu....:Dhm, ich weiß jetzt zwar nicht wen oder was Du meinst, ist ja aber auch egal (eventl. dann per PN).
Ich dachte bei meiner Frage an Performance, bzw. unnötige Teile aus dem Kernel herauszunehmen. Aber wenn ich Dich richtig verstanden habe, dann ist das eher unerheblich.

Den Kernel, den ich kompiliert habe ist der "4.4.20-v7+" Der läuft seither sehr gut, ich habe keinerlei Ausfälle, Abstürze oder sonstiges. Ich nutze den allerdings auch nur für für die Audioausgabe via brutefir. Ich hatte gestern noch ein Systemupdate gemacht, danach Kernel und Module neu eingespielt, alles wie gehabt ohne Probleme.


uname -a
Linux raspberrypi 4.4.20-v7+ #1 SMP Thu Sep 29 13:25:04 UTC 2016 armv7l GNU/Linux
brutefir hatte ich gestern aus den Quellen neu kompiliert, konnte aber bisher keine Vor- oder Nachteile gegenüber dem ursprünglich mit Raspbian ausgelieferten Paket feststellen (bisher war es wohl die 1.0m, jetzt 1.0o)

btw.: Da ich damals Schwierigkeiten mit dem Crosscompilieren hatte, habe ich direkt auf dem RPI3 kompiliert. Ich kann nicht sagen, wie lange es genau dauerte, aber länger als einen halben Nachmittag war er wohl nicht beschäftigt damit.

Viele Grüße Klaus

[The Alchemist]

...

aber wenn ich Dich richtig verstanden habe, dann ist das eher unerheblich.


Genauso hab ich es gemeint.

Gruß

Noch ein kleiner Nachtrag:
Mir ist zugetragen worden, dass in einem "anderen Forum" Beiträge gelöscht worden sind, bei denen auf die Modifikation, auf die ich im Kernel hingewiesen hab (die nicht auf meinem Mist gewachsen ist) Bezug genommen wurde.

Ich weise ausdrücklich darauf hin, dass der Linux Kernel quelloffen ist und unter GPL steht. Es ist daher ausdrücklich jedermann möglich, dokumentierte Veränderungen am Kernel vorzunehmen, ob es diese Veränderungen dauerhaft in den Kernel schaffen ist eine andere Geschichte.

Es werden durch Veränderungen im Kernel, insbesondere im quelloffenen Treiber bcm2835, keinerlei Lizenzen oder Patente verletzt. Das Signal wird nicht AC3, DD oder ähnlich kodiert. HDMI Lizenzen müssen vom Hersteller für die Nutzung der Schnittstelle gezahlt werden, dass heißt jeder Hersteller, der eine HDMI Schnittstelle in seinen Geräten verwendet, muss eine Lizenzgebühr bezahlen. In diesem Fall also die RPi Foundation. Acht Kanäle PCM sind seit Einführung der Schnittstelle Standard.

Da sind die "Hüter des Jitters" ganz eindeutig über das Ziel hinausgeschossen.

[The Alchemist]

brutefir hatte ich gestern aus den Quellen neu kompiliert, konnte aber bisher keine Vor- oder Nachteile gegenüber dem ursprünglich mit Raspbian ausgelieferten Paket feststellen (bisher war es wohl die 1.0m, jetzt 1.0o)

Schaut man einmal hierher (https://www.ludd.ltu.se/~torger/brutefir.html#news), dann stellt an fest, dass sich auch eigentlich nichts geändert haben sollte.

Gruß

[sion]

Es werden durch Veränderungen im Kernel, insbesondere im quelloffenen Treiber bcm2835, keinerlei Lizenzen oder Patente verletzt. Das Signal wird nicht AC3, DD oder ähnlich kodiert. HDMI Lizenzen müssen vom Hersteller für die Nutzung der Schnittstelle gezahlt werden, dass heißt jeder Hersteller, der eine HDMI Schnittstelle in seinen Geräten verwendet, muss eine Lizenzgebühr bezahlen. In diesem Fall also die RPi Foundation. Acht Kanäle PCM sind seit Einführung der Schnittstelle Standard.

Da sind die "Hüter des Jitters" ganz eindeutig über das Ziel hinausgeschossen.

Da habe ich aber jetzt voll auf dem Schlauch gestanden. Die Geschichte meinst Du. :D
Leider sind die "Hüter des Jitters" völlig unzugänglich für die von Dir genannten Fakten. Schwamm drüber, hier im Forum scheint mir der Austausch im Grunde wesentlich fruchtbarer zu sein. Dir nochmals herzlichen Dank für Deine Impulse in der Richtung, ich genieße gerade die Früchte... :ok:

[waterburn]

Ich könnte mir vorstellen, dass sie die I2S Schnittstelle des Pi mit 384 kHz betreiben und per Software 4 Audio Streams multiplexed werden. Das ganze könnte dann auf der Hardware mittels FPGA oder CPLD wieder auf 4 parallele I2S Streams mit 96 kHz demultiplexed werden.

Allerdings bin ich mir nicht sicher, ob der Pi überhaupt 384kHz als Samplerate über I2S unterstützt.

Gruß

waterburn

[sion]

Hallo waterburn,

so etwas in der Richtung wäre ja denkbar. Allerdings sprechen die Entwickler von 8 Kanälen, 96 kHz und 24 bit...

Angepasste Kernel mit 384 kHz gibt es bereits, picoreplayer z.b. hat das implementiert https://sites.google.com/site/picoreplayer/home/news

Viele Grüße Klaus

[waterburn]

Allerdings sprechen die Entwickler von 8 Kanälen, 96 kHz und 24 bit...


Ja genau. Jeder Stream hat zwei Kanäle. Und 4 Streams mit 96 kHz entsprechen einem mit 384 kHz.

[sion]

Jeder Stream hat zwei Kanäle

:thumbup: (Groschen gefallen!)