Im Abschnitt limitations der LinkIt Doku hint es den Hinweis “mono (1 channel) is not supported” hmm, kann ich dann einfach Stereo aufnehmen und ein Kanal ist Müll? Oder ist das das Problem weshalb das Audio-Modul sich aufhängt?
Eine ausschließliche Stereoaufnahme wäre für uns erst mal doof, weil das automatisch die doppelte Datenmenge produzieren würde. Wir könnten aber ggf. beim Postprocessing noch nach Mono konvertieren.
Lass uns nochmal überlegen, ob das mit den USB-Mikros Sinn macht. Wir bräuchten dann zu den Micros auch USB-Soundkarten, oder? Ich würde gerne die selbe Hardware - bei den MIcs - für 24/7 und später im Feld verwenden. “Draußen” ist Stromverbrauch und die Größe der Dinger relevant. Denke da haben die I2S-Mics Vorteile.
Vielleicht finde ich auch noch etwas zum Stromverbrauch.
“Wenig Stromverbrauch” ist an dieser Stelle eine Optimierungsgröße. Und beim Prototypen gilt erstmal: “Premature optimization is the root of all evil”. USB ist und bleibt am universellsten über die gesamte Klasse der SoC Geräte hinweg.
Ganz normale USB Soundkarten mit ganz normalen Mikros, ja.
Falls unterschiedliche Micros einen signifikanten Einfluss auf die Daten haben könnte das eine Störgröße sein, besser wäre gleiche Mics für Phase 1 und Phase 2. Weiter werden wir für den Node im Feld eh keine USB-Soundkarte verwenden können weil der ESP oder ein anderer MC das nicht unterstützt.
Kann man den I2S nicht ähnlich wie einen Soundkarten-Eingang verwenden, auch mit gstreamer?
Zwei analoge Mics kann man an den da anschließen. - Auf dem break-out gibt es noch einen AUX audio in (der ist ohne elektret-biasing, also dynamische Mikros oder Line-In).
Ob das ein echter issue ist zw. wie die das genau meinen, kann ich noch nicht beurteilen, wäre aber unproblematisch; einen leeren Kanal zwar abzutasten, aber nicht aufzuzeichen oder zu übertragen, ginge immer.
Zu Deinem verwendeten (von Mediatek stammenden) Beispiel-Befehl:
dort fehlt arecord die device-Angabe. Das geht solange gut, wie ein default für den snd_core -Treiber des kernels definiert ist - wie im Falle des OpenWRT auf dem LinkIt 7688, nämlich der WM8960! Nur deshalb geht das Beispielt in deren wiki.
Normalerweise muß da sowas hin wie hw1:0 oder plughw:1, es liest sich auch besser. ;)
device tree -Schnipsel für das ICS43432
Invensense ICS-43432 MEMS microphone with I2S output.
There are no software configuration options for this device, indeed, the only host connection is the I2S interface. Apart from requirements on clock frequency (460 kHz to 3.379 MHz according to the data sheet) there must be 64 clock cycles in each stereo output frame; 24 of the 32 available bits contain audio data. A hardware pin determines if the device outputs data on the left or right channel of the I2S frame.
Du müßtest also 32bit aufzeichen, von denen 24 genutzt werden. I2S ist zwar big-endian, Dein PCM-Ziel will es aber anders, daher explizit (und nix shortcuts wie “cd” oder “dat”):
Aktuelles OpenWRT baut für das Teil, es gibt ein target und sub-target und sogar ein spezifisches target profile, - aber das weißt Du ja schon von @einsiedlerkrebs ! ,) Ich konnte sogar ganz ansehliche Stücke Python und gstreamer anmachen, und das image war gebaut gerade 13 MB.
Im aktuellen LEDE (die sind wieder zusammen: jetzt also wieder: OpenWRT) ist alles für I2S -support im kernel sowie einige Geräte, soweit bekannt und erschlossen, angelegt. Man findet mediatek’s github-feeds, die aus einem MT7688 einen LinkIt machen (inkl. dieser vorgeschalteten WebGUI vor OpenWRT) - die man aber nicht mehr braucht, denn der Wifi-Treiber ist inzwischen ein offener (MT76), die MT-GUI braucht man eh nicht! ;)
Es wird nichts drumherum führen, daß Du dieses Teil hier als kernel-Treiber für MIPS24KEc brauchst:
… und es muß im device tree eingeragen werden, daß dieses Mikrofon angeschlossen ist… und es muß der MT8960-Treiber rausgeschmissen werden… und es braucht zwingend einen 4.x kernel.
@einsiedlerkrebs oder ich könnten mal dieses file crosscompilen für den LinkIt, und dann muß noch ein passender device tree -Eintrag adaptiert werden. @clemens, fühlst Du Dich in der Lage, ein fertiges aktuelles Image von https://downloads.lede-project.org/releases/18.06.0-rc1/targets/ramips/mt76x8/ (gleich das erste oben) uber die LuCi (OpenWRT/LEDE-webgui) auf das Ding einzuspielen? Dann könnten wir weitersehen.
Wie ich im thread lese, kannst Du aber mit ctrl-C abbrechen, dann hat sich da nix aufgehangen. Der WM8960 ist bereits ein komplexer Stein mit aufwendigem Treiber (WM8960 audio codec - NXP Community), er benutzt daher ein I2C als control interface: genau dort hat nichts geantwortet, und arecord konnte den fehler an die alle Schichten darunter schieben.
… nee, @einsiedlerkrebs’ deployment ist einfacher, denn USB ist PnP, und einen USB-Treiber nachzuinstallieren, ist einfacher, als ein passendes i2s--kernel-Modul zu bauen, es einzubinden und neustart-fest zu machen. (Unabhängig davon streamt seine Lösung, das läßt sich kaum einacher machen, als so.) Den kernel + sinnvollen user space selbst zu bauen oder einen entsprechend existierenden zu modifizieren, wirst Du nicht umhinkommen. - @einsiedlerkrebs ist da dichter am Thema, denn im Gegensatz zu mir hat der solch ein MT7688!
Grundsätzliches zu diesem SoC (geht da um den Onion2 von omega.io, die verbauen den gleichen Chip auch):
I think we should precisely differentiate three areas:
There are bugs in the Mediatek MT7688, affecting SPI, I2S and I2C, see link in @György-Farkas’ post above. If you blame Onion for using this chip, then please name a better one in the same price range having at least partially open specs. The MT7688 is nothing more than a slightly IoT-zed router chip. Its ethernet, USB, UART and WiFi hardware is solid, but its SPI was originally designed to connect the flash chip only, and things like PWM and I2C seem to have been added without much care. Sad, but certainly MediaTek’s fault.
There’s not enough open documentation for the MT7688 to write solid drivers without a lot of try and error. As said, at least there is a publicly available datasheet (there was none for the Omega1’s AR9331!), but it is little more than a list of register addresses and bits. No conceptual descriptions of any of the function blocks, very little context. So the drivers that exist in the open source LEDE stack have shortcomings just because the hardware is not documented properly. On the other hand, those developers who do have more information, are bound by NDAs so can’t contribute to the open drivers, e.g. WiFi. This is the sad state of affairs around a only semi-open SoC chip.
Genau, das ist das Ziel eines solchen Kerneltreibers für den MT7688: Sobald der ordentlich läuft, muß das Audiogerät ebenfalls per ALSA (und PulseAudio) als hw (oder plughw) ansprechbar sein. Dann kann man alles damit anstellen, was man von anderen Audiogeräten unter Linux kennt.
Ich werde versuchen, heute Abend mit deinen Hinweisen weiter zu kommen. Beim Yun hatte ich das OS schon mal aktualisiert, so i’ll try my very best! … und reporte dann wie weit ich gekommen bin.
Schade, dass es nicht so geht wie gedacht. Hätte ich das schon mit “arecord -l” sehen müssen / können?
Vielen Dank für die Hilfe und Deine lange Antwort! ;-) Auch wenn “einfacher” besser wäre und der Weg steinig ist, lernt man mit deinen Antworten immer viel!
Die WLAN-LED ist nur ein GPIO, daher kann das ein normales Verhalten dieser LED unter diesem Treiber sein (den MT76 -wifi-Treiber benutze ich nicht mangels Notwendigkeit, sonst wüßte ich es genauer). Vorher war ja der proprietäre Treiber darin, und der wird ziemlich sicher anders geblinkt haben. - Also das allein ist noch kein Indiz.
Was sagt denn die console, schick’ doch mal den kompletten Mitschnitt des boot-Vorgangs von der seriellen Schnitte! Da meldet sich der bootloader, der das image reinzieht, entpackt und versucht, den Kernel anzustarten usw. Im besten Fall kommen irgendwann keine Protokollzeilen mehr, und Du kannst Enter drücken, um eine root shell zu erhalten. Wenn er vorher anhält, kann ich nur mit einem bootlog irgendwas dazu sagen.
Wie hast Du geupdated: über serielle, USB-Stick oder Ethernet? Hast Du das von der OpenWRT-Oberfläche aus gemacht oder aus der shell auf dem linkit mit sysupgrade? Du solltest auch immer die sha256 für das file mit der angegebenen verifizieren und neu downloaden, wenn es da eine Abweichung gibt!
BTW, Yun ist ne gute Idee, das ist der gleiche Target-core: ein mips24Kc (mips32r2-Code). Das bedeutet, daß Du für den Yun gebaute Pakete per ipkg komfortabel nachinstallieren kannst. - Ich nutze ja die Carambola2, das ist auch mips24kc. Der SoC ist ein anderer Hersteller (Atheros AR9331), aber wiederum der gleiche wie im Yun. Das heißt, ich habe dafür bereits die gebaute toolchain zum crosscompilen (und muß sie nicht erst bauen). Das beschert relativ schnell den ics43432-Treiber, - was aber noch nicht ausreicht…
Das update habe ich über die LuCI-Weboberfläche gemacht, wie unter Via Web-Oberfläche (weiter unten auf der Seite) beschrieben.
Der LinkIt war dabei im lokalen WLAN, die (bestehende) Konfiguration habe ich nicht übernommen (Option beim update). Dann habe ich damit gerechnet, dass der LinkIt in den AP-Mode wechselt und ein WLAN-Netzwerk mit “LinkIt irgendwas …” aufmacht. Ok, ist kein “original” LinkIt-Image, vielleicht macht er das gar nicht. Ich versuche mal über die Konsole ran zu kommen.
Um den boot-Prozess zu debuggen und auf den LinkIt – ohne WLAN – zuzugreifen muss man ihn über die serielle Schnittstelle ansprechen. Anleitung unter Bootloader and kernel console … hilfreich dabei auch das Pin-out Diagramm
Nun kann man mit PuTTY auf den LinkIt zugreifen. Wenn man nur am output interessiert ist kann man alternativ auch den seriellen Monitor der Arduino-IDE verwenden.
Et voila! Alive!
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.0-rc1, r7090-d2aa3a1b62
-----------------------------------------------------
D.h. die dauerangeschaltetet WLAN-LED, die mit der Original Linkit-Firmware einen Fehler signalisiert scheint – wie von @weef oben geschrieben – hier keinen Fehler zu signalisieren. ;-)
Nun spannt OpenWRT auch einen AccessPoint mit der SSID OpenWrt auf, mit dem kann man sich nun verbinden. Hat man die Verbindung hergestellt kommt man über http://192.168.1.1 auf LuCI.
Im Moment läuft hier auf dem MT7688 zwar ein gebautes openwrt-Image mit u.a. python 2.7 und gstreamer (ca. 21MB; ist letzten Do noch nach unserer session mit @Andreas entstanden), und das rennt auch, - aber es bröselt an einer der Hauptfunktionen: der freie MT76-Wifi-Treiber ist zwar schon toll, aber nur dessen AP mode funktioniert zuverlässig, sobald man aber zusätzlich einen STA mode braucht (als wifi client zum home-Netzwerk), wackelt das ganze im einstelligen Sekundenbereich, bis hin zu kernel warnings… 8(
Diese Probleme sind immerhin bzw. leider bekannt, und aufgrund des Alters des Systems und Desinteresse seitens Mediatek an der opsen source-Weiterentwicklung des Treibers auch nicht einfach so zu lösen. Maintainer für u.a mt76 ist nbd (Felix Fietkau); es ist davon auszugehen, daß schon alles in dem MT76-Treiber ist, was er ohne Doku ermöglichen konnte. Ich kann aber gerne auch den Stand und die Aussichten noch mal von ihm bestätigen lassen. Auch dieser Treiber kommt leider nicht ohne binary blob für die Wifi-Funktionalität aus.
Man könnte ja nun den AP abschalten, nachdem das Teil auf das home-Netz provisioniert ist, man hat nur kaum Zeit dazu, bevor das Teil auf beiden Interfaces wieder aus- und angeht. - Als nächstes kommt jetzt mal ein MagJack dran, damit ich ich stabiles Ethernet habe, sonst macht das Ding keinen Spaß.
Im Moment habe ich da ‘nur’ USB-Audio mit unserem bekannten kleinen Interface, den ICS43432-Treiber habe ich noch nicht kompiliert, was aber, wie beschrieben, kein Problem darstellt. Es muß in jedem Fall der device tree angepaßt für das Mikrofon werden - und dafür muß ich mir Zuarbeit anfragen…
Mediatek hat proprietäre Treiber für ein paar patchlevel vom 3.18.x kernel, damit muß man sich nicht mehr ohne Not beschäftigen müssen, oder man macht die nötigen backports alle selbst! ;)
Die Programme dieser Firmware linken noch gegen die uClibc während aktuellere OpenWrt Distributionen gegen die modernere musl libc Bibliothek linken. Beides sind kompakte Ausgaben der von einem “großen” Linux bekannten “glibc”, der glibc - Wikipedia.
Das sind also wirklich zwei Welten. Die OpenWrt Firmware von LinkIt lebt noch in der älteren, während wir beim Einsatz von OpenWrt eher auf die neuere setzen sollten.
Und nun?
Nach aktuellem Stand der Dinge schaue ich bereits in Richtung BeagleBone Green. Da hier auch Mainstream Distributionen wie Debian laufen, würden wir erstmal komplett ohne yak shaving auskommen - für den Start des Testbetriebs von Saraswati vielleicht nicht ganz unschlau.
Wenn das ohne zu großen Aufwand von abenteuerlustigen unter uns noch getestet werden könnte, wäre das vielleicht wirklich noch eine Chance. Grundsätzlich wäre der LinkIt für diesen Anwendungsfall schon ein tolles Stück Hardware. Oder vielleicht doch der Carambola 2, den Du ohnehin im Einsatz hast, @weef?
Mal ganz doof in die Runde gefragt, @weef du sagtest, man könne den ein oder anderen code-Schnipsel, der für den Yun gebaut wurde auch für den LinkIt verwenden? Da kommen wir aber nicht weiter, oder? Haben nicht den gleichen WLAN-chip?
