Problemchen mit rpi bei Musikwiedergabe
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo,
ich habe hier das kleine Geschirr:
1 rpi3, 1 USB-Festplatte mit eigener Stromversorgung, 1 usb-ifi nano DAC inkl Kopfhörerverstärker
Die sollen autark mobil arbeiten, also ohne einen weiteren Rechner als Server für die Musikdateien.
Softwarevariante 1: DietPi + minimserver + convoproxy
htop zeigt, das der rpi sich im Prinzip langweilt.
Problem: Die Musikwiedergabe ist nicht störungsfrei, immer wieder hakt sie ein wenig. Musikgenuss ist so nicht möglich. Es ist dabei egal, ob die Musikdaten durch minimserver -> convoproxy gereicht werden oder nur vom minimserver solo angereicht werden. Es ist auch egal, ob von convoproxy resamplet wird oder nicht.
Ich hatte den Verdacht, dass das Problem darin begründet ist, dass alle USB-Anschlüsse beim über eine Bus-Leitung laufen, wenn ich mich recht erinnere.
Dann Softwarevariante 2: PicorePlayer + Lyrion Server + Camilladsp. Das C-3PO-Transcoding Helper Plugin resamplet auf 19200 KHz.
Die Wiedergabe ist damit problemlos.
Also kann es im Prinzip wohl nicht am USB-Transfer liegen.
Offenbar verwalten die beiden "Betriebssysteme" PicorePlayer und DietPi die gegebenen Ressourcen anders?
Was also tun, wenn die Softwarevariante 1 im Prinzip die klanglich ein wenig schönere ist und störungsfrei betrieben werden soll?
Ach ja, mit einem rpi4 sieht's nicht signifikant besser aus, vielleicht ist die Zahl der Hakeleien bei Variante 1 geringer.
Viele Grüße
Jochen
ich habe hier das kleine Geschirr:
1 rpi3, 1 USB-Festplatte mit eigener Stromversorgung, 1 usb-ifi nano DAC inkl Kopfhörerverstärker
Die sollen autark mobil arbeiten, also ohne einen weiteren Rechner als Server für die Musikdateien.
Softwarevariante 1: DietPi + minimserver + convoproxy
htop zeigt, das der rpi sich im Prinzip langweilt.
Problem: Die Musikwiedergabe ist nicht störungsfrei, immer wieder hakt sie ein wenig. Musikgenuss ist so nicht möglich. Es ist dabei egal, ob die Musikdaten durch minimserver -> convoproxy gereicht werden oder nur vom minimserver solo angereicht werden. Es ist auch egal, ob von convoproxy resamplet wird oder nicht.
Ich hatte den Verdacht, dass das Problem darin begründet ist, dass alle USB-Anschlüsse beim über eine Bus-Leitung laufen, wenn ich mich recht erinnere.
Dann Softwarevariante 2: PicorePlayer + Lyrion Server + Camilladsp. Das C-3PO-Transcoding Helper Plugin resamplet auf 19200 KHz.
Die Wiedergabe ist damit problemlos.
Also kann es im Prinzip wohl nicht am USB-Transfer liegen.
Offenbar verwalten die beiden "Betriebssysteme" PicorePlayer und DietPi die gegebenen Ressourcen anders?
Was also tun, wenn die Softwarevariante 1 im Prinzip die klanglich ein wenig schönere ist und störungsfrei betrieben werden soll?
Ach ja, mit einem rpi4 sieht's nicht signifikant besser aus, vielleicht ist die Zahl der Hakeleien bei Variante 1 geringer.
Viele Grüße
Jochen
-
Hironimus_23 · „wie Hironimus_23 zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 897
- Registriert: 29.12.2012
- Wohnort: Norddeutschland
- „wie Hironimus_23 zum aktiven Hören kam“
Hallo Jochen,
eine Lösung kann ich dir nicht nennen, aber ggf. Ansätze, um das Problem einzugrenzen.
Beide von dir genannten Wege betreibe ich bei mir und sie funktionieren beide:
Hörraumanlage: Ein SBC x64 Atom/Intel mit DietPi, MinimServer, ConvoProxy und gmediarenderer. Controlpoint ist die JPlay-App auf dem Smartphone.
Wohnzimmeranlage: Ein RasPi 3 mit aroioOS (wegen Korrekturfilter); Lyrion-Server läuft auf einem anderen Rechner (NAS). Controlpoint ist iPeng auf dem Smartphone bzw. Lyrion-Desktopvariante auf einem anderen Rechner im Netzwerk.
Möglicherweise hat der Raspi nicht genug Leistung, um Server und Player zusammen zu betreiben? Zwar unwahrscheinlich, aber hast du es mal ausprobiert den Lyrion-Server auf deinem anderen RasPi 4 zu betreiben, sodass der RasPi 3 nur als Player agiert?
Zweiter Ansatz, ggf. hast du für deinen RasPi eine HAT-Karte, die eine SPDIF-Schnittstelle (Coax oder TOSLINK) bereitstellt und du damit in deinen DAC gehen kannst? Oder eine HAT-Karte, die einen DAC onboard hat und du damit direkt in deinen Vorvorverstärket gehen kannst? Damit könntest du die USB-Ausgänge auf dem Raspi umgehen, da die HATs über die GPIO-Steckerleiste laufen, und schauen, ob die Ursache des Problems im Bereich der USB-Anschlüsse steckt.
Wir geschrieben, nur Ansätze, noch keine Lösung.
Viele Grüße
René
eine Lösung kann ich dir nicht nennen, aber ggf. Ansätze, um das Problem einzugrenzen.
Beide von dir genannten Wege betreibe ich bei mir und sie funktionieren beide:
Hörraumanlage: Ein SBC x64 Atom/Intel mit DietPi, MinimServer, ConvoProxy und gmediarenderer. Controlpoint ist die JPlay-App auf dem Smartphone.
Wohnzimmeranlage: Ein RasPi 3 mit aroioOS (wegen Korrekturfilter); Lyrion-Server läuft auf einem anderen Rechner (NAS). Controlpoint ist iPeng auf dem Smartphone bzw. Lyrion-Desktopvariante auf einem anderen Rechner im Netzwerk.
Möglicherweise hat der Raspi nicht genug Leistung, um Server und Player zusammen zu betreiben? Zwar unwahrscheinlich, aber hast du es mal ausprobiert den Lyrion-Server auf deinem anderen RasPi 4 zu betreiben, sodass der RasPi 3 nur als Player agiert?
Zweiter Ansatz, ggf. hast du für deinen RasPi eine HAT-Karte, die eine SPDIF-Schnittstelle (Coax oder TOSLINK) bereitstellt und du damit in deinen DAC gehen kannst? Oder eine HAT-Karte, die einen DAC onboard hat und du damit direkt in deinen Vorvorverstärket gehen kannst? Damit könntest du die USB-Ausgänge auf dem Raspi umgehen, da die HATs über die GPIO-Steckerleiste laufen, und schauen, ob die Ursache des Problems im Bereich der USB-Anschlüsse steckt.
Wir geschrieben, nur Ansätze, noch keine Lösung.
Viele Grüße
René
-
tom_on_wheels · „wie tom_on_wheels zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 1292
- Registriert: 11.07.2010
- Wohnort: Berlin
- „wie tom_on_wheels zum aktiven Hören kam“
Hallo Jochen,
hast Du mal unter DietPi-Launcher => DietPi-Services geschaut, wie die Kerne belegt sind? Hier könntest Du die Services ja auf verschiedene Threads zuordnen.
Mehr fällt mir auf Anhieb nicht ein.
Viele Grüße
Tom
hast Du mal unter DietPi-Launcher => DietPi-Services geschaut, wie die Kerne belegt sind? Hier könntest Du die Services ja auf verschiedene Threads zuordnen.
Mehr fällt mir auf Anhieb nicht ein.
Viele Grüße
Tom
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Guten Morgen, René,
danke für deinen Beitrag.
Viele Grüße
Jochen
danke für deinen Beitrag.
Da sich die rpis laut htop langweilen, es ist wirklich nicht viel los auf den Kernen, glaube auch ich das eher nicht.Hironimus_23 hat geschrieben: 29.01.2025, 06:59 Möglicherweise hat der Raspi nicht genug Leistung, um Server und Player zusammen zu betreiben?
Wenn die Serversoftware (minim, convoproxy oder LMS) auf einem anderen Rechner laufen, gibt es kein Problem. Ich folgere daraus, dass der rpi genug Leistung hat, die aber ungünstig verwaltet im Falle DietPi.Zwar unwahrscheinlich, aber hast du es mal ausprobiert den Lyrion-Server auf deinem anderen RasPi 4 zu betreiben, sodass der RasPi 3 nur als Player agiert?
Guter Hinweis, da schaue ich nächste Woche mal in die Grabbelkiste.Zweiter Ansatz, ggf. hast du für deinen RasPi eine HAT-Karte, die eine SPDIF-Schnittstelle (Coax oder TOSLINK) bereitstellt und du damit in deinen DAC gehen kannst? Oder eine HAT-Karte, die einen DAC onboard hat und du damit direkt in deinen Vorvorverstärket gehen kannst? Damit könntest du die USB-Ausgänge auf dem Raspi umgehen, da die HATs über die GPIO-Steckerleiste laufen, und schauen, ob die Ursache des Problems im Bereich der USB-Anschlüsse steckt.
Viele Grüße
Jochen
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo Tom,
auch dir danke für den Beitrag.
Wie gesagt: Mich wundert nur, dass die PCP-Variante (auch mit LMS an Bord) keine Probleme hat, obwohl sie dieselbe Hardware bespielt. Offenbar ist es ein Unterschied, ob man Software auf die Musikwiedergabe optimiert oder "nur" eine für keine spezifische Aufgabe zugeschnittene "kleine" = abgespeckte Lösung anbietet wie DietPi.
Viele Grüße
Jochen
auch dir danke für den Beitrag.
Ja habe ich: Die für die Musik zuständigen Teile auf 1 & 2, den Rest, soweit man ihn erwischt, auf 0 & 3. Ich werde das noch strenger durchführen: Die Serversoftware auf einen Kern, gmediarender auf einen anderen.tom_on_wheels hat geschrieben: 29.01.2025, 08:27 hast Du mal unter DietPi-Launcher => DietPi-Services geschaut, wie die Kerne belegt sind? Hier könntest Du die Services ja auf verschiedene Threads zuordnen.
Wie gesagt: Mich wundert nur, dass die PCP-Variante (auch mit LMS an Bord) keine Probleme hat, obwohl sie dieselbe Hardware bespielt. Offenbar ist es ein Unterschied, ob man Software auf die Musikwiedergabe optimiert oder "nur" eine für keine spezifische Aufgabe zugeschnittene "kleine" = abgespeckte Lösung anbietet wie DietPi.
Viele Grüße
Jochen
-
tom_on_wheels · „wie tom_on_wheels zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 1292
- Registriert: 11.07.2010
- Wohnort: Berlin
- „wie tom_on_wheels zum aktiven Hören kam“
Hallo Jochen,
bei mir läuft DietPi auf einem X86er. Ganz kurz hatte ich DietPi, Minimserver und ConvoProxy versuchsweise auf einem RPI 3, mit SD-Karte. Das ist tadellos gelaufen. Ist allerdings schon länger her.
Viele Grüße
Tom
bei mir läuft DietPi auf einem X86er. Ganz kurz hatte ich DietPi, Minimserver und ConvoProxy versuchsweise auf einem RPI 3, mit SD-Karte. Das ist tadellos gelaufen. Ist allerdings schon länger her.
Viele Grüße
Tom
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo,
ich habe noch ein wenig rumgespielt.
1. DietPi auf bullseye-Basis installiert, kein bookworm mehr. Minimserver installiert: Musik läuft fehlerfrei.
2. Convoproxy installiert, naturbelassen: Musik läuft einwandfrei.
3. bufhrt aktiviert und/oder LoCo aktiviert: Musik läuft mit Stottern.
4. Das ändert sich auch nicht nach Deaktivierung der beiden Features. Auch nicht nach Neustart des rpi. Also CP gelöscht und nach Reboot neu installiert. Damit sind wir wieder bei 2.
5. Resampling in CP aktiviert: Musik läuft einwandfrei.
Scheint also so, dass einige Zusatzfunktionen von CP Probleme auf dem kleinen Rechnerchen bereiten, auch wenn die Services so auf die Kerne verteilt sind, dass sie sich möglichst nicht in die Quere kommen.
Mal weiter beobachten.
Viele Grüße
Jochen
ich habe noch ein wenig rumgespielt.
1. DietPi auf bullseye-Basis installiert, kein bookworm mehr. Minimserver installiert: Musik läuft fehlerfrei.
2. Convoproxy installiert, naturbelassen: Musik läuft einwandfrei.
3. bufhrt aktiviert und/oder LoCo aktiviert: Musik läuft mit Stottern.
4. Das ändert sich auch nicht nach Deaktivierung der beiden Features. Auch nicht nach Neustart des rpi. Also CP gelöscht und nach Reboot neu installiert. Damit sind wir wieder bei 2.
5. Resampling in CP aktiviert: Musik läuft einwandfrei.
Scheint also so, dass einige Zusatzfunktionen von CP Probleme auf dem kleinen Rechnerchen bereiten, auch wenn die Services so auf die Kerne verteilt sind, dass sie sich möglichst nicht in die Quere kommen.
Mal weiter beobachten.
Viele Grüße
Jochen
-
tom_on_wheels · „wie tom_on_wheels zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 1292
- Registriert: 11.07.2010
- Wohnort: Berlin
- „wie tom_on_wheels zum aktiven Hören kam“
Hallo Jochen,
dann schicke Michael doch mal eine Nachricht. Vielleicht kann er anhand eines Logfiles sehen, was da im Argen liegt.
Viele Grüße
Tom
dann schicke Michael doch mal eine Nachricht. Vielleicht kann er anhand eines Logfiles sehen, was da im Argen liegt.
Viele Grüße
Tom
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo,
ich glaube, ich habe den Wurm gefunden: bufhrt möchte nicht mit process isolation laufen. Offenbar kommt es dann mit der Prozessverteilung von DietPi zu Problemen.
Wenn bufhrt ohne isolation läuft, kann auch LoCo und Resampling laufen, ohne dass die Musikwiedergabe stolpert.
Viele Grüße
Jochen
ich glaube, ich habe den Wurm gefunden: bufhrt möchte nicht mit process isolation laufen. Offenbar kommt es dann mit der Prozessverteilung von DietPi zu Problemen.
Wenn bufhrt ohne isolation läuft, kann auch LoCo und Resampling laufen, ohne dass die Musikwiedergabe stolpert.
Viele Grüße
Jochen
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo,
noch eine (hoffentlich das Problemchen abschließende) Anmerkung: Es ist offenbar besser, wenn sich minimserver und convoproxy zwei Kernel teilen und nicht jeder einem zugewiesen wird. Der Linuxkernel verteilt die Last dann besser und CP beschlagnahmt nicht den einen zu nahezu 100%.
Viele Grüße
Jochen
noch eine (hoffentlich das Problemchen abschließende) Anmerkung: Es ist offenbar besser, wenn sich minimserver und convoproxy zwei Kernel teilen und nicht jeder einem zugewiesen wird. Der Linuxkernel verteilt die Last dann besser und CP beschlagnahmt nicht den einen zu nahezu 100%.
Viele Grüße
Jochen
-
Schorsch · „wie Schorsch zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 894
- Registriert: 17.02.2011
- Wohnort: Frankfurt am Main
- „wie Schorsch zum aktiven Hören kam“
Hallo Jochen,
das mit dem Prozess verteilen klingt schlüssig.
Wenn bufhrt einen eigenen Kern hat, ist das bei den NAS sehr deutlich hörbar. Hast Du mit einem anderen Tool die Prozesse für DietPi zugewiesen? Wenn ja, würde ich das mal weglassen und nur bufhrt seinen Prozess auslagern lassen.
Viele Grüße
Georg
PS: sehe gerade, Du hast neue Erkenntnisse ...
das mit dem Prozess verteilen klingt schlüssig.
Wenn bufhrt einen eigenen Kern hat, ist das bei den NAS sehr deutlich hörbar. Hast Du mit einem anderen Tool die Prozesse für DietPi zugewiesen? Wenn ja, würde ich das mal weglassen und nur bufhrt seinen Prozess auslagern lassen.
Viele Grüße
Georg
PS: sehe gerade, Du hast neue Erkenntnisse ...
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo Georg,
danke für den Hinweis. Also Lastumkehr und bufhrt auf isolation in CP konfiguriert und alles andere dem Linuxkernel überlassen. Klingt offenbar freier und luftiger als bei den verordneten Zwangsjacken zuvor.
Viele Grüße
Jochen
danke für den Hinweis. Also Lastumkehr und bufhrt auf isolation in CP konfiguriert und alles andere dem Linuxkernel überlassen. Klingt offenbar freier und luftiger als bei den verordneten Zwangsjacken zuvor.
Viele Grüße
Jochen
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo,
das Thema der Störungen, die im Ausgangsbeitrag genannt wurden, war doch noch nicht erledigt. Und so fanden diverse Tests und ein reger Mailaustausch mit Michael statt. Am Ende ergab sich, dass die mit Recht andernorts gelobte Stromversorgung mit dem "Akkunetzteil" von LHY-Audio nicht für jeden Anwendungsfall ausreicht. Es reicht völlig und macht einen hervorragenden Job, wenn ein WiiM oder rpi versorgt werden soll, der nur für die Musikwiedergabe zuständig ist oder höchstens einen Serverjob (minimserver auf rpi3 oder rpi4 in diesem Fall) zu versorgen hat. Es reicht nicht aus, wenn eine zweite "Serverschicht" (Convoproxy in diesem Fall) ins Spiel kommt. Dann kommt es zu den genannten Störungen oder die Musikwiedergabe bricht ganz ab.
All diese Problem waren verschwunden, wenn das LHY-Audio-Gerätchen durch eine hundsgewöhnliche Powerbank ersetzt wurde. Und der entscheidende Hinweis kam von Michael, der einen entsprechenden Verdacht hatte, als er sich die logfiles anschaute.
Ach ja, und wenn jemand fragt, wozu das ganze Spielchen diente: Genau dafür - eine kleine Spielerei war es.
Nebenbei gesagt: Die Kombination rpi (dietpi) + minimserver + Convoproxy klingt für meine Ohren (dank Convoproxy) deutlich besser, weil klarer und präziser, als die Kombination rpi (Picoreplayer) + Lyrionmusicserver + Camilladsp, die ein wenig muffig klingt im Vergleich. Wie gesagt meine Ohren.
Viele Grüße
Jochen
das Thema der Störungen, die im Ausgangsbeitrag genannt wurden, war doch noch nicht erledigt. Und so fanden diverse Tests und ein reger Mailaustausch mit Michael statt. Am Ende ergab sich, dass die mit Recht andernorts gelobte Stromversorgung mit dem "Akkunetzteil" von LHY-Audio nicht für jeden Anwendungsfall ausreicht. Es reicht völlig und macht einen hervorragenden Job, wenn ein WiiM oder rpi versorgt werden soll, der nur für die Musikwiedergabe zuständig ist oder höchstens einen Serverjob (minimserver auf rpi3 oder rpi4 in diesem Fall) zu versorgen hat. Es reicht nicht aus, wenn eine zweite "Serverschicht" (Convoproxy in diesem Fall) ins Spiel kommt. Dann kommt es zu den genannten Störungen oder die Musikwiedergabe bricht ganz ab.
All diese Problem waren verschwunden, wenn das LHY-Audio-Gerätchen durch eine hundsgewöhnliche Powerbank ersetzt wurde. Und der entscheidende Hinweis kam von Michael, der einen entsprechenden Verdacht hatte, als er sich die logfiles anschaute.
Ach ja, und wenn jemand fragt, wozu das ganze Spielchen diente: Genau dafür - eine kleine Spielerei war es.
Nebenbei gesagt: Die Kombination rpi (dietpi) + minimserver + Convoproxy klingt für meine Ohren (dank Convoproxy) deutlich besser, weil klarer und präziser, als die Kombination rpi (Picoreplayer) + Lyrionmusicserver + Camilladsp, die ein wenig muffig klingt im Vergleich. Wie gesagt meine Ohren.
Viele Grüße
Jochen
-
Melomane · „wie Melomane zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 3468
- Registriert: 14.10.2011
- „wie Melomane zum aktiven Hören kam“
Hallo,
offenbar eine never-ending-story.
Die angegebene Problemlösung gilt nur für einen rpi4. Ein gerade verwendeter rp3 bekommt's nicht hin bzw. nur dann, wenn minimserver und convoproxy auf einem anderen Rechnerchen laufen. Das sollte kein rpi3 sein, sondern ein leistungsfähigerer. Ich habe da einen alten Intel Celeron. Der tut den Job.
Nun ist aber der Ehrgeiz, den Celeron nicht immer zu bemühen. Also nur den rpi solo. Und da kommt dann wieder der PiCoreplayer ins Spiel. In Kombination mit CamillaDSP für das Crossfeed zum ifi-DAC/Kopfhörerverstärker und einer alten USB-Festplatte für die Musik. Das klappt in Sachen ungestörter Musikwiedergabe vorzüglich. Und ist halt besser als nichts, Und so läuft gerade das:
Sehr schön, die Produktion!
Wenn mal wieder Zeit für solche Basteleien ist, besorge ich mir vielleicht einen Odroid. Aber da möchte erst recherchiert werden, welcher in Frage käme.
Viele Grüße
Jochen
offenbar eine never-ending-story.
Die angegebene Problemlösung gilt nur für einen rpi4. Ein gerade verwendeter rp3 bekommt's nicht hin bzw. nur dann, wenn minimserver und convoproxy auf einem anderen Rechnerchen laufen. Das sollte kein rpi3 sein, sondern ein leistungsfähigerer. Ich habe da einen alten Intel Celeron. Der tut den Job.
Nun ist aber der Ehrgeiz, den Celeron nicht immer zu bemühen. Also nur den rpi solo. Und da kommt dann wieder der PiCoreplayer ins Spiel. In Kombination mit CamillaDSP für das Crossfeed zum ifi-DAC/Kopfhörerverstärker und einer alten USB-Festplatte für die Musik. Das klappt in Sachen ungestörter Musikwiedergabe vorzüglich. Und ist halt besser als nichts, Und so läuft gerade das:
Sehr schön, die Produktion!
Wenn mal wieder Zeit für solche Basteleien ist, besorge ich mir vielleicht einen Odroid. Aber da möchte erst recherchiert werden, welcher in Frage käme.
Viele Grüße
Jochen
-
Tinitus · „wie Tinitus zum aktiven Hören kam“
- Aktiver Hörer
- Beiträge: 1337
- Registriert: 10.11.2013
- „wie Tinitus zum aktiven Hören kam“
Hallo Jochen,
seid Jahren liegen bei mir zwei Odroid C1 in der Schublade. Kann auch sein das einer davon ein C1+ ist. Die haben den Vorteil, dass Netzwerk und USB von unterschiedlichen Chips gehandelt werden:
https://www.hardkernel.com/blog-2/bench ... c1-odroid/
https://wiki.odroid.com/odroid-c1/odroid-c1
Falls deine theoretische Betrachtung ergibt, dass die für Praxisversuche geeignet werden, kannst Du dich gerne bei mir melden, ich kann Dir einen gerne überlassen.
Gruß
Uwe
seid Jahren liegen bei mir zwei Odroid C1 in der Schublade. Kann auch sein das einer davon ein C1+ ist. Die haben den Vorteil, dass Netzwerk und USB von unterschiedlichen Chips gehandelt werden:
https://www.hardkernel.com/blog-2/bench ... c1-odroid/
https://wiki.odroid.com/odroid-c1/odroid-c1
Falls deine theoretische Betrachtung ergibt, dass die für Praxisversuche geeignet werden, kannst Du dich gerne bei mir melden, ich kann Dir einen gerne überlassen.
Gruß
Uwe