RaspiBlaster: CD-Player mit dem RPi oder wie binde ich "libasound2" in "Python Audio Tools" ein?

  • Mei dass då nix oafach is!


    Derzeit manipuliere ich den C++-Code von audacious so, dass die neue Funktion "eject" als Toolbar-Button und als Menüpunkt (Wiedergabe-->Eject) zur Verfügung steht (erfolgreich ergänzt)

    und

    die in den Beiträgen #11 und #25 umgebaute Auswurftaste des CDROM-Laufwerks über GPIO4 gesperrt wird. Dies ist beinahe erfolgreich umgesetzt: Die Sperre an sich funktioniert.


    Aber jetzt erstmal wieder ein bissl mimimi: :mad_GREEN:

    Neben der Tatsache, dass mich die nicht nur bei mir, sondern selbst bei Experten gefürchtete C-/C++-typische #include/Makefile-Geschichte immer wieder ausbremst, habe ich es jetzt tatsächlich geschafft, das audacious-Projekt auf dem RPi zu kompilieren und dabei die pigpio-Bibliothek -lpigpiod_if2 über die Datei buildsys.mk in das Projekt mit einzubinden. Das ist die Version von pigpio, die den GPIO-Zugriff über den pigpio-Daemon durchführt. Damit braucht das Clientprogramm (audacious) keine Rootrechte.

    Aber was passiert jetzt als neues Schmankerl?

    Nach Absetzen von sudo pigpiod läuft die Audioausgabe gar nicht oder nur mit ca. 50% der Originalgeschwindigkeit. :baeh2:

    Ein geschmeidiger sudo killall pigpiod führt sofort dazu, dass nach dem Kill die Audiogeschwindigkeit beim laufenden Musikstück (Nightwish: "Dead Gardens") sofort wieder auf 100% ansteigt.

    Ich vermute, dass pigpio den I²S-Bus irgendwie ausbremst...


    Bisher kenne ich mich mit den GPIOs überhaupt nicht gescheit aus, aber folgende Lösungsvorschläge geistern in meinem Kopf herum:

    - Die "normale" pigpio-Variante -lpigpio ohne Daemon bremst die Audioausgabe ebenfalls aus!

    - Kann der pigpiod auf eine Teilmenge der GPIOs (hier GPIO4) eingeschränkt werden?

    - hilft es, ein kleines C-Programm zu erstellen, das den GPIO4 ansteuert und mit system(<Pfad>/<Programmdatei>) aus audacious heraus aufgerufen wird?

    - wäre eine andere Lib (wiringPi, bcm2835) evtl. besser geeignet?


    Es ist zum ko... -- äh Mäuse melken!

    schlizbäda


    Edith meint dazu:

    Ich habe pigpio durch wiringPi ersetzt. Um genau zu sein, verwende ich das in wiringPi enthaltene Kommandzeilenprogramm gpio zum Ändern von GPIO4. Erstens war das am schnellsten in den audacious-Quellcode eingebunden (nur der simple Aufruf der Funktion system("gpio ...") aus der <stdlib>) und zweitens (der wichtigere Grund) braucht audacious dazu keine Rootrechte. Und damit schalte ich GPIO4 problemlos, ohne die I²S-Kommunikation zu beeinträchtigen!

    Den von mir geänderten audacious-Code (stable version 3.9) habe ich schon mal vorab als Github-Repository veröffentlicht. Jetzt bin ich gerade dran, noch eine LaTeX-Doku dafür zu verfassen, auf deutsch und auf englisch...

  • Yeah!


    Endlich habe ich den Durchbruch geschafft und der Raspiblaster ist einigermaßen so, wie ich mir das vorstelle. Zumindest reicht es, den Erledigt-Haken zu setzen. Ich verwende jetzt doch audacious in der aktuellen stable-Release 3.9 vom 19.08.2017 mit Ergänzung der eject-Funktion einschließlich der notwendigen eject-Sperre über GPIO4 (wiringPi: shell-Kommando gpio). Hier ein Screenshot vom RPi-Desktop mit der von mir angepassten audacious-Variante:

     

     


    Der von mir angepassten Quellcode von audacious befindet sich im github-Repository .../schlizbaeda/audacious-raspiblaster zum Download. Außerdem habe ich mit LaTeX eine pdf-Bedienungsanleitung/Dokumentation für den Raspiblaster verfasst, in der u.a. in Kapitel 3 beschrieben ist, wie der angepasste audacious-Quellcode auf dem RPi zu kompilieren ist. Die Bedienungsanleitung befindet sich im github-Repository .../schlizbaeda/raspiblaster-manual. Derzeit liegt nur eine deutschsprachige Version vor, ich will sie aber auch noch auf englisch übersetzen - versprochen! git gibt ja eine derartige Variantenvielfalt in einem Repository mittels mehrerer Branches her :) EDIT 22.05.2018: Die Dokumentation liegt mittlerweile in englischer und deutscher Sprache vor.

    Wer Bock hat, kann sich ja mal die Doku anschauen. Und dann mit Kritik und Verbesserungsvorschlägen nicht hinter dem Berg halten. Immer her damit!


    PS:

    Übrigens ist das Beitrag #42 in diesem Thread. Die Antwort auf alle Fragen! ;)

    schlizbäda

  • :thumbup:

    eject-Funktion


    Sorry für die (vielleicht blöde) Idee, die Dir dann doch sooo viele Sorgen bereitet hat! :denker:


    BTW: Ich bin nach wie vor begeistert von Deinem Ehrgeiz das Projekt erfolgreich abzuschließen!

    "Alles, was wir sind, ist Sand im Wind, Hoschi."

  • Sorry für die (vielleicht blöde) Idee, die Dir dann doch sooo viele Sorgen bereitet hat! :denker:

    Nein, das war überhaupt keine blöde Idee. So eine halbseidene Funktionsweise ohne Korrekturmaßnahmen hätte mich richtig gestört. Erst jetzt ist das Ganze nämlich einigermaßen so, wie ich es mir anfangs vorgestellt habe.


    Weiterhin offen ist die Sache mit der S-USV pi advanced mobile (siehe Beitrag #1)

    Es wäre schön gewesen, damit einen Batteriebetrieb samt sauberem/kindgerechtem Herunterfahren beim Ausschalten zu realisieren. Aber ich glaube, ich habe die mobile-Variante der S-USV zu früh bestellt, da enthielt deren proprietäre Soft-/Firmware wohl noch einige Fehler...


    Das Beste ist aber folgendes:

    Neben der Tatsache, dass die eject-Taste des verwendeten Laufwerks LG GP50NW40 Probleme bereitete, ist es auch in der Einlesephase der CD relativ langsam. Dieses Geschwindigkeitsproblem führte ich zunächst auf den verwendeten RPi3B (ohne Plus) zurück. Letztens war ich mit dem kleineren Buben (5 Jahre) wegen eines neuen Ethernet-Switches in der Stadt in den einschlägigen Elektronikgroßmärkten. Als wir in der PC-Abteilung bei den CD-ROM-Laufwerken vorbeikamen, sagte er, er wolle auch so einen CD-Spieler wie sein größerer Bruder. Dann nahm ich ein CD-ROM-Laufwerk für ein Desktop-/Tower-PC-Gehäuse (eigentlich ein Blu-ray Disc Rewriter LG BH16NS55) zum Preis von 25,00€ mit, u.a. weil dessen eject-Taste nicht am beweglichen Teil verbaut ist.

    Außerdem erwarb ich gleich einen (wohl überteuerten) USB2.0-S-ATA-Wandler (Vivanco 31952) für über 30,00€.

    Zu Hause schloss ich dieses Gespiel zum Test an einem herumliegenden RPi1 an, auf dem auch meine audacious-Software läuft (gleiches SD-Image wie am Raspiblaster), um die Screenshots für meine Doku zu erstellen.

    Resultat:

    Das Einlesen der CD an diesem Gerät geht (trotz RPi1?) gefühlt dreimal so schnell, jedenfalls mehr als schnell genug. Beim Betätigen der eject-Taste kommt die gleiche harmlose Fehlermeldung von audacious wie am (richtigen) PC ohne Hängen. Das eject-Problem ist wohl eine Treibergeschichte des ursprünglichen Laufwerks, wie ich bereits in Beitrag #2, Unterpunkt 1 offenbar leider richtig vermutet habe. Frei nach Loddar Matthäus: "Again what learned"


    schlizbäda

  • apt-get vs. apt


    Dieses Projekt bleibt sich treu und liefert ein neues Schmankerl für den Linux-Dauernoob:

    Kennt jemand den Unterschied zwischen apt-get und (dem neueren) apt? Oder was hat es damit schon wieder auf sich?


    Bei Durchführung meines Tutorials aus Kapitel 3 in meiner Doku unter dem aktuellen Stretch vom 13.03.2018 schlägt nach Ausführung von

    sudo apt-get update

    sudo apt-get upgrade

    das Kommando

    sudo apt-get install eject

    und auch etliche andere sudo apt-get install ... fehl.


    Erst ein

    sudo apt update 

    führt dazu, dass die Pakete bei Aufruf von

    sudo apt install ...

    wirklich installiert werden!


    Ach, dann werde ich Kapitel 3 nochmals umschreiben müssen! Gut, dass ich die Doku noch nicht auf englisch übersetzt habe, Faulheit zahlt sich eben immer wieder aus!


    schlizbäda

  • Die letzten Tage / Wochen gab es öfter Probleme bei der Installation verschiedenster Software, die sich nach wiederholtem sudo apt-get update in Luft auflösten. Vermutlich werkelt man im Moment verstärkt an den Paketlisten herum. :conf:

    "Alles, was wir sind, ist Sand im Wind, Hoschi."

  • ...und ich dachte, die (mir durchaus geläufige) Sache mit den Raspbian-Paketen wäre mittlerweile durch?

    Komisch ist, dass es mit apt-get nicht funktioniert und mit apt schon.

    Oder es liegt daran, dass beim zweiten Aufruf sudo apt/apt_get update die Metadaten nochmals erneut aktualisiert werden, oder, oder, oder... :?:


    Auch bei Linux ist nicht alles superduper!

  • apt wurde vor allem eingeführt um Alltagsaufgaben mit einem einheitlichen und übersichtlichen Kommando durchführen zu können (statt apt-get, apt-cache,...) und macht bei den gleichen Befehlen dasselbe wie apt-get.


    Mit den Informationen, die du gepostet hast, lässt sich nur mutmaßen, dass der ersten Versuch die Paketlisten mit apt-get upzudaten fehlgeschlagen ist, vielleicht wegen (vorübergehenden) Problemen mit der Netzwerkverbindung oder weil in den Repositories gerade gearbeitet wurde und das gewünschte Paket in den Paketlisten beim folgenden apt-get install … gefehlt hat oder der Eintrag nicht (mehr) gestimmt hat.

    (Auf jeden Fall halte ich die Probleme für einen unglücklichen Zufall.)


    Man kann apt und apt-get auch beliebig kombinieren oder je nach Lust und Laune abwechselnd nutzen. So etwas wie

    Code
    1. # apt-get update && apt install eject

    oder

    Code
    1. # apt update && apt-get upgrade

    soll und darf überhaupt kein Problem sein.


    aptitude ist ein bisschen etwas anderes, weil es soweit ich weiß seine eigenen von apt abweichenden Methoden hat Abhängigkeiten aufzulösen, aber solange man keine außergewöhnlichen Dinge mit der Paketverwaltung stellt, spielt das auch keine große Rolle und man kann dann auch aptitude weitgehend problemlos mit apt/apt-get kombinieren.

  • Hähä,


    ich habe zum Test nochmals das aktuelle Raspbian Stretch with Desktop geflasht und die apt-Gaudi nochmals getestet. Mit dem Image vom 13.03.2018 ist es tatsächlich so, dass man zunächst folgende Befehle in dieser Reihenfolge absetzen muss:

    Code
    1. sudo apt update # egal ob apt oder apt-get
    2. sudo apt upgrade
    3. uname -a # liefert: Linux raspiblaster 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l GNU/Linux
    4. sudo apt update # hier das Update der Paket-Metadaten NOCHMALS aufrufen!

    Meine Vermutung ist, dass nach dem Flashen des Images zunächst die Metadaten dem Stand vom 13.03.2018 entsprechen. Dann führt man mit diesen aktualisierten Metadaten den Upgrade durch und erhält einen Distributionsstand vom 26.03.2018 und bei dem ist es offenbar erneut erforderlich, die Paket-Metadaten zu aktualisieren. Ein weiteres sudo apt upgrade oder auch sudo apt dist-upgrade liefert die Meldung, dass alle installierten Pakete aktuell sind.

    Aber das ist jetzt eine reine Vermutung eines echten Linux-Noobs.


    apt ist cooler als apt-get, denn die Ausgabe ist farbig und es wird ein geschmeidiger Fortschrittsbalken angezeigt :cool: