Raspberry Pi -> ADAU1701 DSP I2S Treiber

Autor

Beitrag

MK_Sounds
Stammgast

#1 erstellt: 21. Mai 2018, 15:26

Hallo zusammen,

für mein aktuelles Projekt verwende ich den Raspberry Pi als digitales Zuspielmedium in Verbindung mit einem DSP (ADAU1701 z.B. Sure DSP). Die einfachste Option wäre hierfür eines der zahlreichen DA-Wandler Boards zu kaufen und den DSP analog zu speisen. Allerdings wandelt man dann von digital in analog und im DSP wieder von analog in digital. Das ist natürlich ausgesprochener Blödsinn und unnötiger Qualitätsverlust.

Die Daten sollen folglich digital via I2S in den DSP gelangen. Nun ist dafür allerdings ein Treiber notwendig. Es gibt mittlerweile schon einige Treiber für Audioanwendungen, aber kein mir bekannter passt auf die speziellen Anforderungen des DSPs.

Also, was tun sprach Zeus ? - Programmieren, was sonst

Herausgekommen ist dabei nun ein generischer I2S Audio-Treiber für den Raspberry. Angeschlossen werden können damit dann z.B. DSPs, die als Clock-Master konfiguriert werden (müssen) und die keinerlei Initialisierung oder Konfiguration via I2C oder SPI erfordern. Das Projekt ist auf die Standard-Einstellungen des DSPs (48 kHz bei 24 bit) konfiguriert. Ein Konfigurations-File für das ALSA-Subsystem übernimmt dabei eine womöglich erforderliche Interpolation des Audio-Materials, im Falle dieses nicht mit den benötigten Parametern vorliegt (z.B. 44,1 kHz und 16 bit, AirPlay bildet einen Spezialfall, siehe unten). Das behebt das grundsätzliche Problem, das entsteht, wenn der DSP als Master konfiguriert werden muss (weil der Raspberry keine MCLK bereitstellen kann) und somit nicht auf eine Änderung der Sample Rate des abzuspielenden Materials reagieren kann (die Filter im DSP werden immer auf eine feste Sample Rate kompiliert).

Problematik bei der Nutzung von AirPlay

Bei der Nutzung von AirPlay ergibt sich allerdings ein Problem, da Shairport-Sync als verantwortliche Library direkt auf die Soundausgabe zugreift, was im Zuge der Multiroom-Synchronisation natürlich sinnvoll ist. AirPlay sendet und empfängt immer nur in 44,1 kHz oder Vielfachen davon. Eine sinnvolle Interpolation auf der Softwareseite, ohne den Zeitbezug bei der Synchronisation (Multi-Room) zu behindern, ist mir derzeit nicht bekannt.

Die Nutzung von AirPlay muss somit auf der Hardwareseite (ADAU1701 Basis-Clock) gelöst werden. Hierzu wird auf dem DSP-Board der vorhandene 12,288 MHz Quarz durch ein Modell mit 11,2896 MHz ersetzt. Somit kann auf der Softwareseite alles auf 44,1 kHz Abtastrate ausgelegt werden.
Die benötigten Files (eigentlich nur eins) habe ich in eine Repo auf Github gelegt. Dort kann auch der Programmcode eingesehen und ggf. für spezielle Anforderungen angepasst werden. In der Beschreibung ist zudem die notwendige Konfiguration des DSPs enthalten.

Installation

Die Software liegt hier in einem Github Repo:

Link zur Repo
Der Treiber ist mittlerweile als generischer I2S/TDM-Treiber ausgelegt. Für den ADAU1701 bzw. allgemein DSPs (die als Clock-Master laufen) muss das Overlay "generic_audio_out_i2s_slave.dtbo" verwendet werden.
Die Installation ist sehr simpel und gelingt schon mit einer Hand voll Anweisungen in der Kommandozeile oder SSH-Client. Dokumentiert habe ich die Installation rudimentär hier:

Installation Guide.
Dort sind auch noch ein paar Anmerkungen allgemein zum Raspberry und speziell als digitaler Audio-Zuspieler zu finden.

Mittlerweile gibt es auch ein Testprojekt für Sigma Studio, um die Einstellungen und die Verdrahtung der digitalen Ein- und Ausgänge (I2S) des DSPs testen zu können. Dafür wird ein Sinus erzeugt, digital ausgegeben, direkt auf einen digitalen Eingang rückgeführt und auf einen DAC geroutet.

Change Log
--------------------------
Erledigt
- Integration in Volumio
- Taktproblematik mit Airplay aufgedröselt, Fix mittels anderem Quarz getestet
- Sigma Studio Testprojekt zum Testen der digitalen IOs des DSP
- Treiberdateien für alle verschiedenen Anwendungsfälle erstellt: I2S- oder TDM8-Ausgabe, Raspberry als Clock-Master oder -Slave
- Anleitung an generischen Treiber angepasst

In diesem Sinne, schon mal beste Grüße

[Beitrag von MK_Sounds am 25. Okt 2021, 13:26 bearbeitet]

MK_Sounds
Stammgast

#2 erstellt: 21. Mai 2018, 15:47

Hier noch ein Bild vom Test-Setup:

Test setup I2S driver for adau1701 on the raspberry pi

Zu sehen sind der Raspberry, der Sure DSP und der Programmer.
Die Verdrahtung ist zum Testen mit einfachen Jumper-Kabeln gemacht.

Als Testsoftware kann man entweder Audacity verwenden und Töne generieren oder ein paar MP3s auf einen Stick schieben und damit testen. Als Player kann man z.B. LX Music Player verwenden.

[Beitrag von MK_Sounds am 21. Mai 2018, 15:49 bearbeitet]

Autoschrauberix
Stammgast

#3 erstellt: 21. Mai 2018, 15:53

Wow

Ich wollte meinen DSP auch an den Raspi anschließen, dachte aber in meiner grenzenlosen Naivität ich nehme den Treiber vom HifiBery Digi+ und schließe dann den I2S Ausgang des Raspi am I2S Eingang des DSP's an. Nach Deinen Ausführungen hätte ich damit wohl nicht viel Erfolg gehabt.

Sobald ich dazu komme, werde ich Deine Lösung mal testen.

Gruß Fritz

MK_Sounds
Stammgast

#4 erstellt: 22. Mai 2018, 20:03

Autoschrauberix (Beitrag #3) schrieb:

Ich wollte meinen DSP auch an den Raspi anschließen, dachte aber in meiner grenzenlosen Naivität ich nehme den Treiber vom HifiBery Digi+

Das geht in der Tat mit keinem der HifiBerry Treiber! Der DAC+ und kleinere sind als Slave konfiguriert, dementsprechend unbrauchbar. Es kommt hinzu, dass die Chips über I2C initialisiert werden (müssen), wenn auf dem I2C Bus aber kein Device antwortet (was mit dem DSP der Fall ist), wird der Audio-Treiber gar nicht erst eingebunden. Z.B. den DAC+ PRO Treiber müsste man erst modifizieren, denn der kann im Betrieb die Clock-Basis wechseln, was ein DSP ohne ASRC (Asynchronous Sample Rate Converter) wie der ADAU1701 nicht kann.
Bei den größeren Kalibern müsste man sowieso die Clock-Settings anpassen oder den Quarz inklusive Beschaltung der PLL auf dem DSP umlöten.

Sobald ich dazu komme, werde ich Deine Lösung mal testen.

Super

Habe mich heute mit der Integration in Volumio beschäftigt. Verwendet habe ich die aktuelle Version 2.389 vom 2018-03-26.
Die Integration des generischen Treibers ist keine große Sache und funktioniert nun problemlos. Diese habe ich im zugehörigen Artikel auch direkt mit dokumentiert:

Installation Guide mit Einbindung in Volumio.
Mit lokalen Files (NAS müsste auch gehen) funktioniert das bestens.

Problematisch ist aber die Nutzung von AirPlay. Dort kommt es zu zweisekündigen Aussetzern. Ich vermute Probleme mit der Sample Rate und Bittiefe, da AirPlay momentan "nur" 44,1 kHz bei 16 bit kann, der DSP aber 48 kHz bei 24 bit haben will. Die Interpolation von Volumio funktioniert nicht, da der Shairport-sync Service (der für die Emulation des AirPlay-Protokolls zuständig ist) seine Daten direkt auf die Hardware schreibt.
Wenn hier jemand Vorschläge hat, wie man das lösen könnte, immer her damit.

JaccSen
Schaut ab und zu mal vorbei

#5 erstellt: 15. Jul 2018, 15:27

Mega, vielen Dank!
Es besteht doch noch Hoffnung, dass meine 2 Diven endlich aufeinander klarkommen...

Lässt sich der Volumio-Paragraph aus deiner Installationsanleitung auch auf Kodi anwenden?
Si no, was gäbe es dabei anzupassen?

MK_Sounds
Stammgast

#6 erstellt: 07. Aug 2018, 14:56

JaccSen (Beitrag #5) schrieb:

Lässt sich der Volumio-Paragraph aus deiner Installationsanleitung auch auf Kodi anwenden?
Si no, was gäbe es dabei anzupassen? :)

Mit Kodi arbeite ich momentan nicht, entsprechend weiß ich nicht, wie dort die Einbindung neuer I2S-Geräte gemacht wird. Aller Wahrscheinlichkeit nach lässt sich die Vorgehensweise von Volumio aber auf Kodi adaptieren. Die I2S-Geräte werden genauso in einem File liegen, das man entsprechend finden und anpassen müsste. Google wird dazu vermutlich weiterhelfen.

Momentan arbeite ich an der Funktionsfähigkeit von Airplay. Dazu habe ich testweise den Quarz auf dem DSP durch einen mit 11,2896 MHz ersetzt. Damit läuft dann alles auf 44,1 kHz Basis. Soweit funktioniert das grundlegend bestens.
In Shairport kann dann noch die Bittiefe angepasst werden, damit die Konfiguration der Frames passt.
Hier gibt es irgendwo noch ein Problem bei den Einstellungen, dass zu einem leichten, zyklischen Knacken (evtl. Bitfehler oder leichter Versatz bei der Synchronisierung) führt.
Muss ich mir bei Gelegenheit auf dem Oszi anschauen und beheben.

Das aktuelle Testsetup hat sich nicht viel verändert (nur etwas ordentlicher

Testaufbau 2, I2S Driver Raspberry Pi ADAU1701

JaccSen
Schaut ab und zu mal vorbei

#7 erstellt: 20. Aug 2018, 16:09

Der Treiber ließ sich bei mir nach deiner Anleitung ohne Probleme in Volumio (RPi 3B & RPi3B+) integrieren.
Doch trotz der m.m.N. korrekten Verbindung der Pins und softwareseitiger Einstellungen in Volumio und Sigma Studio schaff ich es nicht, dass ein Audiosignal am DSP anliegt.

Ich bin leider nach den etlichen gescheiterten Versuchen über Monate hinweg die Elektronik mit I2S zum Laufen zu bekommen total demotiviert. Trotzdem möchte ich aber die 2 LS Prototypen, in die ich schon soviel Zeit und Geld gesteckt habe endlich (digital) zum Laufen bekommen.

Ich würde daher in meiner Verzweiflung gerne folgenden Vorschlag machen.

Wer sachkundig ist und Lust hat, MK_Sounds I2S Verbindung zwischen Volumio und dem RPi zu testen oder anderweitig mit der Hardware zu experimentieren, dem schicke ich frei Haus zwei RPi mit Speicherkarten (3B & 3B+), DSP, Programmer und alle wichtigen Kabel zu.

Ihr übernehmt keinerlei Verantworung, versucht aber letztendlich die I2S Verbindung zwischen RPi (Volumio) und dem DSP herzustellen und mir das Komplettpaket im Laufe der nächsten 2-3 Monate wieder zurückzuschicken.

Wer Lust hat, bitte per PN melden.

MK_Sounds
Stammgast

#8 erstellt: 20. Aug 2018, 16:50

JaccSen (Beitrag #7) schrieb:

Hast du mal Tests unter Raspbian gemacht ?

Tests unter Volumio:
- mit lokalen Files ?
- Interpolation auf 48 kHz aktiv ?
- ansonsten auch mal ohne Interpolation mit lokalen Audiofiles mit 48 kHz Samplerate getestet ?

Airplay und der Mod mit dem Umbau des DSP auf 44,1 kHz Basis funktioniert noch nicht vollständig, da muss ich noch Feintuning machen.

JaccSen
Schaut ab und zu mal vorbei

#9 erstellt: 23. Aug 2018, 15:02

Hallo Markus,
Tests unter Rasbian habe ich keine gemacht. Die Tests unter Volumio hingegen schon.

Ich habe heute einen Hifiberry Newsletter bekommen, indem ein Dac+ DSP für Anfang September angekündigt wurde.

https://www.hifiberr...grid&utm_medium=mail
Das scheint für mich elektrotechnischen Analphabeten die Lösung zu sein - Plug and Play #fingerscrossed

DSP_FAN
Neuling

#10 erstellt: 06. Jan 2019, 02:36

Hallo, vielen dank erst einmal für die Anleitung und die Programmierung des Treibers !

Wie muss ich die register des ADAU1701 einstellen, damit diese mit dem Raspberry funktioniernen ?
Ich kann nicht alles in den Registern finden:

Konfiguration - ADAU1701 (ist manuell in Sigma Studio vorzunehmen)
Sample rate: 48 kHz---OK allgemeine Festlegung im Projekt
Bit depth: 24 bit---OK ( nicht einstellbar)
Data format: I2S---OK

Clock master at the I²S output
MCLK = 256 * Fs = 12.288 MHz ( nicht einstellbar, ist das die Quarzfrequenz ?)
BCLK = 64 * Fs = 3.072 MHz --> Internal / 16---OK
LRCLK = Fs = 48 kHz --> Internal / 1024---OK

LRCLK polarity: falling edge (LRCLK = 0 = left channel, LRCLK = 1 = right channel) ---OK
BCLK data change: falling edge ---OK
Transmission: MSB first --- ( nicht einstellbar)
MSB position: delayed by 1 BCLK
---- Frame Sync fehlt in der Beschreibung.

Für einen Test nur mit dem ADAU1701 habe ich dem Ausgang DIG0 einen Sinusgenerator aufgeschaltet.
Den ersten I2S Eingang ( 2) habe ich auf einen Analogen Ausgang geführt. Diese Verschaltung hat funktioniert, nachdem ich die I2C Verbinung zum PC unterbrochen habe.

So soll die Einstellung für den Raspberry sein, oder nicht ?

Nur kommt vom Raspberry noch kein Ton...

Vielleicht hat jemand einen Tipp..
Gruß !

[Beitrag von DSP_FAN am 06. Jan 2019, 15:27 bearbeitet]

tskemper
Neuling

#11 erstellt: 30. Mai 2019, 16:07

Hallo zusammen,

ich versuche auch seit Tagen, die beschriebene Kombination ans Laufen zu bringen. Leider kriege ich es auch nicht hin: ich höre keinen Ton am Ausgang des 1701.

Kann es am Raspberry-Model liegen? Ich habe einen 3A+, auf dem Bild ist ja ein 2B V1.1 abgebildet.

Wenn ich eine .WAV-Datei abspielen will, hängt der Raspberry sozusagen direkt am Anfang des Liedes fest, wenn ich mit aplay abspiele.

Der ADAU1701 läuft, wenn ich ein analoges Signal am Eingang habe, kann ich es problemlos am Ausgang hören.

Irgendeine Idee, wie man die Schaltung prüfen kann?

Herzlichen Dank!

Thomas

MK_Sounds
Stammgast

#12 erstellt: 31. Mai 2019, 16:11

tskemper (Beitrag #11) schrieb:

Kann es am Raspberry-Model liegen? Ich habe einen 3A+, auf dem Bild ist ja ein 2B V1.1 abgebildet.

Der Treiber ansich ist hardwareunabhängig. Alle Kernel ab Version 4.9.80-v7+ müssten funktionieren.
Einen Raspberry 3 habe ich leider nicht zur Hand, um das selbst zu testen.

Wenn ich eine .WAV-Datei abspielen will, hängt der Raspberry sozusagen direkt am Anfang des Liedes fest, wenn ich mit aplay abspiele.
Irgendeine Idee, wie man die Schaltung prüfen kann?

Der Treiber funktioniert. Wenn man kein Airplay nutzen will auch mit dem standard Quarz auf dem DSP (Bluetooth wäre gangbar).
Was zeigt dir denn die Ausgabe von "aplay -l". Wird das Audiodevice richtig erkannt?

Im Grunde kann man nicht sonderlich viel falsch machen, wenn man sich an die Anleitung hält. Ich vermute evtl. liegt es an der Einstellung des DSP. Wie man die digitalen Ein/Ausgänge verwendet ist im Sure DSP Wiki beschrieben. Am besten dort schauen und die Konfig prüfen.
Zum Überprüfen der digitalen Ports des DSP kannst du einen einfachen Loopback mit zB einem Sinus machen (Sinusgenerator -> digital out -> digital in -> analog out).
Clocks prüft man am einfachsten mit einem Oszi.

Die Anleitung habe ich etwas gekürzt. Der Block mit den speziellen Settings fürs Airplay ist rausgeflogen, da nicht notwendig.
Ich werde bei Gelegenheit auch mal Bluetooth mit Volumio testen. Das muss man aber manuell dazu installieren. Ich werde das dann auch dokumentieren.
Die Testschaltung der digitalen IOs des DSP werde ich dann auch beschreiben.

MK_Sounds
Stammgast

#13 erstellt: 01. Jun 2019, 16:28

Update:
Ich habe ein Testprojekt für Sigma Studio erstellt, in dem die digitalen Ein- und Ausgänge des DSP mit einem Sinus getestet werden können. Die Pins sind alle als digitale IOs zugewiesen. Das Testprojekt dient der Überprüfung der Einstellungen des DSPs und der DSP-seitigen Verdrahtung. Das Testprojekt kann somit für alle Projekte mit digitalen Ein-/Ausgängen verwendet werden (nicht nur in Kombi mit dem Raspberry).

Die Notwendige Verdrahtung ist wie üblich bei digitaler Zuspielung. Takte werden rückgeführt, Ausgang 0 testweise mit Eingang 0 verbunden.
MP5 mit MP11
MP4 mit MP10
MP6 mit MP0

Das Projekt muss man im Grunde nur herunterladen (File liegt ebenfalls im Github Ordner), öffnen, auf den DSP flashen und den Sinus-Generator einschalten. Dann sollte Pegel in der Anzeige zu sehen sein (oder zu hören).
Anbei ein Bild des Schematic:

Sigma Studio ADAU1701 I2S Test digital Audio Port

tskemper
Neuling

#14 erstellt: 01. Jun 2019, 18:35

Hallo Markus,

danke für die Antwort und die Hilfestellung! Die Sache mit dem Test-Sinuston, den Du erzeugst, digital ausgibst und am Eingang wieder einspeist, war eine gute Idee. Das hat nämlich bei mir auch nicht funktioniert, aber dadurch bin ich der Sache auf den Grund gekommen: Sobald ich den Raspberry Pi vom DSP abgeklemmt hatte, funktionierte der Sinus nämlich.
Dann habe ich tatsächlich bemerkt, daß ich doch zwei Pins am Raspberry vertauscht habe, obwohl ich alles mehrfach kontrolliert hatte.
Gleichzeitig habe ich aber auch irgendein Kabelproblem: die beiden Platinen habe ich getrennt auf zwei Europa-Platinen montiert, die dann in ein 19"-Gehäuse gesteckt werden. Wenn ich die Verbindungsleitungen hinten an den Steckern bewege, ändert sich massiv die Tonqualität von sehr gut bis komplett weg. Möglicherweise sollte man die Leitungen mit dem hochfrequenten digitalem Signal doch nicht so lang machen und vor allem nicht über längere Strecken parallel verlaufen lassen.

Wie auch immer. Es läuft. Das Leitungsproblem werde ich lösen.

Danke für den Tipp und den Treiber!

Thomas

chboor
Schaut ab und zu mal vorbei

#15 erstellt: 02. Mai 2020, 19:20

Hallo in die Runde,

da das Thema so gut passt, hole ich mal diesen Thread wieder hoch und hoffe auf freundliche Unterstützung. Mein aktuelles Projekt basiert auf dem ADAU1701 in Form eines Wondom TPA230, mit dem ich (leider) bereits einige Erfahrung sammeln durfte. So ist in der Dokumentation der Pin MP6 fälschlicherweise als MP7 bezeichnet, der wiederum als DATA bezeichnet wird. Das aber nur nebenbei, sonst komme ich eigentlich gut klar damit.

Mein Ziel ist nun, einen Raspi Zero W per I²S anzubinden und mit Volumio zu füttern. Dazu nutze ich den dankenswerterweise von MK_Sounds bereitgestellten Treiber auf einer frischen, aktuellen Volumio-Installation. Leider aber noch nicht erfolgreich.

Das Problem ist, dass die Wiedergabe stark verzerrt, fast wie übersteuert wirkt. Bereits auf kleinster Lautstärkestufe (entspricht laut asound.conf -50dB) ist das Signal so laut, dass auch sehr leise Musikpassagen direkt ins Clipping gehen. Lautere Musik lässt sich aufgrund der starken Verzerrung gar nicht als solche erkennen. Das Phänomen tritt auf, egal ob ich Softvolume aktiviere, ob ich Resampling nutze oder bei abgeschaltetem Resampling eine native 24bit-48kHz-Datei abspiele. Auch wenn ich per speaker-test manuell auf Alsa zugreife, ist das Signal genauso kaputt. Für mich ergibt sich daraus, dass die Zuspielung zu Alsa nicht das Problem ist.

Die I²S-Schnittstelle auf DSP-Seite habe ich ziemlich sicher auch richtig konfiguriert, da das Testbeispiel aus dem Git-Repository wunderbar und ohne irgendeine Störung funktioniert. Sobald ich das Sinussignal des Testprojekts durch den Ausgang des Raspi ersetze zeigt sich das gleiche, oben beschriebene Verhalten. Lade ich mein eigenes Programm in den DSP bringt das erst recht keine Verbesserung.

Es scheint also, dass der Fehler irgendwo zwischen ALSA und der I²S-Schnittstelle liegt (und natürlich vor dem Bildschirm

) Leider war ich mit meiner Fehlersuche bisher nicht erfolgreich. Die einzige, mir bisher aufgefallene Unstimmigkeit ist, dass im dts-File der bcm2708 angegeben ist und nicht der im Raspi verbaute bcm2835. Ob das aber einen Unterschied macht, weiß ich beim besten Willen nicht…

Falls jemand irgendeinen Hinweis hat, wäre ich sehr dankbar dafür! Ich krebse jetzt schon eine ganze Weile damit herum und komme einfach nicht weiter.

Beste Grüße Christian

MK_Sounds
Stammgast

#16 erstellt: 02. Mai 2020, 21:23

Hallo Christian,

welche Version von Volumio nutzt du denn?
Poste mal bitte den Output von:
> uname -a
und
> aplay -l

chboor
Schaut ab und zu mal vorbei

#17 erstellt: 03. Mai 2020, 12:14

Hallo,

Danke für die Antwort, das ging ja fix! Dann will ich mal schnell liefern, hätte ich mir ja eigentlich denken können…

Volumio ist die aktuelle 2.729
volumio@test:~$ uname -a
Linux test 4.19.86+ #1283 Fri Nov 29 18:27:21 GMT 2019 armv6l GNU/Linux

volumio@test:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 7/7
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Output [ADAU1701 I2S Output], device 0: bcm2835-i2s-dit-hifi dit-hifi-0 [bcm2835-i2s-dit-hifi dit-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Zusätzlich noch die /boot/config.txt:
nitramfs volumio.initrd
gpu_mem=32
max_usb_current=1
dtparam=audio=on
audio_pwm_mode=2
dtparam=i2c_arm=on
disable_splash=1
hdmi_force_hotplug=1

include userconfig.txt

#### Volumio i2s setting below: do not alter ####
dtoverlay=adau1701-i2s

MK_Sounds
Stammgast

#18 erstellt: 03. Mai 2020, 17:25

chboor (Beitrag #17) schrieb:

Hallo,
Danke für die Antwort, das ging ja fix! Dann will ich mal schnell liefern, hätte ich mir ja eigentlich denken können…
Volumio ist die aktuelle 2.729
(...)

Hallo Christian,
das passt wie zu erwaten alles (Kontrolle ist aber besser

).
In Volumio wurden zwar im letzten halben Jahr größere Änderungen in der Oberfläche vorgenommen und teilweise neue Features implementiert, es ist mir aber nicht bekannt, dass das die älteren Treiber beeinflusst. Genau aus dem Grund hat man den Device Tree eingeführt. Einerseits um die Verwaltung der Treiber und der Kernels zu vereinfachen, andererseits um konsistente Software zu haben, die auch in Zukunft kompatibel ist.

Um dort 100% sicher zu sein, habe ich das gerade selbst noch mit einem Raspi 3b+ geprüft. Aktuelle Volumio-Version, kompletter Clean-Install, exakt nach der Anleitung vorgegangen, kein Resampling aktiv, Test mit Airplay-Stream auf 44,1 kHz-Basis: funktioniert ohne Probleme.
Ein Problem auf der Software-/Zuspielseite halte ich eher für unwahrscheinlich. Ich denke da ist eher was im DSP oder in der Verdrahtung schief gegangen.

Bei der Beschreibung deines Fehlerbilds kommt mir zunächst ein Fehler der Position der Daten im Slot in den Sinn. Ich kenne das Problem wenn die Daten nicht sauber "links" aligned sind (MSB beginnt auf Bit 0), sondern ein Byte zu weit "links". Das äußert sich dann auch in sehr hohem und dementsprechend verzerrtem Pegel.
Hast du ggf. irgendwo am Datenformat etwas geändert?
Ich würde dir zunächst mal die Überprüfung der Verdrahtung empfehlen. Wenn das nichts nützt eine Neuinstallation machen (Clean-Install). Dann nochmal Rückmeldung geben. Einen RPi Zero W könnte ich zum Test zur Not noch auftreiben, damit ich es auf der gleichen Hardware testen kann.

Das compatible-Feld im Overlay wird übrigens beim Erstellen des Device Trees beim Bootup (noch) nicht geprüft. Dass dort noch bcm2708 steht ist somit nicht schlimm. Das könnte ich aber für die ferne Zukunft mal anpassen.

[Beitrag von MK_Sounds am 03. Mai 2020, 17:26 bearbeitet]

chboor
Schaut ab und zu mal vorbei

#19 erstellt: 10. Mai 2020, 20:24

Hallo Markus,

vielen Dank für die Hinweise und dein Engagement! Folgendes habe ich mittlerweile probiert, erfolgreich war ich aber leider nicht:
- Verkabelung überprüft. Dabei habe ich einerseits die Pinbelegung des Wondom-Boards mit einer Drahtbrücke gegengeprüft, andererseits die elektrische Verbindung von Quelle bis Ziel durchgeklingelt. Einen Fehler will ich hier natürlich nicht kategorisch ausschließen, jedoch mag mir kein Szenario einfallen, bei dem ein Verkabelungsfehler ein solches Verhalten verursacht.
- Volumio ein weiteres Mal frisch installiert und genau nach Anleitung konfiguriert.
- Dein Testprojekt in den EPROM geladen und den DSP frisch gebootet. Die Übertragung des Sinus funktioniert wunderbar. Wenn ich die Brücke entferne und stattdessen vom Raspi zuspiele, stellt sich wieder das bekannte Phänomen ein.
- Den Raspi Zero W durch einen alten, treuen Raspi 2 Model B ersetzt. Auch dieser zeigt das gleiche Verhalten.

Hast du noch eine weitere Idee, was ich tun könnte? Bei mir wächst das Gefühl, dass mir nichts anderes übrig bleibt als mir mal ein Oszi zu organisieren und das Signal ganz genau unter die Lupe zu nehmen.

Beste Grüße Christian

MK_Sounds
Stammgast

#20 erstellt: 10. Mai 2020, 20:44

Hallo Christian,

hast du den Post im Sure DSP Thread gesehen? Dort wird ein vergleichbares Fehlerbild mit einem DSP-Amp beschrieben.

Link.
Hast du zufällig ein reines DSP-Board zum Testen zur Hand?

Wie bereits an anderer Stelle erwähnt, habe ich den Treiber nur mit dem reinen DSP-Board getestet. Die Amps mit integriertem DSP besitze ich nicht, testen entsprechend nicht möglich.

chboor (Beitrag #19) schrieb:

Hallo Markus,
Hast du noch eine weitere Idee, was ich tun könnte? Bei mir wächst das Gefühl, dass mir nichts anderes übrig bleibt als mir mal ein Oszi zu organisieren und das Signal ganz genau unter die Lupe zu nehmen.

Nun, genau das hätte ich dir als einfachstes Debugging-Mittel empfohlen. Nachdem du schon diverse Hardware auf Raspberry-Seite getestet hast, würde ich vermuten, dass der gemeinsame Nenner eher der Amp ist, sprich dort irgendwas in der Konfig nicht hinhaut.

Was mir noch einfällt: Bitte die Polarität des Bitclock im Amp prüfen. Einfach mal in Sigma Studio invertieren. Ansonsten am besten auch mit dem Oszi prüfen.

[Beitrag von MK_Sounds am 10. Mai 2020, 20:47 bearbeitet]

rogle
Neuling

#21 erstellt: 10. Mai 2020, 22:12

Hallo,

habe in der Tat ein ähnliches Fehlerbild (siehe link von zuvor). Dort (Sure DSP Thread, S.44) habe ich versucht, ein aussagekräftiges Oszi-Bild einzustellen (es ist am oberen Ende meiner Möglichkeiten). Für mich scheint es, als kämen die Signale aus dem Raspberry PI "zu spät"...

Umschalten der Polarität LRCK im Sigma-Studio habe ich ohne Erfolg hinter mir. Auch Verändern der Wartetakte half bei mir nicht.

Ich bin mir nicht sicher, ob alsa aus 24bit-Daten wie gewünscht doch etwa 16bit-Daten erzeugt: noch suche ich. Weiter will ich versuchen, das dtoverlay i2s-mmap zu aktivieren: möglicherweise hilft dann alsa durch Zuschalten des Mixers im erwarteten Sinn.

adafruit schreibt, man solle
aplay /dev/zero
auf die "Karte" ausgeben, um Aussetzer der Synchronisation zu vermeiden: noch nicht versucht.

Hat der Takt des raspberry einen Einfluß? Und wie synchronisiert der "PWM-Ausgang"?

Für gute Hinweise bin ich dankbar.

Gruß Rolf

MK_Sounds
Stammgast

#22 erstellt: 13. Mai 2020, 09:26

rogle (Beitrag #21) schrieb:

Bitte mal ein aussagekräftiges Oszi-Bild erstellen. Mit Bclk, LRCLK und der Datenleitung.

Ich bin mir nicht sicher, ob alsa aus 24bit-Daten wie gewünscht doch etwa 16bit-Daten erzeugt: noch suche ich.

Im default sollte da eigentlich nichts anbrennen. Im Overlay/Treiber wird die Slotbreite mit 32 Bit gesetzt. Wenn die Bittiefe des Quellmaterial niedriger ist, wird eben mit Nullen aufgefüllt. Da der Raspberry als Slave läuft (bekommt die Clocks von extern), kann beim Datenformat eigentlich nahezu nichts schief gehen, da die Daten im Prinzip "hart" von außen in den Slot "gepresst" werden.

Hat der Takt des raspberry einen Einfluß? Und wie synchronisiert der "PWM-Ausgang"?

Was meinst du mit PWM-Ausgang? Die Audiodaten werden per I²S übertragen.

rogle (Beitrag #2185) schrieb:

Das dspproj-File des JAB3-230 auf einem Sure-Kernel-Board (ADAU1701 pur) liefert guten Ton, diesen allerdings unverstärkt...

Im Nachbarthread hast du geschrieben, dass mit dem nackten DSP-Board alles funktioniert?! Das würde ja zwingend einen Fehler beim Amp implizieren.

Ich würde am einfachsten mal eine andere I²S-Quelle testen, um herauszufinden, ob das Problem auf der Zuspielseite liegt.

rogle
Neuling

#23 erstellt: 17. Mai 2020, 11:57

Hallo,

wie zuvor gewünscht bin ich aktiv geworden. In einer Testkonfiguration wurde Bild 1 aufgenommen: die Signale sind wie erwartet. Feinjustierungen in den Registern des ADAU1701 führen zu Veränderungen wie erwartet: alles scheint ok. Zum Ansatz kamen die Anleitungen aus

https://github.com/MKSounds/ADAU1701-I2S-Audio-Driver-for-Raspberry-Pi.git

Die Signale des JAB3-230 wurden auf ein MAX98357A geleitet: auch dort erscheint der gewünschte Ton, alles gut.

Nun wurden BCLK an den Raspi angehängt: er erzeugt Daten, die nicht synchronisiert sind (nicht verwunderlich). Als nächstes wurde RLCLK angehängt: es werden Daten erzeugt, ohne Orientierung an RLCLK, siehe Bild2. Der MAX98357A gibt keinen Ton von sich. Datenquelle war

speakertest -r 48000 -c 2 -t wav (oder sine -f 440).

Es scheint, als fehle die Synchronisation...

zu MK_SOUND (zitieren kann ich noch nicht):
1) Habe nur Raspis als Quelle. Was könnte ich ersatzweise benutzen? Hifiberry nur mal eben ist mir zu teuer.
2) Mehrfachbelegung GPIOs: ich dachte, der GPIO sei mehrfach, auch für PWM belegt. Ist wohl unbegründet. I2C ist definitiv ausgeschaltet. Sonst nutze ich ein aktuelles Raspbian Lite in minimaler Ausstattung (headless). Zusätzliche Software wurde fast nicht geladen.
3) Müssen die GPIOs initialisiert werden z.B. durch wiring Pi oder python?

MK_Sounds
Stammgast

#24 erstellt: 17. Mai 2020, 19:56

rogle (Beitrag #23) schrieb:

Da scheint in der Tat der LRCLK nicht korrekt verarbeitet zu werden. Ein Grund, wie das passieren kann, fällt mir gerade auch (noch) nicht ein.
Bitte mal die Ausgabe folgender Kommandos posten:
> uname -a
> aplay -l
> lsmod

3) Müssen die GPIOs initialisiert werden z.B. durch wiring Pi oder python?

Nein, eine Konfiguration ist außer dem Einbinden des Treibers/Overlays nicht notwendig.

1) Habe nur Raspis als Quelle. Was könnte ich ersatzweise benutzen?

Die Frage war nur für den Fall, dass du zufällig irgendwas zur Hand hast.
Hast du mal mit einer anderen Distribution z.B. Volumio getestet?

rogle
Neuling

#25 erstellt: 18. Mai 2020, 00:08

Hallo MK_Sounds,

habe mittlerweile mit hifiberry-dac experimentiert: an meinem Internetradio (Sabre ES9023) gibt das Overlay alle benötigten Signale (CLK, LRCLK, DATA) aus. Der MAX98357A arbeitet damit als slave. Bei Parallel-Schaltung des JAB3 bricht das Signal ein: CLK an MP05 wird stark gedämpft. Hier suche ich in der neuen Woche.

Zu den Fragen übermittle ich:

1) aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Output [ADAU1701 I2S Output], Gerät 0: bcm2835-i2s-dit-hifi dit-hifi-0 [bcm2835-i2s-dit-hifi dit-hifi-0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0

2) uname -r
5.4.35+

3) lsmod
sg, uas, sha256_generic, libsha256, cfg80211, rfkill, 8021q, garp, stp, llc, raspberrypi_hwmon, hwmon, snd_soc_rpi_simple_soundcard, snd_soc_bcm2835_i2s, regmap_mmio, snd_soc_pcm5102a, snd_soc_core, snd_compress, snd_pcm_dmaengine, snd_pcm, snd_timer, snd, uio_pdrv_genirq, uio, fixed, ip_tables, x_tables, ipv6, nf_defrag_ipv6

(Der Ausdruck lsmod sah schlimm aus, da Tabulatoren ein Eigenleben führen).

MK_Sounds
Stammgast

#26 erstellt: 18. Mai 2020, 13:00

Hast du den Kernel manuell geupdatet? Weil das passt nicht so recht zusammen:

rogle (Beitrag #23) schrieb:

Sonst nutze ich ein aktuelles Raspbian Lite in minimaler Ausstattung (headless). Zusätzliche Software wurde fast nicht geladen.

rogle (Beitrag #25) schrieb:

2) uname -r
5.4.35+

Das aktuelle Raspbian Lite (Buster) basiert auf Kernelversion 4.19. Beim Kernel 5 gab es auf jeden Fall diverse Änderungen auch in den Audio-Modulen. An sich dürfte das die Abwärtskompatibilität aber nicht beeinflussen. Ggf. haben wir allerdings einen Bug in Raspbian gefunden.

Bei Parallel-Schaltung des JAB3 bricht das Signal ein: CLK an MP05 wird stark gedämpft. Hier suche ich in der neuen Woche.

Der Raspberry kann ja nicht gleichzeitig Master und Slave sein. Das gibt entsprechend Sauereien bei den Clocks.

3) lsmod
snd_soc_rpi_simple_soundcard,
snd_soc_bcm2835_i2s,
snd_soc_pcm5102a,

Das passt nicht so recht zusammen. Hast du da einen munteren Treiber-Mischmasch mit den Hifiberry-Treibern produziert?
Der Treiber für den adau1701 ist auf jeden Fall nicht geladen ( das Modul snd_soc_spdif_tx fehlt).
Habe auf github mal einen Log der Ausgabe der drei Kommandos hochgeladen (File: "status_log.txt"):

Link.
Das ist eine funktionierende Konfiguration mit Volumio 2.773

[Beitrag von MK_Sounds am 18. Mai 2020, 13:01 bearbeitet]

rogle
Neuling

#27 erstellt: 18. Mai 2020, 22:43

Hallo Markus,

habe Dank für Deine Mühen! Werde es mit einer neuen Installation versuchen: in der Tat habe ich enttäuscht auf ziemlich vielen Knöpfen rumgedrückt...

Der Ausflug zu Hifiberry hat gezeigt, daß der Raspberry schöne Rechtecke erzeugen kann, nicht aber der JAB3, siehe Oszillogramme zuvor.

Heute habe ich 5 Kondensatoren am Eingang ausgelötet - und erstmalig befriedigenden Ton erhalten. Links/Rechts funktioniert noch nicht, aber das kommt vielleicht beim Neuaufsetzen des Raspberry. - Die Signale lassen sich nun von zwei "Slaves" nutzen: Freude. Unten die neuen Oszillogramme.

Es scheint, als gäbe der Raspberry nur 16bit aus - im Vergleich zu früher fast schon ein niedliches Problem.

Ich suche weiter.

Gruß Rolf

rogle
Neuling

#28 erstellt: 19. Mai 2020, 23:04

Die Maßnahmen haben Freude bereitet: erstmals gab es unverzerrten Ton in der Endstufe...

speaker-test: rechter und linker Kanal sind gelegentlich vertauscht in der Endstufe...

alsamixer: es gibt nichts einzustellen... Muß ich einen alsa-Mixer "emulieren"?

Neu aufgesetztes Raspbian läd nahezu alle Module, nicht jedoch
snd_bcm2835 snd_seq snd_seq_device und auch nicht
overlay
Entgeht mir dadurch etwas?

Das Lernen geht weiter. Vielen Dank!

MK_Sounds
Stammgast

#29 erstellt: 20. Mai 2020, 12:39

rogle (Beitrag #28) schrieb:

Die Maßnahmen haben Freude bereitet: erstmals gab es unverzerrten Ton in der Endstufe...

Sehr gut

Das heißt, das Problem mit dem JAB3-230 kommt von dessen Hardware-Beschaltung der Clock-Pins des I²S?

alsamixer: es gibt nichts einzustellen... Muß ich einen alsa-Mixer "emulieren"?

Der Treiber ist nur ein sehr einfacher Basistreiber, der lediglich die notwendige Konfiguration des I2S-Interface für den DSP macht.
Etwaige Controls, Mixer, hardware Volume etc. gibt es nicht. Die müsste man sich bei Bedarf selbst dazu programmieren.
Software volume geht. Das genügt für z.B. Volumio. Bei Raspbian kann es sein, dass die Bedienelemente für die grafische Oberfläche allerdings fehlen.

Neu aufgesetztes Raspbian läd nahezu alle Module, nicht jedoch
snd_bcm2835 snd_seq snd_seq_device und auch nicht
overlay
Entgeht mir dadurch etwas?

Erlaubt ist, was funktioniert

Der Test-Log den ich hochgeladen habe war sowieso mit Volumio. Da werden entsprechend nicht alle Module gleich sein wie beim Test unter Raspbian (Lite). Ich werde den Log mal noch auf die wesentlichen, zur Soundausgabe notwendigen, Module einkürzen.

[Beitrag von MK_Sounds am 20. Mai 2020, 12:44 bearbeitet]

chboor
Schaut ab und zu mal vorbei

#30 erstellt: 30. Mai 2020, 10:27

Hallo Markus, hallo Rolf,

vielen Dank für die guten Hinweise! Bei mir läuft die Combo aus Raspi und Jab3-230, bzw. TPA230 jetzt sehr zufriedenstellend.
Letztlich ermöglichten die Hinweise zur Eingangsbeschaltung des Jab3-230, bzw. TPA230 die Lösung. Es sieht ganz danach aus, als sei jeweils ein RC-Tiefpass an den acht herausgeführten Eingangspins eingelötet. Das ist natürlich unpraktisch, wenn man hochfrequent Rechtecksignale übertragen will. Jedenfalls reichte bei mir das auslöten der Kondensatoren, die Widerstände habe ich der Einfachheit wegen einfach unberührt gelassen. Es läuft jetzt trotzdem wunderbar mit dem Raspi Zero W.

Beste Grüße Christian

rogle
Neuling

#31 erstellt: 30. Mai 2020, 22:05

Hallo,

mit den Fortschritten bin ich - trotz Licht nach langer Durststrecke - noch nicht zufrieden.

Der Ton (livestream) funktioniert - aber nur mit kleinen Aussetzern. Manchmal kommen noch häßliche Knack-Geräusche dazu (lästig bei 30W Power): diese hatte ich auf langsamen Datennachschub aus dem Netz geschoben, was aber nicht alles erklärt. Sinuston von der lokalen Festplatte wird mit Aussetzern wiedergegeben.

Am Netzteil liegt es nicht: mit dem Original-Netzteil wird es nicht besser.

Bisweilen ist mir nicht gelungen, auf alsa mehr als 16 bit auszugeben. Zuletzt kam noch der Hinweis:

"ALSA lib pcm.c:7566:(snd_pcm_slave_conf) Unknown field period_time"

Offenbar hatte ich "slave" vor dem Punkt vergessen... Eigentlich wollte ich den Buffer beeinflussen (alsa ist mysteriös). - Ich suche noch.

Ich nutze - aus Pietät - meinen ersten Raspberry, Version 1.0 (damals mußte ich 3 Monate warten...). Mit dem sabre-Breakout-Board und einem kleinen Verstärker ist Musikhören über Jahre hinweg gelungen: es scheint, als könne dieses Frequenzschwankungen bis zu 44.1kHz ausgleichen. Die Signale kommen aus den GPIO 28, 29 und 31, (Modus Alt-2), abgegriffen an den Widerständen: alles sieht wie erwartet im Oszillografen aus. Ohne Tonausgabe lassen sich die GPIOs wie erwartet ansteuern.

Ist Version 1.0 überfordert? Bringt es etwas, Module und/oder Overlays neu zu übersetzen? Gibt es noch Ratschläge?

Grüße

Paddy_B
Neuling

#32 erstellt: 02. Okt 2020, 16:01

Servus zusammen,

erstmals danke für die wunderbare Arbeit.

Ich habe folgende Konfiguration getestet:
Raspberry 3B+ mit Moodeaudio (auf Raspbian basierend), Kernel 5.4.51-v7+.

Mit dem Testprogramm bekomme ich einen Sinuston am Ausgang und ich kann auch per Pi Audiofiles abspielen. Also grundsätzlich funktioniert die Kommunkiation zwischen Pi und dem Wondom DSP Board.

Nun zu meinem Problem:
Nach ungefähr 15sek (Zeit nicht immer gleich) reibungsloser Soundausgabe fängt die Wiedergabe an zu haken. Pausiere ich und drücke dann wieder Play, startet dieses Spiel auch wieder von vorne.
Manche Lieder werden auch etwas schneller abgespielt was mich stark darauf tippen lässt, dass etwas mit der Sampleratenkonvertierung nicht passt.

Meine Testfiles waren bis jetzt 44.1kHz bei 24bit. Ich werde es mit 48kHz auch probieren.

Bei der Installation bin ich wie in der Anleitung beschrieben vorgegangen.

Hier noch mein Output von lsmod:

Module Size Used by
evdev 24576 1
uinput 20480 1
cmac 16384 1
bnep 20480 2
hci_uart 40960 1
btbcm 16384 1 hci_uart
bluetooth 376832 30 hci_uart,bnep,btbcm
ecdh_generic 16384 2 bluetooth
ecc 32768 1 ecdh_generic
8021q 32768 0
garp 16384 1 8021q
stp 16384 1 garp
llc 16384 2 garp,stp
brcmfmac 319488 0
brcmutil 16384 1 brcmfmac
sha256_generic 16384 0
libsha256 20480 1 sha256_generic
snd_soc_simple_card 20480 1
snd_soc_simple_card_utils 24576 1 snd_soc_simple_card
cfg80211 679936 1 brcmfmac
raspberrypi_hwmon 16384 0
rfkill 28672 6 bluetooth,cfg80211
bcm2835_codec 36864 0
bcm2835_isp 32768 0
i2c_bcm2835 16384 0
bcm2835_v4l2 45056 0
v4l2_mem2mem 32768 1 bcm2835_codec
bcm2835_mmal_vchiq 28672 3 bcm2835_isp,bcm2835_codec,bcm2835_v4l2
videobuf2_dma_contig 20480 2 bcm2835_isp,bcm2835_codec
snd_soc_spdif_tx 16384 1
snd_soc_bcm2835_i2s 16384 2
videobuf2_vmalloc 16384 1 bcm2835_v4l2
videobuf2_memops 16384 2 videobuf2_dma_contig,videobuf2_vmalloc
videobuf2_v4l2 28672 4 bcm2835_isp,bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
videobuf2_common 57344 5 bcm2835_isp,bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
snd_soc_core 200704 4 snd_soc_spdif_tx,snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_simple_card
snd_compress 20480 1 snd_soc_core
videodev 237568 6 bcm2835_isp,bcm2835_codec,videobuf2_common,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_pcm 94208 3 snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_core
mc 45056 6 bcm2835_isp,bcm2835_codec,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2
snd_timer 32768 1 snd_pcm
vc_sm_cma 32768 1 bcm2835_mmal_vchiq
snd 69632 6 snd_compress,snd_timer,snd_soc_core,snd_pcm
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
fixed 16384 0
ip_tables 28672 0
x_tables 32768 1 ip_tables
ipv6 450560 54
nf_defrag_ipv6 20480 1 ipv6

Ich hoffe es ist hier noch wer aktiv der mir helfen kann

.

LG,
Patrick

MK_Sounds
Stammgast

#33 erstellt: 05. Okt 2020, 11:08

Paddy_B (Beitrag #32) schrieb:

Mit dem Testprogramm bekomme ich einen Sinuston am Ausgang und ich kann auch per Pi Audiofiles abspielen. Also grundsätzlich funktioniert die Kommunkiation zwischen Pi und dem Wondom DSP Board.

Nun zu meinem Problem:
Nach ungefähr 15sek (Zeit nicht immer gleich) reibungsloser Soundausgabe fängt die Wiedergabe an zu haken. Pausiere ich und drücke dann wieder Play, startet dieses Spiel auch wieder von vorne.
Manche Lieder werden auch etwas schneller abgespielt was mich stark darauf tippen lässt, dass etwas mit der Sampleratenkonvertierung nicht passt.

Meine Testfiles waren bis jetzt 44.1kHz bei 24bit. Ich werde es mit 48kHz auch probieren.

Hallo Patrick,
also die Einstellungen am DSP scheinen zu stimmen, die Kommunikation zwischen RPi und DSP funktioniert auch.
Ich gehe davon aus, dass es sich um ein Problem der Clocks handelt. Wenn das nicht passt, sind die Devices nicht mehr synchron.
Die Thematik mit 44,1 kHz ist im Abschnitt zu Airplay beschrieben. Der DSP läuft auf 48 kHz Basis (12,288 MHz MCLK). Man muss entsprechend sicherstellen, dass beide Devices auf dem gleichen Clock laufen. Also entweder den RPi zu 48 kHz zwingen, was z.B. im Falle von Airplay nicht möglich ist oder den DSP auf 44,1 kHz-Basis umbauen (Quarz tauschen).

Paddy_B
Neuling

#34 erstellt: 06. Okt 2020, 20:20

Hallo Markus,

danke für die schnelle Antwort.

Okay, das ergibt sinn dass die Synchronität verloren geht.
Ich dachte nur mit den ALSA Einstellungen mache ich genau das dass ich den PI auf 48kHz zwinge. Audioausgabe läuft auch bei mir über ALSA.
Das Alsa-File habe ich wie beschrieben erstellt.
Kann da etwas schief gelaufen sein?

LG,
Patrick

rogle
Neuling

#35 erstellt: 08. Okt 2020, 18:09

Halo Patrick,

wäre denn denkbar, daß an ganz anderer Stelle etwas überläuft (bluetooth, v4l2 oder so)? Ist vielleicht der swap aufgebraucht? Für mich ist es überraschend, daß erst nach 15sek eine Reaktion auftritt...

Ich betreibe einen Raspberry Pi 1 mit deutlich weniger Modulen. Der kleine Rechner stottert leicht beim Abspielen von https-Seiten - http-Seiten werden klaglos genommen.

Viel Erfolg!

MK_Sounds
Stammgast

#36 erstellt: 08. Okt 2020, 19:08

Paddy_B (Beitrag #34) schrieb:

Ich dachte nur mit den ALSA Einstellungen mache ich genau das dass ich den PI auf 48kHz zwinge. Audioausgabe läuft auch bei mir über ALSA.
Das Alsa-File habe ich wie beschrieben erstellt.
Kann da etwas schief gelaufen sein?

Eigentlich müsste das die Ausgabe der Daten, die über ALSA laufen (also z.B. lokale Files), in jedem Fall passend resamplen. Bei z.B. Airplay ist das Problem, dass die Software direkt auf den Soundtreiber zugreift und keine Interpolation seitens ALSA zulässt.
Im Zweifel mal mit nativen 48 kHz Dateien testen.

Paddy_B
Neuling

#37 erstellt: 23. Okt 2020, 20:59

Hallo nochmals zusammen,

ich habe das Problem gelöst und will natürlich niemanden das vorbehalten der vielleicht das gleiche Problem hat

Also bei der Sample-Rate Konvertierung kommt es zu Problemen wenn man das bei Moode über die ALSA Konfiguration löst.
Ich habe hier eine Anleitung gefunden wie man einen Patch installiert wo man danach die Konvertierung über den MPD machen kann der läuft.
Das habe ich so getestet und funktioniert problemlos.

Hier der Link:

https://www.bitlab.nl/page_id=157

Hoffe ich konnte jemanden helfen.

Jetzt muss ich nur mehr testen wie ich 2 DSPs zeitgleich an der I2S Verbindung zum Laufen bringe

.

LG,
Patrick

steve6502
Neuling

#38 erstellt: 24. Okt 2021, 15:37

Hallo Markus, ich dachte ich schreib Dich mal hier im Forum an, weil ich mit einem Effekt den ich beobachte etwas ratlos bin.

Kurz etwas Kontext. Ich bin Haupt-Author einer Flipper Soundlösung, die zur Sounderzeugung einen Pi nutzt.

Die Soundausgabe geht typischerweise per i2s entweder auf einen DAC 5102 oder einen DSP 1702.

Für die DSP Ausgabe verwende ich deinen Treiber. Soweit so schön.

Optional habe ich in der ALSA Config den Software Equalizer davor aus libasound2-plugin-equal. Ich weiss für einen DSP ist das nur zum Teil sinnvoll weil man das ja auch mit dem SigmaStudio machen könnte. Allerdings wird es mit dem Einstellen dann schwieriger.

Jetzt beobachte ich folgenden sehr seltsamen Effekt und zwar nur auf Pi4:
Sobald der Software-EQ in der ALSA Ausgabe davor ist, gibt es Loops oder Echos immer ungefähr 1s oder so. Es wird nicht mehr sauber rausgestreamt.

Das gleiche tritt übrigens auch beim hifiberrydac overlay auf, das ich für den DAC5102 nutze. Wenn ich den Software-EQ weglasse, geht auch auf dem Pi4 alles ohne Probleme.

Wenn ich hinter dem Software-EQ das interne Audio-Device für den Klinken-Stecker nutze, funktioniert es auch. Nur bei der i2s Ausgabe zum DSP oder DAC gibts diese Loops.

Beim Pi3 funktioniert allerdings alles mit der identischen Konfiguration. Hast Du irgendeine Idee?

Der Software-EQ nimmt übrigens nur FLOAT_LE als Format (in/out), d.h. downstream ist immer ein "plugin"-device dazwischen für die Format-Konvertierung.

Viele Grüße in der Hoffnung auf eine Idee - Stefan

MK_Sounds
Stammgast

#39 erstellt: 25. Okt 2021, 12:54

Hallo Stefan,

solche Inkompatibilitäten zwischen den Raspberry Generationen 3 und 4 sind mir bei anderer Software auch schon aufgefallen. Teilweise wird je nach Hardware-Version eine andere Software-Version installiert, was natürlich Blödsinn ist.

Nachdem du das Problem auf den Software-EQ eingrenzen konntest:
Checke mal welche Version auf dem jeweiligen Gerät installiert ist. Evtl. lässt sich damit das Problem weiter eingrenzen.
Ansonsten würde ich mal testweise nach einer anderen DSP Software schauen. Da sollte es diverse zur Auswahl geben.
Mehr kann ich dir dazu leider auch nicht sagen, da einerseits das Problem in der jeweiligen Software liegt und ich konsequenterweise nicht mit dem Software-EQ des RPi arbeite, wenn ein Hardware-DSP angeschlossen ist

steve6502
Neuling

#40 erstellt: 25. Okt 2021, 13:11

Hallo Markus,

danke für Deine schnelle Antwort. Die Software Versionen sind absolut identisch. Ich tausche ja quasi nur den PI aus, verwende ansonsten aber das gleiche System / die gleiche SD Karte.

Was meinst Du denn mit "anderer DSP" Software? Einen anderen Treiber als Deinen?

Natürlich ist der Software-EQ eigentlich etwas fehl am Platz wenn man danach noch einen vollwertigen DSP zur Soundausgabe nutzt.

ABER: es gibt schon einen Unterschied. Den Software-EQ und auch andere Parameter, die ALSA per Software macht kann ich natürlich zur Laufzeit einstellen. Und meine Bedienoberfläche kann das natürlich auch. Beim DSP ist das schon schwieriger. Zwar kann ich Standard-Filter wie Butherworth oder Chebyshev auch zur Laufzeit im DSP neu parametrieren, aber eine komplettes EQ Element wie Sigma-Studio es ja auch anbietet klappt nicht.
Das liegt natürlich vor allem daran, dass Analog Devices die Filter nicht wirklich dokumentiert und die Gleichungen nicht public sind. Für die Standard-Filter ist das kein Problem, weil man die woanders herbekommt und dann auf den DSP und dessen Float-Format adaptieren kann. Aber bei komplexeren "Bausteinen" im DSP gelingt das eben nicht.

Das Problem schein ja auch nicht so wirklich spezifisch zum DSP zu sein, weil ich mit dem DAC5102 für welchen ich das hifiberry-dac Overlay verwende, die gleichen Probleme sehe. Beide verwenden die Soundausgabe per I2S.
Gruß Stefan

MK_Sounds
Stammgast

#41 erstellt: 25. Okt 2021, 13:41

steve6502 (Beitrag #40) schrieb:

Was meinst Du denn mit "anderer DSP" Software? Einen anderen Treiber als Deinen?

Den Ausgabetreiber hattest du durch deine Tests schon ausgeschlossen. Es geht um die installierte Software-DSP-Lösung. Da gibt es in der Linux-Welt diverse Möglichkeiten.

Das Problem schein ja auch nicht so wirklich spezifisch zum DSP zu sein, weil ich mit dem DAC5102 für welchen ich das hifiberry-dac Overlay verwende, die gleichen Probleme sehe. Beide verwenden die Soundausgabe per I2S.

Die Treiber für die reine I2S-Ausgabe sind alle recht rudimentär und unterscheiden sich wenig bis gar nicht. Die Unterschiede liegen in der Konfiguration per I2C die ggf. bei manchen DACs notwendig ist. Dieser Teil ist beim DSP nicht notwendig, da über SigmaStudio programmiert.

hpude
Neuling

#42 erstellt: 28. Okt 2021, 09:50

Hallo, habe in meinem letzten Projekt einen Gitarrenverstärker mit 3 Adau1701 aufgebaut. Kommunikation zwischen den Modulen ist I2S (kein Problem!). Über eine externe Soundkarte habe ich einen Raspi laufen. Auf dem Raspi läuft eine Looper applikation und ein Reverb unter pyAudio. Die I2s Anbindung würde hierfür besser passen, allerdings bräuchte ich den Treiber für Input und Output. Hatte mal versucht den vorhandenen Treiber nach Anleitung zu installieren, hat aber nicht funktioniert (wird nicht erkannt). Mit der Installation werde ich mich nochmal beschäftigen. Frage: läuft der Treiber bereits als In und Output? wenn nein, ist eine Erweiterung beabsichtigt? viele Grüße

hab jetzt nochmal das aktuelle OS aufgesetzt und per Putty (SSH) die Installation laut Anleitung durchgeführt.
auf "aplay -l" bekomme ich: "aplay: device_list:272: keine Soundkarten gefunden ..." . Was läuft schief?

[Beitrag von hpude am 28. Okt 2021, 13:26 bearbeitet]

MK_Sounds
Stammgast

#43 erstellt: 28. Okt 2021, 16:30

Habe das gerade nochmal kurz getestet, weil ich die Files für die generischen Treiber in der Anleitung eingebunden habe. Treiber war an sich immer schon generisch, jetzt werden aber alle Fälle abgedeckt (Master, Slave, I2S, TDM8).
Hatte das auch in der Anleitung angepasst.
Aplay liefert wie zu erwarten:

pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Slave [Generic I2S Output - Slave], device 0: bcm2835-i2s-dit-hifi dit-hifi-0 [bcm2835-i2s-dit-hifi dit-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

hpude (Beitrag #42) schrieb:

Die I2s Anbindung würde hierfür besser passen, allerdings bräuchte ich den Treiber für Input und Output.
(...) Frage: läuft der Treiber bereits als In und Output? wenn nein, ist eine Erweiterung beabsichtigt?

Der Treiber läuft momentan nur als Output. Die Source files (.dts) liegen im Github bei. Da könntest du dir mit dem simple card Modul zusätzlich einen Eingang bauen und dann kompilieren. Gibts auch zahlreiche Beispiele im Netz.

hugoone
Neuling

#44 erstellt: 09. Apr 2023, 10:14

Hallo,

läuft der Treiber auch auf dem piCorePlayer?

MK_Sounds
Stammgast

#45 erstellt: 11. Apr 2023, 20:32

hugoone (Beitrag #44) schrieb:

Hallo,
läuft der Treiber auch auf dem piCorePlayer?

Das ist ja ein standard Overlay/Treiber. Sollte also auf jeder Distribution laufen.

Bitte die Hinweise hier beachten:

Kompatibilität für neuere Kernel. Bin noch nicht dazu gekommen, die Änderungen einzupflegen.

tskemper
Neuling

#46 erstellt: 06. Mai 2023, 15:21

Hallo,

ich greife das Thema auch noch einmal auf:
ich habe bereits vor zwei Jahren die oben beschriebene Konfiguration mit dem ADAU1701 und dem Raspberry Pi aufgebaut und hatte in einem Beitrag weiter oben ja auch schon einen Verdrahtungsfehler aufgedeckt.
Nachdem ich das alles ans Laufen gekriegt hatte, lief das ganze System ganz gut. Nur mit den Leitungen zwischen ADAU1701 und RPi habe so meine Probleme: Ich habe zum einen den ADAU1701 und dessen Programmer auf einen Europlatine in ein 19"-Rack gebaut, der Raspberry Pi ist auf einer Platine unmittelbar daneben:

(ADAU1701 oben, RPi unten).
Leider klappte es mit einer Verdrahtung über den Bus an der Rückseite des Racks überhaupt nicht: die Leitungswege schienen zu lang.
Mit extra Leitungen (einzelne Drähte, ca. 8cm lang) direkt über den Platinen klappte es hingegen gut.

Nun habe ich das Projekt ein paar Monate an die Seite gestellt, weil anderes zu tun war.

Als ich vor einer Woche das Ding wieder eingeschaltet hatte, ließ sich erstmal kein Ton mehr aus dem Ding holen: Wenn ich auf dem Raspi eine Audiodatei abspiele, läuft das Stück 32 mal so schnell durch, wie normal, und aus dem Lautsprecher kam nur Datenmüll.
Seitdem versuche ich den Fehler zu finden: interessanterweise klappt es manchmal: es kommt vor, daß die Geschwindigkeit paßt und dann paßt auch das Audiosignal. Manchmal geht das von Anfang an beim Starten des Musikstücks auf Anhieb, manchmal geht es, wenn man eines der Clock-Signale kurz unterbricht.
Das ganze ist übrigens unabhängig vom Programm (omxplayer, mpg321, ...) oder von der Audio-Datei.
Ich habe irgendwo im Internet einen Vorschlag für eine Terminierung der Leitungen gefunden:

. Das ganze bringt leider auch nichts.
Auch habe ich gelesen, daß die Leitungen nur sehr kurz sein dürfen. Jetzt habe ich ein Flachbandkabel drin, wovon jede zweite Ader auf Masse liegt. Abgeschirmte Leitungen habe ich auch schon ohne Erfolg probiert.
Wenn ich die Leitungen oszillographiere, sieht meiner Meinung nach alles gut aus:

, allerdings habe ich irgendwie das Gefühl, daß der hochfrequente Takt auf die niederfrequentere Leitung überstrahlt und somit sich die Geschwindigkeit ver-32-facht.

Meine Frage: wie lang dürfen die Leitungen sein? Sind die 8cm schon zu viel? Reichen ganz normale, einfache Drähte? Ist das mit der Terminierung so sinnvoll? Wie klappt das bei Euch? Muß ich doch beides auf eine Platine bauen, damit die Leitungen noch kürzer werden?

Vielleicht weiß jemand weiter?

Beste Grüße,

Thomas