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

Quote from hyle

Wenn z.B. Breaking The Law im Hintergrund läuft, wippen die Beine und meine Hände wollen regelmäßig in die Luft...

Die Hände sind dabei aber hoffentlich schon zur Pommesgabel geformt

PS: Bei mir läuft gerade Helloween: Future World

Quote from hyle

...erwischte eine Linux-Live-CD und legte diese ein. Frag mich nicht warum, aber ab da war Ruhe und der Player hat garkeine CD mehr lesen wollen.

Da wirst Du halt ein Firmware-Update auf Deinem CD-Wechsler gefahren haben

Hardwareverbesserung: Die verbaute klassische Flachbandleitung durch eine flexiblere Folienleitung ersetzt

Die in Beitrag 11 beschriebene Flachbandleitung habe ich jetzt durch eine etwas filigranere und wesentlich dünnere Folienleitung ersetzt. Dafür habe ich das 15cm RPi-Flachbandkabel für das Kameramodul bestellt und mit einer scharfen Schere zwei vieradrige Streifen heruntergeschnitten. Diese beiden Teile wurden mit dem Lötkolben verlötet. Die Lötstelle befindet sich außen auf der Unterseite des Laufwerks (blauer Aufkleber). Gott sei Dank hat die Flachbandleitung eine einigermaßen passende Länge, so dass sich der Einbau ins CD-ROM-Laufwerk nicht übertrieben schwierig gestaltete.

Der Grund für den Umbau war, dass die ursprünglich verwendete Flachbandleitung dennoch einfach zu dick und zu starr war, so dass sich das Laufwerk nur ganz schlecht öffnete. Manchmal zwickt es auch jetzt, aber das liegt an der (vermutlich mittlerweile zu oft geöffneten) Mechanik des Laufwerks. Da kommt beim nächsten Öffnen WD40 oder weißes Sprühfett an die richtige Stelle in der Laufschiene des Schlittens. Hier sehe ich kein Riesenproblem...

Hier noch ein paar Bilder vom Umbau:

...und softwareseitig geht's jetzt mit der Umstellung des Players auf C weiter, aber dazu demnächst mehr...

schlizbäda

Bevor ich mich jetzt dazu herablasse, in den Tiefen von C zu versinken, habe ich nochmals versucht, den Player KsCD (siehe Beitrag #1) auf einem jungfräulichen Raspian Stretch zu installieren und zwar ohne die ALSA-Konfiguration für den MiniAmp: Und siehe da, bei unveränderter Audioausgabe über den HDMI-Anschluss funktioniert die Lautstärkeregelung von KsCD einwandfrei.

Ich hatte schon öfter den Eindruck, dass die auf der HifiBerry-Internetseite unter https://support.hifiberry.com/hc/en-us/articles/205377202-Adding-software-volume-control beschriebene ALSA-Implementierung nicht vernünftig bzw. unvollständig ist.

Ich habe ein paar andere Bugs(?) entdeckt, die ich teilweise allerdings auch auf meinem ubuntu-PC (16.04) festgestellt habe:

* Die eject-Schaltfläche funktioniert auf dem RPi nicht, am PC schon.

* Die Lautstärkeregelung über ALSA funktioniert am PC schon, am RPi nur bei der Standardaudioausgabe. Mit dem HifiBerry DAC+ in meinem yamuplay habe ich es jetzt nicht getestet.

* Viele Schaltflächen funktionieren nicht intuitiv. Die Titel springen manchmal (= Gesetzmäßigkeit noch nicht erkannt) nicht weiter. Das ist aber auch am PC so.

* Scheint auf dem RPi3 langsam zu sein (ist die auf Qt basierende GUI der Grund oder resultiert es aus den vielen Fehlermeldungen im Terminalfenster?)

Dennoch ist KsCD vermutlich ein gutes C-Gerüst, das unter Umständen mit wenigen Anpassungen auf Vordermann gebracht werden könnte. Leider habe ich mal wieder keine Ahnung, wie man auf dem RPi den Sourcecode auf die Schnelle kompiliert.

Das zweite fertige Programmpaket, das eventuell in Frage kommt, ist der AlsaPlayer. Aber auch da weiß der bekennende Linux-Dauernoob nicht, wie der übersetzt wird. Ich werde jedoch versuchen das herauszufinden...

Gut's Nächtle,

schlizbäda

Hi smutbert,

entschuldige bitte, dass ich erst jetzt antworte. Wie Du gehe auch ich davon aus, dass das Verhalten von KsCD an den ALSA-Einstellungen für den HifiBerry MiniAmp liegt.

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: sndrpihifiberry [snd_rpi_hifiberry_dac], Gerät 0: HifiBerry DAC HiFi pcm5102a-hifi-0 []
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0

pcm.hifiberryMiniAmp {
    type softvol
    slave.pcm "plughw:0"
    control.name "Master"
    control.card 0
}
pcm.!default {
    type       plug
    slave.pcm  "hifiberryMiniAmp"
}

#pcm.!default {
# type hw card 0
#}
#ctl.!default {
# type hw card 0
#}

Auf meiner YAMuPlay-Hardware: verwende ich einen HifiBerry DAC+. Dort scheint die ALSA-Konfiguration etwas ausgereifter zu sein, jedenfalls läuft die ALSA-Audioausgabe dort problemlos:

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], Gerät 0: HifiBerry DAC+ HiFi pcm512x-hifi-0 []
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

#pcm.!default {
#  type hw card 0
#}
##pcm.!default {
##  type plug
##  slave.pcm {
##    type bluealsa
##    device "98:E7:F5:3D:3D:2D"
##    profile "a2dp"
##  }
##}
#ctl.!default {
#  type hw card 0
#}

Weder auf dem RaspiBlaster noch auf dem YAMuPlay befinden sich im Homeverzeichnis von pi die in meinen Augen etwas obskuren Dateien

~/.asound.conf

~/.asoundrc

die mir bei der Einrichtung der ALSA-Anbindung für den MiniAmp auf dem RaspiBlaster immer wieder begegnet sind (Ich weiß schon, das sind lokale Dateien für den jeweiligen Linux-User, die bei Vorhandensein die Einstellungen der globalen /etc/asound.conf ersetzen, aber mich wundert, wieso die plötzlich da waren). Die ALSA-Konfiguration erforderte zudem immer wieder einen Reboot. Im Anhang ist eine Textdatei (dem Vorläufer meiner späteren Dokumentation), in der ich mir aufschrieb, wie ich bei der Installation vorging. Vielleicht hilft das irgendwie?

EDIT:

Prinzipiell muss der RaspiBlaster zunächst nur als CD-Spieler funktionieren. Als Erweiterung habe ich aber folgende Punkte im Hinterkopf:

* yamuplay aufspielen, um Mediadateien von USB-Sticks etc. abspielen zu können (das habe ich bereits getan).

Über den omxplayer -o alsa können Audio- und Videodateien ganz normal abgespielt werden und auch die Einstellung der Lautstärke über den ALSA-Regler läuft ptoblemlos. Das gleichzeitige Abspielen von Musik über yamuplay.py und raspiblaster.py, der auf dem mplayer basiert, ist nicht möglich, wie Du bereits leider richtig vermutet hast. Der erste reserviert sich die (Achtung: Windows-Slang) ALSA-Ressourcen.

* RFID-Funktionalität der Jukebox 4 Kids implementieren.
* Bluetooth-"Lautsprecher"

* DAB+-Radio

Vorab schon mal für Deine Hilfe!

Peter

PS:

Zum Vergleich habe ich die Ausgabe von meinem Samsung-Laptop NP350E7C hinzugefügt. Dort sind zwei ALSA-Audiogeräte definiert:

Die "echte" Soundkarte und der HDMI-Anschluss für einen zweiten Bildschirm. Ähnliches sieht man ja auch unter Windows 7 im Geräte-Manager (dessen Pendant in ubuntu ich nach wie vor nicht kenne).

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC269VC Analog [ALC269VC Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Statusbericht zur ALSA-Konfiguration

Servus smutbert,

1.aktuelle ALSA-Einstellungen einspielen

Auf einem ALSAmäßig jungfräulichen Raspbian Stretch, auf dem bisher keine /etc/asound.conf existiert hatte, habe ich diese Datei mit Deinem Inhalt aus Beitrag #29 angelegt. Nach einem Reboot erschien zunächst immer wieder die Datei /home/pi/.asoundrc mit den alten Inhalten:

pcm.!default {
 type hw card 0
}
ctl.!default {
 type hw card 0
}

Als Nebeneffekt ist die ALSA-Einstellung von X11 in der Taskleiste von Raspbian deaktiviert:

Das Lautsprechersymbol ist mit einem roten Kreuz als inaktiv gekennzeichnet und die Steuerelemente sind deaktiviert (ausgegraut). Sorry für die schlechte Bildqualität, ich hatte keinen Bock, ein Screenshot-Tool auf dem RPi zu installieren, deshalb habe ich das Bild einfach fotografiert und den Qualitätsverlust durch die Moiré-Muster in Kauf genommen

Erst die Aufrufe

speaker-test -c 2

alsamixer

führten dazu, dass nach einem neuen Reboot die X11-Alsaeinstellung funktioniert.

Mit der neuen ALSA-Konfiguration in /etc/asound.conf erfolgt eine parallele Audioausgabe, wenn KsCD und der omxplayer -o alsa (über yamuplay.py) gleichzeitig laufen.

2. Audioanbindung von KsCD (deshalb keine weitere Verwendung mehr beim RaspiBlaster geplant)

Ich hatte mir ja bereits den C++-Quellcode von KsCD heruntergeladen und entdeckte dort auch die Verwendung der Klasse phonon und das zickt (in Verbindung mit ALSA?) wirklich herum! Probehalber lief jetzt im RaspiBlaster eine CD unter KsCD, aber da regt mich neben phonon noch mehr auf:

* drexlangsamer Start von KsCD auf dem RPi (inklusive vieler Fehlermeldungen+Warnings im Terminalfenster) und funzt manchmal gar nicht. Wird wohl an der fehlenden KDE-Umgebung auf dem RPi liegen. Eine Installation weiterer KDE-Bibliotheken wird die RPi-Performance wohl nicht positiv beeinflussen...

* Über den X11-Lautstärkeregler kann zwar die Lautstärke vom omxplayer -o alsa gesteuert werden, nach wie vor nicht die von KsCD! Der plärrt in voller Lautstärke. Der eigene Regler von KsCD funktioniert aber. --> "Shice"

* Wenn das erste Lied zu Ende ist, fährt KsCD manchmal (d.h. Gesetzmäßigkeit nicht erkannt) nicht mit dem nächsten Lied fort. Ein Umschalten über die Schaltfläche "loop mode" (none, loop track, loop disk) bringt nichts --> unbrauchbar für Kinder (und Erwachsene)

Vielleicht habe ich noch etwas übersehen, aber die obigen Punkte reichen mir zum Abgewöhnen

3. Kriterien für ein vernünftiges Abspielprogramm

a) Einfache und kindgerechte Bedienung über eine klar strukturierte Oberfläche ähnlich der von KsCD (oder zur Not wie mein Python-Script aus Beitrag #13), die vollständig auf dem Original-Raspidisplay mit 800x480 Pixeln Platz findet.

b) Alle Funktionen (Play, Pause, Skip, Rewind, FastForward, nicht zwingend Eject) zum Abspielen von CDDAs müssen zur Verfügung stehen

c) Vernünftige Schwuppdizität, d.h. entsprechende RPi-Performance ohne ewiges Herwarten.

d) WICHTIG: Playlists dürfen zwar möglich sein, aber sie sollen nicht die primäre Bedienungsform darstellen! Leider bei vielen Linux-Playern der Fall und die CD-Wiedergabe (falls überhaupt vorhanden) verbirgt sich irgendwo tief in der Menüstruktur

e) ALSA-kompatible Einbindung ohne übergestülpten Schnickschnack (phonon, pulseaudio, ...) muss möglich sein

f) idealerweise ist eine Steuerung von außen möglich, so dass eine Steuerung über ein eigenes Programm/Script möglich ist. Dies ermöglicht eine Einbindung einer Python-GUI wie aus Beitrag #13 oder wichtiger für künftige Hardware-Steuerelemente an den GPIOs des RPi)

Bisher testete ich es mit folgender Software:

mplayer in Verbindung mit meiner Python-GUI

Erfüllt: a) c) d) e) f)

nicht erfüllt: b) Es fehlen Rewind+Ffwd. Der mplayer erkennt zudem nicht auf allen CDs die einzelnen Tracks

Python Audio Tools mit meiner Python-GUI

Siehe Beitrag #10

audacious (Qt Interface)

Erfüllt: b) c) e)

teilweise erfüllt: d)

nicht erfüllt: f) a) zu viele Steuerelemente, außerdem hat das Gimmick FFT-Balkenanzeige in der Qt-Variante einen Fehler (=Jammern auf höchstem Niveau!)

Beim "normalen" audacious ist die Minimalgröße des Hauptfensters größer als 800x480

KsCD

Erfüllt: a) d)

nicht erfüllt: b) prinzipiell schon, aber auf dem RPi (bzw. vermutlich, wenn kein KDE-System vorliegt) fehlerhaft. c) e)

unbekannt: f)

alsaplayer (Link zu ubuntuusers.de, Link zum Quellcode)

Das wird mein nächster Versuch, Details zu obigen Punkten weiß ich noch nicht

Fazit:

* An erster Stelle steht derzeit der Alsaplayer

* Audacious (Qt Interface) habe ich auch noch nicht aufgegeben. Vielleicht ist die Oberfläche relativ einfach umzustellen?

* Einen eigenen CD-Spieler mit C scheue ich richtig!

*** STRIKE! ***

So heute habe ich mich mal damit befasst, ein größeres Programm wie audacious auf dem RPi zu kompilieren und einzurichten:

* Download des Sourcecodes (libaudclient-3.5-rc2.tar.bz2, audacious-3.9.tar.bz2, audacious-plugins.tar.bz2)

* Programmpakete in der oben genannten Reihenfolge übersetzt und dabei alle fehlenden aber notwendigen Bibliotheken heruntergeladen (* selbstschulterklopf *)

* Die Bibliotheken ("shared libraries") mussen von /usr/local/lib nach /usr/lib kopiert werden, damit sie audacious findet

* Im Terminalfenster audacious eingegeben und die CD ( hyle: Disturbed - Ten Thousand Fists) im Raspiblaster angehört

* TODO:

Jetzt muss ich die GUI von audacious (Achtung: Unwort!) nur noch so umgestalten, dass sie ein Kind problemlos bedienen kann

und noch ein paar andere "Kleinigkeiten"

Obwohl ich mich an einigen Stellen sakrisch durchbeißen musste, hat es rückblickend auf den heutigen Tag ganz gut geklappt.

Leck mi am Årsch, bin i a Fuchs! Ned so g'scheid aba genau so dreckad.

Pfiad enk und guad Nåcht sågt da schlizbäda.

(Entschuldigt bitte, falls es aufgrund meines Eigenlobs sogar durch's Internet durchstinken sollte)

...und da kommt auch schon wieder die Ernüchterung:

nach erfolgerichem Kompiliervorgang von audacious auf dem RPi und dem PC (Linux Mint), sah ich mir mal den Quelltext an und erschrak!

Wo wird die GUI aufgabaut? Ja, irgendwo in main() stehen die Aufrufe drin, die verbergen sich sourcecodemäßig in anderen Quellcodedateien, aber in welchen?

Also muss (für faule Hunde wie mich) ein Debugger her, um den Programmaufbau mal prinzipiell zu erkunden.

Ich habe mir auf die Schnelle die IDE eclipse heruntergeladen, aber bei anklicken von "Compile", "Make" oder "Build" kommt es zu Fehlern. Klar, da ist ja noch nichts eingestellt.

An die C-Freaks:

Habt Ihr da kleine Hinweise für mich, wie ich das idealerweise anpacke?

Wichtig ist ein Debugger, der einfach funktioniert und das Ganze idealerweise visuell im Code anzeigt. Eine IDE brauche ich gar nicht unbedingt.

Quote from smutbert

aber wäre es da nicht ungleich einfacher einen Player zu nehmen, um den du nur eine GUI drumherum basteln musst.

prinzipiell richtig, das war auch mein erster Versuch.

Aber auf dem RPi muss die EJECT-Taste gesperrt werden, wenn eine CD läuft (siehe Beiträge ganz am Anfang und insbesondere ab Beitrag #11). Dies will/muss ich hardwaremäßig umsetzen, d.h. über ein Relais wird der Stromkreis des EJECT-Tasters des Laufwerks unterbrochen, um seine Betätigung zu verhindern. Die Relaisansteuerung erfolgt über einen GPIO des RPi. Dazu muss sowieso der Sourcecode egal welchen Players irgendwie geändert/angepasst werden. Ein solches Feature bietet vermutlich kein Player remote über dbus, Pipe-Mechanismus etc.

Ach ja, auch in eclipse konnte ich mittlerweile meinen derzeitigen Lieblingsplayer audacious auf dem PC erfolgreich kompilieren

Da der Bua keinen Spaß versteht, wenn ich mir abends zu seiner Bettgehzeit seinen Raspiblaster "ausleihe", muss ich die Änderungen an audacious mangels zweitem USB-CD-ROM ohnehin an meinem Laptop machen. Am Schluss werde ich die Sourcecodes auf den RPi kopieren und dort das Projekt einfach nochmals kompilieren und dann ausgiebig testen. Aber dafür muss ich mich erst noch in den eclipse-Debugger einarbeiten, um mich durch den Programmaufbau von audacious durchzuhangeln...

Wäre ja gelacht, wenn bei diesem Projekt mal irgendetwas wirklich einfach wäre Es weist für mich eine extrem steile Lernkurve auf. Größere C- bzw. C++-Projekte hätte ich sonst nicht so schnell angefasst!

Quote from smutbert

Also meine erste Idee wäre gewesen, den Auswurftaster des Laufwerks komplett lahmzulegen (eventuell auch einfach nur zu verdecken) und die CD per Software auswerfen zu lassen (zum Beispiel ausgelöst von einem eigenen Taster per gpio, der dann vorher auch Stopp betätigen kann).

Genau so habe ich es in meinem Python3-Script aus Beitrag #13 umgesetzt. Bei Betätigung der tkinter-Schaltfläche "eject" führt das Python-Script erst "stop" aus und danach "eject".

Quote from smutbert

Selbst wenn du bei deinem Plan mit dem Relais bleibst, hätte ich zumindest bei mpd eine vage Idee wie du es ohne Anpassung von mpd erledigen kannst (ein zusätzliches Programm muss dann natürlich laufen, aber das muss es bei mpd und allen anderen Playern, die in Client/Frontend und Server/Backend aufgeteilt sind, sowieso).

Hardwaremäßig wurde das Relais bereits eingebaut und das CD-Laufwerk entsprechend umgebaut, siehe Beiträge #11 und #25. Prinzipiell steht es frei, das Relais über ein externes Programm oder über die Anwendung selbst (audacious) zu schalten. Der Charme bei Integration dieses Features in den Player selbst liegt darin, dass das Relais den Hardwaretaster nur deaktiviert, wenn wirklich eine CD abgespielt wird und nicht dauerhaft, solange die Playersoftware läuft. Ist aber vielleicht noch abzuwägen, ob es den Aufwand lohnt...

Bei übergestülpten GUIs in Eigenentwicklung (z.B. für mpd) kann dort natürlich die Relaissteuerung entsprechend eingebaut werden. Das wäre ein Revival meiner Python-GUI aus Beitrag #13

MPD/MPC:

Dieser Player ist gut, da er sehr modular aufgebaut ist und auf Client/Server(Daemon) basiert. Daher eignet er sich für eine Einbindung in eigene Projekte. Anfangs schreckte mich die zugrunde liegende "Datenbank" (Playlist) bei mpd/mpc ab, aber damit kann man sich ja arrangieren. Allerdings weiß ich nicht, ob er auch für das Abspielen von echten CDDAs geeignet ist.

Da werde ich nochmals recherchieren... Für Deine Hinweise diesbezüglich bin ich jederzeit dankbar!