Gibt es irgendwo fertige jukeboxes zu kaufen die man dann mit raspberry pi und phoniebox nur noch konfigurieren muss? Ich weiß, Asche auf mein Haupt. Es ist nur so, dass mir momentan meine Zeit kostbarer ist als mein Geldbeutel.
Die Jukeboxen, die in diesem Thread vorgestellt werden, sind wohl unbezahlbar, da es sich um Einzelstücke handelt, die oft mit viel Liebe zum Detail gebaut wurden. Auch die Kinder werden ihre Jukeboxen vermutlich nicht mehr hergeben wollen!
Es handelt sich um das Meanwell-Netzteil RS25-5, siehe hier. Auch ich habe mit diesem Netzteil nur positiver Erfahrungen gemacht.
Yeah!
Betrieb mit HifiBerry MiniAmp mit Treiber dtoverlay=hifiberry-dac (ohne "plus")
...und die Umstellung in Raspbian Stretch Desktop (full) auf den HifiBerry MiniAmp lief absolut problemlos, es dauerte gerade mal fünf Minuten 
Gegenüber der Installation für den HifiBerry DAC+ mussten nur die beiden ALSA-Dateien angepasst werden. Die in Beitrag #16 zur Verfügung gestellten Bluetooth-Dateien für den rpi-audio-receiver von nicokaiser müssen nicht geändert werden!
sudo nano /boot/config.txt
Die Zeile dtoverlay=hifiberry-dacplus wird zu dtoverlay=hifiberry-dac (ohne "plus"!)
sudo nano /etc/asound.conf
Diese Datei ist beim HifiBerry DAC+ nicht unbedingt nötig und existierte daher noch nicht. Für den MiniAmp habe ich wieder meine mittlerweile erprobte Variante verwendet, die auch für den omxplayer funktioniert:
...und das übliche Gespiel, um die ALSA-Einstellungen für den MiniAmp scharf zu schalten:
Die Lautstärke kann ab jetzt mit dem Lautsprecher-Icon in der LXDE-Taskleiste gesteuert werden.
Damit steht einer Ergänzung der Bluetooth-Einbindung in den beiden Raspiblastern morgen nichts mehr im Wege 
Hähä!
Inbetriebnahme von https://github.com/nicokaiser/rpi-audio-receiver unter Raspbian Stretch with desktop and recommended software (full image)
...und soeben ist es mir gelungen, das Projekt auf dem aktuellen Raspbian Stretch desktop (full) vom 13.11.2018 unter folgender Vorgehensweise zu installieren:
Der Inhalt aller angepassten Dateien kann aus dem Dateianhang entnommen werden
Das github-Repository von nicokaiser enthält neben dem Bluetooth-Audioempfänger (A2DP) auch noch Empfänger für AirPlay (Apple), UPnP (Audioübertragung über Netzwerk, LAN/WLAN) und Spotify Connect. In diesem Beitrag beschreibe ich nur die Einrichtung des Bluetooth-Audioempfängers:
Um eine Bluetooth-Verbindung zum RPi mit Raspbian Desktop aufbauen zu können, muss das Bluetooth-Hardwaremodul des RPi über das Icon in der Taskleiste des LXDE-Desktops eingeschaltet werden!
Die Bluetooth-Verbindung vom Smartphone (Samsung Galaxy J5) zum RPi funktioniert problemlos.
Wenn eine andere Software über ALSA eine Audioausgabe macht, kann zwar eine Bluetooth-A2DP-Verbindung hergestellt werden: Die Musik wird auf dem sendenden Gerät "ganz normal" abgespielt, aber sie ist über den RPi natürlich nicht hörbar, da ja das andere Programm läuft. Wenn dieses andere Programm die ALSA-Audioausgabe beendet, schnappt sich der Bluetooth-Empfänger den ALSA-Kanal und die Musik vom Bluetooth-Sender wird wiedergegeben.
Ich habe noch nicht getestet, wie sich der Bluetooth-Audioempfänger unter Raspbian Desktop verhält, wenn mehrere Bluetooth-Sender versuchen, sich anzumelden. Dabei vermute ich allerdings keine wesentlichen Unterschiede zu Raspbian Lite (siehe Beitrag #13).
So, und jetzt Zähneputzen, pullern und ab ins Bett!
Äh ja, das vergaß ich gestern beim Verfassen des Beitrags: Das Kommando rpi-update, ein waschechtes Unding, habe ich selbstredend weggelassen! Aber auf so etwas sollte man für Neulinge etc. natürlich deutlich hinweisen!
rpi-update verwendet man nur, wenn man ganz bewusst den neuesten Kernel verwenden will. Dazu muss man wissen, dass die damit heruntergeladene Kernelversion nicht stable ist, sondern sich noch mitten im Entwicklungs- und Teststadium befindet!
Servus kle ,
danke für den Hinweis auf https://github.com/lukasjapan/bt-speaker.
Mit den in unserem Haushalt befindlichen bluetoothfähigen Geräten gibt es damit allerdings diverse Probleme:
Aufgrund dieser mittelmäßigen Praxiserfahrung suchte ich auf github nach weiteren Bluetooth-Audioempfängern und fand https://github.com/nicokaiser/rpi-audio-receiver. Damit funktioniert die Bluetooth-Übertragung der Audiodaten zum RPi wesentlich besser. Ich habe das github-Repository unter Raspbian Stretch Lite laut github-Anleitung (README.md) EDIT: allerdings ohne das Kommando sudo SKIP_WARNING=1 rpi-update!!! auf meinem RPi 3B+ mit HifiBerry DAC+ installiert und es lief "out of the box": Mit allen Android-Geräten aus dem Spoiler konnte ich ohne Probleme eine einwandfreie Audioübertragung zum RPi herstellen.
Nur mit meinem Crosscall-Tastenhandy Spider X1 konnte ich keine Bluetooth-Verbindung zum RPi aufbauen, allerdings sehr wohl zum käuflichen Bluetooth-Lautsprecher JBL GO 2. Das liegt vermutlich am Protokoll Profil A2DP, das der RPi erwartet, aber das Crosscall-Handy noch nicht kann. Das ist mir aber ehrlich gesagt wurscht (egal)!
Bei meinen Tests fielen mir folgende Punkte auf:
1. Der RPi ist als "AirPi" bluetoothmäßig immer sichtbar (vom Programmierer offenbar so gewollt)
2. Beim Bluetooth-Verbindungsaufbau zwischen Android-Gerät und RPi findet ein etwas seltsames Pairing / Koppeln statt:
Mehrere Geräte können laut Android gleichzeitig erfolgreich eine Verbindung zum RPi aufbauen. Allerdings kann nur das zuerst angemeldete Gerät seine Audiodaten tatsächlich an den RPi übertragen. Erst wenn die Bluetooth-Verbindung von diesem Gerät getrennt wird, kann ein weiteres bereits angemeldetes Gerät seine Audiodaten loswerden (oder es meldet sich ein ganz neues Gerät an).
3. Wird nun wild herumgespielt und mehrere Geräte ständig und in zufälliger Reihenfolge an- und abgemeldet, so kann es mitunter plötzlich (d.h. ich kenne die Gesetzmäßigkeit nicht) passieren, dass kein Gerät mehr angemeldet werden kann. Da hilft dann nur noch das Kommando systemctl restart bluetooth auf dem RPi!
4. Der Bluetooth-RPi kann bei Verwendung des Audioreceivers von nicokaiser "nur" das Bluetooth-Profil A2DP umsetzen. Das ist vermutlich der Grund, warum vom Handy Crosscall Spider X1 keine Audioverbindung aufgebaut werden kann. Zum Bluetooth-Lautsprecher JBL GO 2 jedoch schon, vermutlich weil der neben A2DP (Advanced Audio Distribution Profile) V1.2 auch noch die Profile AVRCP V1.5, HFP (Hands Free Profile) V1.5 und HSP (Headset Profile) V1.2 unterstützt.
5. EDIT: kle
wies darauf hin, dass in der Installationsanleitung das Kommando rpi-update vorkommt. Auch in einigen Installationsskrips ist dieses Kommando enthalten. Bei Verwendung des aktuellen Raspbian Stretch Lite (vom 13.11.2018) ist dieses Kommando jedoch nicht notwendig. Ohne zwingenden bzw. konkreten Grund sollte es grundsätzlich nicht ausgeführt werden!
TODO's: -- Nur Stichpunkte, aber deshalb markiere ich diesen Thread noch nicht mit dem Erledigt-Flag...
- pairing, koppeln
- Restart des Bluetooth-Daemons mit systemctl restart bluetooth manchmal erforderlich... Beheben/automatisch erkennen?
- Implementierung im Raspiblaster -- prinzipiell erledigt:
a) Einspielen auf Raspbian Stretch Desktop -- erledigt, siehe Beitrag #16
b) Test mit MiniAmp (ALSA-Konfig) -- erledigt, siehe Beitrag #17
Ich habe vom HifiBerry MiniAmp einen Stromlaufplan gezeichnet, das könnte an dieser Stelle auch interessant sein:
Stromlaufplan HifiBerry MiniAmp 1.0
Neben den obligatorischen GND-, 3.3V- und 5V-Pins sind am MiniAmp nur folgende Pins tatsächlich belegt:
Pin 12 (GPIO 18, PCM_CLK): I2S-BCLK
Pin 35 (GPIO 19): I2S-SYNC
Pin 40 (GPIO 21): I2S-DATA
Pin 36 (GPIO 16): MUTE (direkt am 3W-Class-D-Verstärker)
Pin 37 (GPIO 26): SHDN (direkt am 3W-Class-D-Verstärker)
Interessant ist dabei:
Beim MiniAmp ist keine Steuerung über I2C erforderlich/notwendig, da die I2C-Pins 3 (GPIO 2) und 5 (GPIO 3) nicht verdrahtet sind.
Es ist keine Erkennung über das RPi-HAT-Plug+Play-System möglich, da kein ID-EEPROM an den ID-Pins 27 und 28 angeschlossen ist.
Heute würde ich bei dieser Schaltung auf der Primärseite zusätzlich ein Kondensatornetzteil implementieren und nicht nur einen billigen Widerstand vorschalten. Siehe hier
PS:
Die Billig-USV funktioniert nach wie vor auch heute noch, im Februar 2019. Der Mediacenter-RPi läuft beinahe täglich und ich hatte noch nie ein korruptes Dateisystem auf der SD-Karte.
Vielen Dank kle,
ich habe Deinen Hinweis als einen weiteren Link auf meinen (derzeit) zum Merkzettel degradierten Thread RPi als Bluetooth-Lautsprecher unter Raspbian Stretch gesetzt.
Vielen Dank!
Es freut mich, dass Du (und einige andere) an mich denken 
Jetzt ist aber erst mein Retro-Gaming-Controller dran, basierend auf dem Arduino Esplora, für den mir dale
großzügigsterweise einen 3D-Druck von einem Gehäuse hergestellt hat...
Wirklich ein super Forum hier mit tollen Leuten!
Version 0.4.0 auf github hochgeladen
Ich habe einige Änderungen vorgenommen, da ich dieses Python3-Script auf den beiden Raspiblastern der Buben installiert habe:
- Standard-Fenstergrößen für die Auflösung (800 x 480 pixel) des original 7" DSI-Displays der RPi-Foundation angepasst.
Keine Angst, wirkt sich auf größere Bildschirme nicht aus!
- Bedienung etwas verbessert, insbesondere werden laufende Videos während diverser GUI-Aktionen transparent geschaltet
- Ein (wirklich billiges) Installationsscript yamuplay-setup.sh hinzugefügt
- und endlich die Icongrafik eingebunden, die mir hyle schon vor mindestens einem halben Jahr zukommen ließ, dafür ein herzliches Dankeschön!
Der Rest steht im Detail auf Github in der README.md sowie in den Commit-Kommentaren
... und Linus
, Deinen Github-Issue habe ich nicht vergessen, nur aufgeschoben 
Davon will ich auf jeden Fall noch das Thema str.format umsetzen und mich mal (endlich) mit PEP8 beschäftigen.
Die Sache mit den Python-distutils (Installationsroutinen) war mir letztens zu stressig 
Ach ja, das LaTeX-PDF gehörte auch noch aktualisiert... 
Trotzdem wünsche ich allen interessierten schon mal viel Spaß!
schlizbäda
Ich hab die Lösung und es ist im Prinzip ganz einfach und hat nix mit MPD in dem sinne zu tun.
Und zwar ist das Problem die gpio-buttons.py den wenn diese aktiviert ist gibt es Doppelbelegungen von hifiberry gpios und der gpio-button.py das hatte damals @hailogugo schon ins seine Anleitung geschrieben... aber aufgrund des one line installer habe ich daran garnicht mehr gedacht...
ach ja, da war auch noch so ein Schmankerl, siehe Beitrag #41 in meinem Raspiblaster-Thread.
Da gibt es ja die (laut Forenkonsens) eher bessere und zu bevorzugende GPIO-Bibliothek pigpio. Die bremst jedoch anscheinend die Kommunikation über I²S zum HifiBerry (und wohl zu allen I²C-Soundkaten) aus, warum auch immer. Mittlerweile vermute ich, dass hier die Pins für I²S irgendwie für "Normalbetrieb" als I/O konfiguriert sind und evtl. erst auf I²S umgestellt werden müssen, ich weiß aber nicht wie. Jedenfalls hatte ich auch das Problem, dass die Audioausgabe einmal in Zeitlupe lief und ein anderes Mal gar nicht. Der optischen Anzeige von audacious konnte ich entnehmen, dass die Audioausgabe letztlich einfach langsamer ablief.
Mein Problem am Raspiblaster löste ich dann durch Umstellung von pigpio auf wiringPi. Oder ihr fieselt euch durch und schaut, wie die I²C-Pins bei der verwendeten I/O-Bibliothek richtig konfiguriert werden...
Display MoreSymptom:
Die Datei Latest_Folder_Played wird ums verrecken nicht gschrieben (bleibt leer):
sudo echo ${VALUE} > $PATHDATA/../settings/Latest_Folder_Played
LinkZumRepo (Zeile 354)
Grund:
Es scheint an dem sudo am Zeilenanfang zu liegen. Wenn ich die Datei lösche und sudo entferne funktioniert es auf einmal...
Hallo Henning,
der Befehl sudo bewirkt ja, dass die nachfolgende Befehlssequenz in dieser Zeile von root ausgeführt wird und nicht vom angemeldeten Benutzer pi. Jede Linux-Benutzerkennung hat ihr eigenes "Environment", in dem u.a. die Inhalte der Shellvariablen (z.B. $PATHDATA) induividuell und auf den Benutzer angepasst gespeichert sind. Bei $PATHDATA kann ich mir gut vorstellen, dass die Pfade bei root und pi abweichen. Somit wird die Datei mit sudo ... wohl durchaus (unter dem Pfad von root) angelegt, aber eben nicht in dem Verzeichnis, das für pi angegeben ist.
Prüfen kannst Du das im Script, indem Du zu Testzwecken bei Zeile 354 die beiden folgenden Befehle einfügst (und hinterher wieder entfernst):
Im Terminal müssten zwei entsprechende Zeilen ausgegeben werden.
PS:
Mir ist es jetzt zu aufwendig, das ganze Script durchzufieseln, nur um das Ganze zu analysieren, daher nur mein theoretischer Ansatz
bezüglich einer asound.conf für den HifiBerry MiniAMP kann ich vielleicht aushelfen (Siehe Dateianhänge). Hier hat mir das Forenmitglied smutbert
sehr geholfen, den MiniAMP bei meinem Raspiblaster (basierend auf dem audacious-Mediaplayer) vernünftig einzurichten, dafür nochmals 
Was mir letztlich auffiel, ist die Tatsache, dass mit dem omxplayer von Raspbian nur eine "einfache" ALSA-Konfiguration funktioniert. Eine etwas komplexere wie in meiner Beispieldatei, die einen Mixer implementiert, um mehrere Audioquellen gleichzeitig wiedergeben zu können, funktioniert zwar mit den meisten anderen Programmen, aber nicht mit dem omxplayer sowie mit Programmen, die darauf aufbauen, wie z.B. mein yamuplay. Aber der omxplayer ist bei diesem Projekt ja außen vor.
Ein weiterer Punkt ist die Anpassung an periphere Soundkarten wie die HifiBerry-Produkte in der config.txt. Dabei wurde für den MiniAMP folgender Block angepasst:
Wichtig ist, die interne "Soundkarte" des SoC 283x zu deaktivieren, was hier über Auskommentieren der Zeile dtparam=audio=on erfolgt und die Einbindung des richtigen Treibers für den HifiBerry MiniAMP: dtoverlay=hifiberry-dac
Der MiniAMP ist kompatibel zum HifiBerry DAC, nicht zum DAC+. Also unbedingt ohne Pluszeichen!
Interessant ist evtl. der folgende Forenthread: HifiBerry MiniAMP aktivieren
Zu meinem Raspiblaster habe ich auf github eine Installationsanleitung abgelegt. Dort kann anstelle des Gesamtprojektes auch die mit LaTeX erstellte PDF-Datei raspiblaster_de.pdf direkt heruntergeladen werden. Kapitel 3.2 der Anleitung beschreibt die Einrichtung des MiniAMP.
Servus Hofei,
soviel ich weiß (und das ist äußerst rudimentär), läuft kodi auf dem RPi im hardwarebeschleunigten GPU-Modus, soll heißen, die Grafik wird nicht in einem X11-Fenster/Framebuffer angezeigt, sondern über die HW-Video-Beschleunigung der GPU direkt zur Anzeige gebracht. Damit wird es wohl sehr schwierig/unmöglich, die Videoausgabe von kodi softwaremäßig in ein Fenster umzulenken.
Ich weiß jetzt gar nicht mehr genau, wie ich die Fensterausgabe in meinem yamuplay gelöst habe. Dort wird in der normalen Anzeige die omxplayer-Ausgabe (diese erfolgt auf die gleiche bzw. sehr ähnliche Art hardwarebeschleunigt) in die Koordinaten eines Fensters des X11-Desktops skaliert. Beim Verschieben des Fensters mit der Maus wird die Videoausgabe erst an die entsprechende Position verschoben, wenn die Maustaste losgelassen wird. Beim Minimieren bleibt die Videoausgabe meines Wissens derzeit noch in der gleichen Größe erhalten, das müsste ich nochmals kurz antesten. Meine Idee war, das Video auf die Größe und Position des grafischen Icons in der Taskbar anzupassen, aber da fehlt mir a weng der programmiertechnische Hintergrund in Python3/tkinter 
Der Einfachheit halber könnte man die Videoausgabe evtl. auch auf Koordinaten außerhalb des sichtbaren Bildschirmbereichs projizieren, so dass die Videoanzeige unsichtbar wird. Aber auch das habe ich noch nicht getestet.
Zurück zu kodi:
kodi verwendete ursprünglich (zumindest auf dem RPi) den omxplayer zur Videowiedergabe. Ich weiß nicht, ob das immer noch so ist, glaube aber, dass sich da etwas getan hat... Aber auf jeden Fall müsste man sich vermutlich durch den C++-Code hangeln und das ist schon heavy...
EDIT:
sorry, jetzt sehe ich erst, dass dies ein alter Beitrag ist, den Du bereits auf "erledigt" gesetzt hast...
Das genannte Meanwell-Netzteil RS25-5 (25W, 5V) habe ich in meinem Raspiblaster verwendet und kann es ebenfalls unumwunden empfehlen:
+ Kleine Bauform
+ Stabile Spannungsversorgung für RPi bis einschließlich 3B (der ohne Plus und mit 1,2GHz, den ganz neuen habe ich noch nicht) --> kein gelber Blitz
+ Preis/Leistungsverhältnis TOP
(nur so als Bestätigung und Zweitmeinung)
ohne es selbst probiert zu haben:
Es gibt offenbar das Softwarepaket kivy für Multitouch-Bedienung. Darauf verweist auch die RPi-Foundation in ihrer Vorstellung the eagerly awaited RaspberryPi display ziemlich am Ende des Artikels. Ohne Installation dieser Software verhält sich das offizielle DSI 7"-Display wie ein stinknormales single Touchdisplay...
Sorry, wer lesen kann, ist im Vorteil: Ich sehe gerade, dass sich der Thread auf Multitouch-Display mit OSMC (kodi) bezieht. Ich ging gerade von Raspbian aus. Nix für ungut!
Bei der olmatic S-USV gibt's ja die mobile-Version, die bei geladenem Akku ganz ohne Netzteil auskommt: Der RPi kann ohne 230V-Versorgung gestartet werden.
Soweit zur Theorie. Bei meinem desaströsen Projekt Raspiblaster hat (natürlich) auch das nicht funktioniert: Das Ding ist (nach Anschluss des 3000mAh-Akkus von olmatic) abgeraucht. Hat da jemand von Euch bessere Erfahrung, speziell mit der mobile-Variante?
Merker für mich selbst:
EDIT 21.08.2018:
Diesen Artikel habe ich mittlerweile zu Hause liegen, muss ich mal in Ruhe nachvollziehen...
EDIT 11.09.2018:
ungeprüfter Link: https://www.voss.earth/2018/04…h-lautsprecher-verwenden/
Weitere Threads zum Thema in diesem Forum:
* Raspi 3b+ Hifiberry Amp2 per Bluetooth streamen
* Airplay (Volumio) & Bluetooth-Empfänger, nur wie?
EDIT 25.11.2018:
Hinweis von kle
auf Bluetooth Audio for (headless) Raspbian systems, hier ist aber der RPi ein BT-Audio-Sender.
EDIT 04.12.2018:
Weiterer Hinweis von kle auf Pi3 Bluetooth-Verbindung mit Smartphone.
C# ist ja ein Compiler und keine Scriptsprache. Der Compiler liefert ein unter dem Betriebssystem lauffähiges Programm, das auf die Bibliotheken im .NET-Framework (oder hier unter Linux auf die Pendants des mono-Projektes) zugreift: Wie dbv richtig fragt, braucht's das mate-Terminal wirklich?
Unter Windows muss man in VB.NET (bzw. in C#) beim Aufruf einer *.bat-Datei allerdings wirklich "cmd.exe /D /C batchdatei.bat" (oder so ähnlich) angeben. Linux ist diesbezüglich anders organisiert. Dort hängt die Ausführbarkeit einer Datei nicht an der Erweiterung (*.exe, *.bat, ...), sondern am x-Attribut im Dateisystem. Beim Laden der Datei sucht Linux (bei Textdateien) dann eben nach dem shebang, um den dazugehörigen Interpreter zu ermitteln. Kommt aber auch darauf an, wie dies letztlich im Mono-Projekt umgesetzt ist.
Mir fehlt im Codeschnipsel eher die Parametrierung von gomail. Diesem Programm müssen doch Kommandozeilenparameter (oder Ähnliches) mitgegeben werden:
* e-mail-Empfänger
* e-mail-Text (oder der Zugriffspfad zu einer Textdatei)
* evtl. noch weitere Parameter (e-mail-Verfasser, SMTP-Server, ...)
--> vermutlich endet es mit einer Fehlermeldung, die man aber im C#-Programm nicht sieht, da sie nicht erfasst wird. Eine Abfrage des exitcodes von gomail würde vermutlich schon viel bringen... Das try-catch-Konstrukt beißt jedenfalls nur an, wenn im C#-Programm selbst der Fehler auftritt, weil z.B. die Programmpfade der aufzurufenden Programme falsch sind. Wenn aber gomail einen Fehler meldet, so war ja der gomail-Aufruf in C# an sich nicht fehlerhaft.
Auch bleibt das aufrufende Programm für 10 sec stehen, da das Terminal offenbar modal aufgerufen wird.
Das ist ja vom Ablauf her in Deinem Codeschnipsel auch genauso programmiert: Selbst wenn gomail parallel zu Deinem Prozess laufen sollte, was ich jetzt gerade nicht weiß, beginnt nach dem Starten mit myProcess.Start(); eine Wartezeit von 10000ms, bevor myProcess beendet wird. Da ist es unerheblich, ob gomail vorher beendet wird oder sogar noch läuft. Im letzteren Fall wird es während seiner Abarbeitung von außen beendet (gekillt)! Also anstelle einer festen Wartezeit eine Schleife mit kurzen sleep(100);(oder so), in der man prüft, ob gomail noch läuft oder schon beendet ist. Dann den Exitcode auslesen und auswerten und myprocess() schließlich sauber beenden (letzteres ist schon im Code vorhanden)
Hi Capitaen,
was hast Du bezüglich Bluetooth gelöst? Ich habe da nämlich auch ein Problem, ich will den RPi als Bluetooth-Lautsprecher einsetzen und da hakt es auch noch...
