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

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
    • Offizieller Beitrag

    beim Programmieren ist zu große Lautstärke und/oder zu viel Baß bisweilen nervig

    Ich kann mich bei richtiger, auch leiser Musik nicht richtig konzentrieren. Wenn z.B. Breaking The Law im Hintergrund läuft, wippen die Beine und meine Hände wollen regelmäßig in die Luft... So kann ich nicht arbeiten. ;)

    Mitte/Ende der 90er brauchte ich einen neuen CD-Player und entschied mich für einen 5-fach Wechsler mit CD-Text von Sony für 550 DM. Ca. zwei Jahre später, natürlich kurz nach Ablauf der Garantie vergriff ich mich bei Kerzenschein bei der CD-Hülle, erwischte eine Linux-Live-CD und legte diese ein. :wallbash: Frag mich nicht warum, aber ab da war Ruhe und der Player hat garkeine CD mehr lesen wollen. :X Seit dem kaufe ich bei Bedarf nur noch ganz einfache CD- mittlerweile DVD-Player.

    BTW: Ich bin echt gespannt welche Möglichkeiten Du noch für das Raspiblaster-Projekt findest. Übrigens: YAMuPlay sieht auf den ersten Blick gut aus, muss ich mir mal in Ruhe ansehen.

  • RaspiBlaster: CD-Player mit dem RPi oder wie binde ich "libasound2" in "Python Audio Tools" ein?? Schau mal ob du hier fündig wirst!

  • 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 :D

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

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

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

  • Ich denke eine Installation dürfte auch am RPi funktionieren, wenn man alle notwendigen Pakete/Metadaten für dpkg lädt/aktualisiert

    Mhh, pip ist da leider nicht allzu gesprächig, was jetzt genau nicht stimmt. Aber schau mal hier: https://pypi.org/project/PyQt5/#files

    Vielleicht bekommst du ja das Wheel file manuell installiert, speziell das: https://files.pythonhosted.org/packages/3a/c6…nux1_x86_64.whl

    Alternativ: https://raspberrypi.stackexchange.com/a/63058/53826

  • 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:

    Beschreibung der Bilder


    IMG 6350:

    Die Flachbandleitung wurde durch eine Folienleitung ersetzt. An der Stelle wo sich der blaue Folienaufkleber der Flachbandleitung befindet, wurden die beiden Teile zusammengelötet.

    IMG 6352:

    Anschluss der neuen Folienleitung an der Elektronik des Laufwerks. Ich habe gelernt, dass das bewegliche Teilstück, das hier endet, genau in Bewegungsrichtung laufen muss, damit es beim Zuschieben nicht schräg läuft und verkantet!

    IMG 6353 + IMG 6355:

    Verlegung der Folienleitung: Hier sieht man die Schlaufe des beweglichen Teils. Der feste Teil muss anfangs ebenfalls gerade laufen und später beim Einbau fixiert werden.

    IMG 6357:

    Bei geschlossenem Laufwerk darf die Schlaufe nicht über die Gesamtmaße des Laufwerkgehäuses überstehen. Hier ist es schon sehr grenzwertig. Siehe Schlaufenrest in der Nähe des USB-Anschlusses in der linken unteren Ecke. Ich traute ich mir allerdings das Kürzen des beweglichen Teilstückes nicht zu...

    IMG 6358:

    Gesamtverlegung der Folienleitung: Das fixierte Teilstück kann dann im Winkel so geknickt werden, dass die Länge letztlich genau passt. Es ist nicht wirklich rechtwinklig, das sieht auf dem Bild nur so aus...

    IMG 6363:

    Am Ende habe ich vorsorglich die von mir zuvor schon sehr grob bearbeitete Leiterplatte mit dem USB-Anschluss mit einem Klebeband (rot) nochmals umhüllt, damit hier keine Kanten die Flachbandleitung aufscheuern.

    IMG6367:

    Fixierte Folienleitung im eingebauten Zustand des Laufwerks (da brauchst eigentlich drei Hände)

    ...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 http://support.hifiberry.com/hc/en-us/artic…-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

  • Also wenn es darum geht die Softwarelautstärkeregelung zum Funktionieren zu bringen willst, bekommen wir das hin.

    Bei der verlinkten Anleitung ist das Problem vermutlich, dass auf "plughw:0" verwiesen wird, also auf die in der Alsa-Nummerierung erste Soundkarte. Die Nummerierung ist aber nicht vorhersagbar und kann sich im Grunde von Systemstart zu Systemstart ändern. (Es gibt zwar einige Maßnahmen, dass die Nummerierung doch etwas vorhersagbarer wird, aber wie man sieht funktioniert das nicht immer.)

    Besser wäre es also die Namen zu verwenden.

    Es wäre nur ganz interessant zu wissen ob du auch mit mehreren Anwendungen gleichzeitig Audio wiedergeben willst (dafür fehlt bei der verlinkten Anleitung noch etwas) und für die Namen der Soundkarten die Ausgabe von

    Code
    $ aplay -l
  • 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.

    RaspiBlaster: Kommando "aplay -l" und Datei "/etc/asound.conf"

    Die Ausgabe von aplay -l lautet:

    Code
    **** 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

    Die Datei /etc/asound.conf hat folgenden Inhalt:

    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:

    YAMuPlay: Kommando "aplay -l" und Datei "/etc/asound.conf"

    Kommando aplay -l :

    Code
    **** 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

    Datei /etc/asound.conf :

    in der Datei /etc/asound.conf steht praktisch gar nichts drin, weil alles auskommentiert ist. Das waren Versuche zu meinem Miniprojekt RPi als Bluetooth-Lautsprecher verwenden, das derzeit mangels Brisanz auf Eis liegt... Wird erst wieder interessant, wenn die CD-Funktionalität des RaspiBlasters irgendwann mal zufriedenstellend funktionieren sollte.

    Interessant ist, dass in dieser Datei nichts drinsteht, aber der HifiBerry DAC+ dort einwandfrei funktioniert. Wobei ich dies letztlich nur mit omxplayer -o alsa verifiziert habe.

    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 :danke_ATDE: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).

    ubuntu-PC: Kommando "aplay -l" und Datei "/etc/asound.conf"

    aplay -l liefert:

    Code
    **** 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

    Die Datei /etc/asound.conf existiert auf meinem ubuntu 16.04 nicht.

  • ~/.asound.conf wird meines Wissens von Alsa bzw. den Anwendungen ignoriert - zumindest kenne ich die Datei bis jetzt nicht. Es gibt ~/.asoundrc für die benutzerspezifische und /etc/asound.conf für die systemweite Konfiguration und Neustart sollte eigentlich keiner notwendig sein, außer für speziellere Sachen – es genügt in der Regel die betreffende Anwendung zu beenden und wieder zu starten.

    Wenn ich mich einmal auf den ersten Auszug für den RaspiBlaster beschränken darf (die Soundkarte heißt beim zweiten, yamuplay, ohnehin gleich, daher sollte es dort genauso funktionieren):

    Es sieht eigentlich alles richtig aus, bis auf das fehlende dmix, damit mehrere Anwendungen Audio wiedergeben können und das kannst du so einbauen (ich habe auch die Namen der definierten pcms etwas vereinfacht)

    Wenn nun über das „Standardgerät“ wiedergegeben wird, durchlaufen die Audiodaten drei Alsa-Plugins

    - plug (default) nimmt eventuell notwendige Konvertierungen vor (Samplerate, -format, Kanalzahl)

    - softvol (softvolume) macht eine Lautstärkeregelung in Software

    - dmix (dmixer) mischt die Audioausgaben mehrerer Anwendungen (der muss immer als letztes kommen, weil dmix nur direkt an Soundkarten, nicht aber andere plugins weiterleitet)

    Wenn allerdings kscd bereits bei den vorigen Einstellungen über default wiedergegeben hat, hätte die Lauststärkeregelung auch schon vorher funktionieren sollen.

    Ich könnte mir vorstellen, dass das daran liegt, dass kscd als KDE-Programm wahrscheinlich eine kde-typische Abstraktionsschicht zur Audiowiedergabe nutzt (phonon) und gerade phonon habe ich als etwas störrisch in Erinnerung, wenn es darum geht, dass es die eigene Alsakonfiguration nutzen soll. Eigentlich glaube ich, dass ein KDE-Programm wie kscd eine etwas ungünstige Wahl für die Wiedergabe von Audio-CDs ist und das gilt umso mehr, als man ohne weitere KDE-Pakete erst einmal keine einfache Möglichkeit hat phonon irgendwie zu konfigurieren und das ganze dann auf ein System hinausläuft, das alles andere als schlank und übersichtlich ist, was auf dem RPi aber bestimmt von Vorteil wäre.

    Falls auch andere Programme in Frage kommen: Hast du KSCD wegen der grafischen Oberfläche ausgewählt oder anders gefragt, welche Kriterien muss denn das CD-Abspielprogramm denn erfüllen?

  • 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:

    ~/.asoundrc mit den alten Inhalten
    Code
    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. :thumbup: :danke_ATDE:

    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:thumbdown:


    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!

  • Es gibt schon noch einige Alternativen, aber alles unter einen Hut zu bringen wird schwierig. Mir persönlich gefällt mpd sehr gut, das bis auf d) wohl alles erfüllt und mit d) wird es wird es insofern schwierig, als bei den meisten Playern die Tracks einer CD nun einmal in einer Art Playlist (meist Wiedergabewarteschlange genannt) landen. Wobei einige der Punkte (a), b)) vom mpd-Client abhängen – dafür habe ich es als verhältnismäßig einfach empfunden mit python einen kleinen mpd-Client zu schreiben, der auf Taster und Drehimpulsgeber reagiert und ein paar LEDs und ein Display steuert.

    Ich bin ja nicht ganz sicher wie du dir die Bedienung vorstellst, aber ich würde eine udev-Regel anlegen, die beim Einlegen einer CD ein Skript oder ähnliches aufruft, das herausfindet ob es sich um eine Audio-CD handelt (eventuell geht das mit der udev-Regel sogar direkt, aber auf Anhieb weiß ich nicht wie) und wenn ja, die Titel zur Wiedergabewarteschlange von mpd hinzufügt (und eventuell sogar gleich zum Spielen anfängt).

    Sonst gehst du mit alsaplayer imho schon in die richtige Richtung von etwas einfachereren Programmen, auch wenn ich alsaplayer nicht so gut in Erinnerung in habe (ich habe gedacht, das gibt es schon lange nicht mehr ;))

    Sonst fallen mir noch vlc, goobox und xmms2 (letzteres kenne ich aber nicht) ein.

  • *** 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) :shy:

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

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

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

    * :auslachen:TODO:

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

    und noch ein paar andere "Kleinigkeiten" :baeh2:

    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.

  • Ich will dir nichts ausreden, aber wäre es da nicht ungleich einfacher einen Player zu nehmen, um den du nur eine GUI drumherum basteln musst. wenn es nicht sogar ohnehin schon eine passende gibt?

    xmms2, mpd, vlc und bestimmt noch viele andere lassen sich jedenfalls einfach von anderen Anwendungen steuern und wenn es dein Wunschplayer nicht auch schon kann, dann lässt sich er sich höchstwahrscheinlich über dbus mittels mpris steuern.

    (mich hat es jedenfalls erstaunt, dass ein mpd-Client, der den Status über LEDs und ein LCD anzeigt und auf Taster und Drehimpulsgeber reagiert in python recht einfach zu realisieren ist. Wenn ich mir dagegen das Quellcode-Archive von audacious ansehe...)

  • 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 :thumbup: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!

  • 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).

    Eigentlich meine ich aber, dass sich das Auswerfen nicht so auswirken dürfte, wie du es beschrieben hast. Vielleicht komme ich einmal dazu, das mit mpd auszuprobieren.


    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).

  • 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".

    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!

    • Offizieller Beitrag

    Hallo schlizbäda,

    Allerdings weiß ich nicht, ob er auch für das Abspielen von echten CDDAs geeignet ist

    auf der Input plugins-Seite des MPD wird libcdio erwähnt. Das könnte etwas sein was Du suchst. :denker:

  • entschuldige, dass ich den Thread nur oberflächlich überflogen habe (und dass diese Tatsache so offensichtlich zutage tritt :angel:)

    Jedenfalls audio-CDs mit mpd funktionieren und das ganz ohne Datenbank. Du musst nur nach dem einlegen der CD dafür sorgen, dass die Tracks der CD in der Wiedergabewarteschlange landen.

    Dank der udev-Events sollte das mit einer eigenen udev-Regel funktionieren. Ich würde es in Anlehung an [1] so angehen

    • Eine udev-Regel, die beim Einlegen/Auswerfen von beliebigen CDs/DVDs (anders habe ich es nicht zusammengebracht) ausgelöst wird, die etwa so aussieht SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_MEDIA_CD}=="1", RUN+="/usr/local/bin/meinskript"
    • Das Skript (/usr/local/bin/meinskript) müsste dann zuerst prüfen ob es sich um eine Audio-CD handelt. Das kann zum Beispiel cd-info aus dem Paket libcdio-utils, ganz holzhammermäßig mit cd-info | grep "Disc mode is listed as: CD-DA"(exit-Status 0 bedeutet Audio-CD, keine Ausgabe und exit-Status ungleich 0 → irgendetwas anderes).
      Handelt es sich um eine Audio-CD lassen sich die Titel der CD leicht in die Wiedergabewarteschlange einreihen mpc add "cdda://"(eventuell wäre es auch eine gute Idee vorher die Warteschlange zu leeren)

    [1] http://jctechnotes.blogspot.co.at/2012/10/auto-r…rver-using.html

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!