Brutefir + Hifiberry Digi +IO

Antworten
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Brutefir + Hifiberry Digi +IO

Beitrag von uli.brueggemann »

Ich verwende schon geraume Zeit das Digi +IO im Zusammenspiel mit Brutefir und dabei in der Konfiguration das Format S32_LE.
Nun kann man eine gefundene Lösung ewig betreiben im Sinne von "never touch a running system".
Ab und zu will ich aber dann doch schauen was denn so Neues passiert, es gibt ja immer neue Versionen. Die Linux-Community lebt.

Also habe ich mir das einmal mit dem aktuellen Raspbian bzw. PiCore11.0 angeschaut. Und wie es so kommt, das Format S32_LE läuft nicht. Invalid format!
Und so sind dann einige Stunden zusammengekommen um festzustellen was denn die Ursache ist. Es gibt zu Brutefir ja leider auch keine Community wo man einfach mal eine Frage losschiessen kann. Und Hifiberry hat gleich abgelehnt im Sinne von "wir sind es nicht!". Dabei habe ich nur gefragt ob sich vielleicht was am Treiber geändert hat. Früher war es hifiberry-digi.c, jetzt gibt es zusammenfassend für mehrere Hersteller rpi-wm8804-soundcard.c

Im nächsten Schritt habe ich mal nachgeschaut wo es denn bei Brutefir hapert. Nämlich bei der Funktion wo für die Hardware das Format S32_LE gesetzt wird. Das nimmt die Karte nicht an. Es folgt die Fehlermeldung mit Invalid format. Und ... S24_LE geht mit Brutefir auch nicht. S16_LE spielt dagegen.

Mmh, seltsam. Bei einem Test von aplay kann ich eine 24bit wav-Datei einwandfrei spielen.

Also habe ich mir selbst anhand von ALSA-Testprogrammen eine eigene kleine Testroutine gebastelt. Und hier klappte das mit derselben Format-Funktion, die auch Brutefir verwendet!
Aber eben nicht mit Brutefir.
Nach reichlich weiteren Tests und Überlegungen, die ich Euch nun doch ersparen will, war ich an einem Punkt, wo ich mit einer Testausgabe in meinem Testprogramm angezeigt bekam:

Code: Alles auswählen

FORMAT:  S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S20_LE S20_BE U20_LE U20_BE S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
Dieselbe Testausgabe, reingebaut ins Brutefir zeigte aber anderes mit:

Code: Alles auswählen

FORMAT:  S16_LE S24_LE
Im Testprogramm konnte ich also reichlich Formate setzen, nicht aber in Brutefir.

Obwohl: auch in Brutefir zeigt die Testausgabe an dass S24_LE geht. Nicht aber in der config-Datei.
Die weitere Inspektion ergibt dann: S24_LE in der config führt zum Brutefir-Format BF_SAMPLE_FORMAT_S24_LE, welches dann in bfio_alsa.c umgesetzt wird zu SND_PCM_FORMAT_S24_3LE.
S24_3LE kann die Soundkarte aber nicht. Also flugs den Quellcode geändert in SND_PCM_FORMAT_S24_LE. Und siehe da, die Ausgabe mit 24 bit unter Angabe von S24_LE in der config läuft. HEUREKA!!

Aber früher konnte ich doch S32_LE verwenden und nun nicht mehr. Frechweg eine weitere Quellcode-Änderung:
BF_SAMPLE_FORMAT_S32_LE wird nun ebenfalls umgesetzt in SND_PCM_FORMAT_S24_LE (anstelle des falschen SND_PCM_FORMAT_S32_LE).
Und schon läuft auch wie früher Brutefir mit der Digi +IO mit S32_LE in der config.

Es verbleibt noch die Frage wieso das Testprogramm viel mehr Formate anzeigt (s.o.). Da bin ich auch noch dahinter gekommen. Man muss ja das Device, also eigentlich die Soundkarte vorgeben. Und das kann man in mehrfachen Varianten tun. Ich habe dabei nun z.B. kennengelernt:
hw:sndrpihifiberry
hw:0 (indiziert, bei mehreren Soundkarten muss der Index passen)
default
plughw:0
dsnoop

Die beiden ersten Varianten zeigen das tatsächlich mögliche Format, also S16_LE und S24_LE.
Die anderen Varianten zeigen alle möglichen ALSA-Formate, jedoch nicht eben, was die Hardware kann.
Brutefir verwendet nun die ersten beiden Varianten, mein Testprogramm (abgekupfert aus ALSA-Testprogrammen) hat die anderen Varianten aufgerufen.

Mittlerweile weiss ich:
Mein Testprogramm hätte es nicht wirklich gebraucht. Dasselbe tut z.B. der Aufruf:

Code: Alles auswählen

arecord -D hw:sndrpihifiberry --dump-hw-params
arecord macht hier Sinn im Vergleich zu aplay weil Brutefir auch zuerst die Eingangskanäle initialisiert.
Eine gegebene Soundkarte zeigt hier also, was sie wirklich kann.
Und dann wählt man in Brutefir die config-Parameter, die dann die möglichen Parameter setzen. Ggf. muss man den Quellcode anpassen und neu übersetzen (was übrigens auch ein Abenteuer für sich sein kann. FFTW, Flex und Jack verhalten sich allesamt anders).

Was ich immer noch nicht weiss:
Wieso gibt es eigentlich die ganzen Varianten bezgl der Devices? Was bezwecken sie genau und warum unterscheiden sie sich?

Fazit:
wenn ich Langeweile habe dann befasse ich mich mit Linux. Ansonsten nur im Notfall. Wer sich diese shice ausgedacht hat ... :mrgreen:
Vielleicht hilft der Beitrag trotzdem dem einen oder anderen.

Viele Grüsse
Uli

PS: im Treiber der Digi +IO steht u.a.

Code: Alles auswählen

#define WM8804_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE | \
                        SNDRV_PCM_FMTBIT_S24_LE) 
Das Format S20_3LE gibt es zwar auch in ALSA, wird aber nicht als mögliches Format der Soundkarte ausgegeben. Und ist somit auch nicht wählbar. Obwohl der WM8804 auch 20 Bit kann.
Hölle, wer hat sich denn da wieder was zusammengemurkst...?
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo Uli

$ aplay -D blahblahdevice -s1 --dump-hw-params /dev/zero
oder
$ arecord -D blahblahdevice --dump-hw-params
gibt die spezifisch von Device blahblahdevice verarbeitbaren Formate aus. In Deinem Fall also wohl und in erster Linie S16_LE und S24_LE

Hingegen, und versuchsweise ohne die Device-Bezeichnung wie folgt eingegeben
$ aplay -s1 --dump-hw-params /dev/zero
oder
$ arecord --dump-hw-params
wird die unspezifische ALSA-Speisekarte aller möglicher Formate ausgegeben.

Ich habe nun den Eindruck, dass Deine leidige und ärgerliche ALSA-/Brutefir-/Hifiberry-/Update-/Formatodyssee damit zusammenhängen könnte, dass das seit Jahren nicht mehr gepflegte, mit umständlich-unwartbarem Code geschriebene, fehlerbehaftete Brutefir da wieder einmal (!) etwas ins Stolpern geraten ist, resp. ins Stolpern gebracht hat. Im geupdateten Setup. Deshalb würde ich es anders, umgekehrt ausdrücken: Vielleicht hast Du ganz einfach Schwein gehabt, dass Deine erste Konfiguration bislang so gut und stabil funktionierte. Und deshalb auch meine Mutmassung über die Ärgerquelle: Wenn was shyze ist, dann ist es wohl im Code von Brutefir zu verorten. Ich habe jedenfalls in meinen Linux-Setups brutefir herausgeschmissen, seit es seit einigen Monaten eine aktuelle und wesentlich bessere Alternative zu BruteFIR gibt: CamillaDSP.

CamillaDSP ist eine sehr neue Initiative des professionellen schwedischen SW-Programmierers Henrik Enquist. Das Programm ist in RUST geschrieben, ist bestens dokumentiert und steht nach wie vor in laufender Entwicklung. Es ist eine universelle, präzisie, elegante und aufgeräumte, einfach zu konfigurierende DSP-Engine, und macht alles, was man für das tägliche Audio so braucht (Convolution sowohl mit FIR, IIR, SRC mit der eigens geschriebenen Bibliothek RUBATO, stellt HP-LP Filter zur Verfügung, Splitting, Delay, Formatkonvertierungen, beherrscht Veränderungen der Konfiguration bei laufendem Betrieb ...). Der einzige Nachteil gegenüber entsprechendem, klassischem C-Code (wie z.B. das umfangreiche und hoch optimierte FFTW) ist der erhöhte Bedarf an CPU-Leistung um ca. 30%-80%. Dafür kommt es dank eines optionalen Web-Interface wahlweise mit einer schicken GUI daher. CamillaDSP, selbstverständlich durchwegs 64-bittig, läuft nach Wunsch puristisch direkt aufgesetzt auf ALSA (d.h. ohne Jack, Pulseaudio & Co.). Versteht jedoch auch Pulseaudio. Und ...

... als weiterer Clou, und für all jene, welche Linux nicht mögen: CamillaDSP läuft, u.a. auch dank den Portierungsmöglichkeiten von RUST, auch auf dem Mac und auf Windows, da es in der aktuellen Version auch Wasapi und CoreAudio direkt unterstützt. Camilladsp kann somit funktional nicht nur die Kombination von Brutefir, Sox und die die ganze soxr-Resampling-Funktionalität aus der Linux-Welt ersetzen, sondern wohl auch viele entsprechende Audio-Programme auf Mac- und Windows-Setups.

Last not least: Henrik Enquist ist nicht nur ein weithorizontig-aufgeschlossener Denker und Entwickler, akribischer Physiker und rasanter Programmierer, sondern ein durchaus freundlicher Mensch und sehr empfänglich für Feedback. Im englischen Forum diyaudio.com läuft denn aktuell ein entsprechender, relativ heisser Thread zum Thema - lesenswert ist er allemal:
https://www.diyaudio.com/forums/pc-base ... n-etc.html
Und die Goodies gibt es hier:
https://github.com/HEnquist

Brutefir? RIP! In diesem Sinne: Le Roi est mort - Vive le Roi ... Wie wäre es denn mit einem alternativen und weniger (zu Recht!) jammerigen Faden namens CamillaDSP + Hifiberry Digi +IO?

Brutefir-Totengräber-Grüsse
Simon
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Hallo Uli,

welche Version von brutefir lief denn vorher, und welche hast du jetzt selbst kompiliert? Es gab in älteren Versionen Fixes in diesem Bereich. Und konntest du nicht einfach in deiner config "S24_4LE" angeben? Das scheint das für deine Karte eigentlich richtige Format zu sein.

Zu deiner Frage nach den unterschiedlichen Devices: Die Devices unterscheiden sich im Verhalten. Das Device "hw:0" ist der direkte HW-Zugriff. Hier siehst du die Wahrheit deiner Karte. "hw:sndrpi..." und "default" sind angelegte Devices, die nur eine Art Pointer auf andere Devices sind -- offenbar zeigt "hw:sndrpi..." direkt auf "hw:0", "default" jedoch auf ein anderes Device (bei mir habe ich das z.B. auf den HDMI-Ausgang geroutet). "snoop" und "plug" sind quasi Adapter, die auf ein Device gesetzt werden können. Diese Adapter nehmen dann -- je nach Konfiguration -- verschiedene Formate (auch Samplingraten) an und passen die an das vom HW-Device geforderte Format ab. Wenn du dich dazu einlesen willst, solltest du nach "asound.conf" oder ".asoundrc" suchen.

Viele Grüße,
Andree
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Hallo Simon,

ich verwende Brutefir ja nun seit zig Jahren. Das hat mal angefangen mit meiner Version von Brutefir on a Memorystick auf Basis vom SPBLinux. Das waren Zeiten, wo ein Stick schon groß war, wenn er 64 MByte hatte. Schon damals habe ich Minimalstversionen schätzen gelernt. Ich habe noch mindestens einen Acourate-Anwender der noch heute! ein aktives System mit dem Memorystick fährt. Never touch a running system eben.

Für CamillaDSP muss man schon deutlich mehr Zeugs installieren. Ich werde mich da wohl auch einmal mit befassen. Am Ende wird man vermutlich auch wieder einiges herunterstrippen können. Man ist allerdings ziemlich abhängig, es sei denn man lernt eben eine weitere Fremd- ääh Programmiersprache.

Hallo Andree,

ich meine ich hatte zuvor Brutefir V1.0l im Einsatz.
Wenn man in bfio_alsa.c reinschaut kommt man natürlich auf die Idee es auch mit S24_4LE zu versuchen. Schliesslich wird es dort dann auf S24_LE umgesetzt, was die Soundkarte denn auch kann. Tatsächlich spielt die Soundkarte damit auch. Leider VERZERRT und damit unbrauchbar. Ich finde das Format auch seltsam. Es packt eben 3 Bytes in 4 Bytes. Allerdings ist nicht direkt ersichtlich in welche der vier (weisst Du? ;)). Und wenn dann für die Ausgabe wiederum 3 Bytes herausgenommen werden und dann die falschen ...

Plughw bzw. hw: das Problem ist, dass man sich Infos zusammensuchen muss. Bzw. dass man erst drauf kommen muss, dass man sich Infos zusammensuchen muss. Und dann gibt es einige Fundstellen mit unterschiedlichsten Antworten.

Viele Grüsse
Uli
Bild
Buschel
Aktiver Hörer
Beiträge: 989
Registriert: 12.12.2013, 20:12
Wohnort: Raum Karlsruhe

Beitrag von Buschel »

Moin Uli,
uli.brueggemann hat geschrieben: 15.09.2020, 09:46 Wenn man in bfio_alsa.c reinschaut kommt man natürlich auf die Idee es auch mit S24_4LE zu versuchen. Schliesslich wird es dort dann auf S24_LE umgesetzt, was die Soundkarte denn auch kann. Tatsächlich spielt die Soundkarte damit auch. Leider VERZERRT und damit unbrauchbar. Ich finde das Format auch seltsam. Es packt eben 3 Bytes in 4 Bytes. Allerdings ist nicht direkt ersichtlich in welche der vier (weisst Du? ;)). Und wenn dann für die Ausgabe wiederum 3 Bytes herausgenommen werden und dann die falschen ...
Das riecht verdächtig nach einem endianess Problem für diesen Fall (bei S32_LE geht es ja offenbar). Keine Ahnung, ob man den Fehler eventuell im Code erkennen kann. Warum hast du auch eine so komische Soundkarte. :)
uli.brueggemann hat geschrieben: 15.09.2020, 09:46 Plughw bzw. hw: das Problem ist, dass man sich Infos zusammensuchen muss. Bzw. dass man erst drauf kommen muss, dass man sich Infos zusammensuchen muss. Und dann gibt es einige Fundstellen mit unterschiedlichsten Antworten.
Stimmt, Linux eben. Aber man kann mit der asound.conf (oder wie auch immer die bei deinem System heißt) wirklich nette Dinge machen, wie z.B. Pipes definieren, die als alsa-Device angesprochen werden können. Oder es lassen sich feste Konfigurationen von Samplingrate, Format und Kanalanzahl vorgeben, die ein zuspielendes Programm einhalten muss. Dadurch lassen sich "ungewollte Schweinereien" wie SRC innerhalb alsa vermeiden.

Viele Grüße,
Andree

Btw, ich nutze brutefir nur noch innerhalb einer pipe mit float64 I/O. Die Ausgabe auf das alsa-Device macht dann sox oder playhrt. Eventuell ist eine Lösung über sox für dich ja auch robuster.
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Andree,

es läuft ja nun wieder wie es soll. Solange man nicht eine neue Konfiguration (Linux-Update, Boardwechsel etc.) macht.

Endianess ist es wohl nicht (also nicht die Byte-Anordnung vorwärts/rückwarts). Sondern eben 8 führende bzw. nachfolgende Nullen vor/hinter den 24 bits.

Feste Koniguration Samplerate: das Ziel ist ja, dass die Digi +IO einer beliebig anliegenden Abtastrate folgt. Und Brutefir das auch mitbekommt.
Was im übrigen bei digitalen Soundkarten (auch ASIO) ein absolutes Minenfeld ist.

Viele Grüsse
Uli
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

uli.brueggemann hat geschrieben: 15.09.2020, 11:40 das Ziel ist ja, dass die Digi +IO einer beliebig anliegenden Abtastrate folgt.
Hallo Uli,

genau das kann die nicht:
https://www.hifiberry.com/docs/hardware ... recording/
Bitte runterscrollen bis Digital Input.

Also muss die das Signal aufnehmende Software das auffangen.

Viele Grüße

Jochen
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Jochen,

nun, es geht schon. Aber das ist eben tricky (natürlich muss das ein Stück Software überwachen). Und abhängig von der Qualität der Quelle manchmal auch nicht zuverlässig.
Bei meinem Fireface als digitale Qualle klappt die Abtastratenerkennung aber problemlos.

Ist das nicht eigentlich frech:
There is no detection of the sample rate of the source
Wieso funktioniert das bei jedem dösigen DAC?

Grüsse
Uli
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Hallo Uli,

wenn ich es recht verstanden habe, ist die Karte kein Wandler, sondern stellt für den rpi nur einen digitalen Eingang bereit für den Fall, dass man nicht z.B. über USB gehen möchte.

Viele Grüße

Jochen
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Ein Standard-DA-Wandler mit digitalem spdif-Eingang bekommt ein Signal mit irgendeiner Abtastrate und gibt das dazu entsprechende analoge Signal aus. D.h. er erkennt die Abtastrate und passt sich daraufhin an.
Hierzu wird am Eingang denn ein entsprechender spdif-Receiver verwendet. Der macht letztlich I2S draus.

Ein spdif-Empfänger, nämlich der WM8804 (eigentlich ein Tranceiver) befindet sich auf der Digi +IO. Das Signal geht zur Verarbeitung nun nicht an einen Wandler-Chip sondern in den Raspi. Und plötzlich ist die Abtastratenerkennung ausser Kraft gesetzt? Obwohl auch hier nach I2S umgesetzt wird.
Weshalb soll nun der angeschlossene Rechner unfähig sein?

Grüsse
Uli
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Der Rechner ist ja nicht unfähig. Es muss halt eine Software laufen, die erkennt, welche Auflösung von der Digi-Karte angeliefert wird. Die ist offenbar so konzipiert, dass sich sich dafür nicht zuständig fühlt, sondern sagt: Rechner/Software: dein Job!

Ich könnte mir vorstellen, dass alsa entsprechend konfiguriert werden kann, kenne mich damit aber nicht aus.

Gruß

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

Beitrag von Daihedz »

Hallo in die Runde
uli.brueggemann hat geschrieben: 15.09.2020, 14:06 ... Bei meinem Fireface als digitale Qualle klappt die Abtastratenerkennung aber problemlos ...
Das kann ich mir gut vorstellen. Denn auch bei einer RME Multiface und bei einer RME HDSP 9632 wird die anstehende SPDIF-Rate in der Pseudodatei unter /proc/asound/card0/hdsp direkt angezeigt. Diese Info wird somit vom spezifischen ALSA-Treiber der RME bereitgestellt. Bei einer Hifiberry Digi +IO (Raspi II / Arch Linux) hingegen fehlt diese Info im gesamten Verzeichnisbaum unterhalb /proc/asound/*. Diese Info wird somit für die Hifiberry wohl nicht innerhalb ALSA abgelesen werden können: Der Treiber der Hifiberry scheint dies nicht zu leisten.

Es wäre deshalb sicherlich sehr hilfreich, wenn jemand hier konkret wüsste, und es auch aufzeigen könnte, wie diese Info auf anderem Weg und möglichst Hardware-nah verfügbar gemacht werden könnte. Falls dies überhaupt mit/bei der Hifiberry möglich ist.

Taktblinde Grüsse
Simon
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Daihedz hat geschrieben: 15.09.2020, 17:54 Es wäre deshalb sicherlich sehr hilfreich, wenn jemand hier konkret wüsste, und es auch aufzeigen könnte, wie diese Info auf anderem Weg und möglichst Hardware-nah verfügbar gemacht werden könnte. Falls dies überhaupt mit/bei der Hifiberry möglich ist.
Das Zauberwort heisst debugfs und dann genauer /sys/kernel/debig/regmap/1--003b/registers
Dort liegen die Registerdaten des WM8804 (siehe Datasheet).
Meines Wissens nach der einzige Weg. Zuständig dafür ist der Codec /sound/soc/codec/WM8804.c

Viele Grüsse
Uli
Bild
Antworten