PC für eigen entwickeltes Produkt

Niklas T. schrieb:
> Wie nennt man solche PCs, kann man die kaufen (Industrie PCs?)?

Such dir aus dem Angebot was raus... Industrie-PCs ist eine Variante, 
die haben aber eher andere Zielgruppen/Spezifikationen. Ab einer 
gewissen Menge oder Geldbetrag kann man sich das auch passend designen 
lassen. Ich würd weiter Richtung NUC schauen, viel besser/einfacher 
wirds nicht.

Niklas T. schrieb:
> ich möchte einen eigene DJ-Player entwickeln. So ähnlich bei zB ein
> Pioneer XDJ oder CDJ.

Schon geguckt was in denen drinnen ist?

Niklas T. schrieb:
> Also, was zB Pioneer für einen PC in ihren DJ-Produkten verwendet.

Wie kommst du darauf? Nein, die verwenden keine PCs.

Hier ein paar Bildchen die man schnell im Internet findet:

https://cdn11.bigcommerce.com/s-pdowf1mync/images/stencil/1280x1280/products/373798/115102/DWX4103__66254.1567191142.jpg

Was sieht man? Links ein SoC mit DRAM und recht vermutlich einen 
dickeren DSP ebenfalls mit DRAM.

https://www.bopdj.com/media/catalog/product/cache/207e23213cf636ccdef205098cf3c8a3/s/c/screen_shot_2018-11-27_at_11.20.09_1.png

Da sieht man nur einen SoC mit DRAM und Flash.

https://cdn11.bigcommerce.com/s-pdowf1mync/images/stencil/1280x1280/products/373768/114656/main-pcb-board-pioneer-xdj1000-1__09200.1556868764.jpg

Da wieder SoC, DRAM, Flash und ein DSP mit seinem DRAM.

Die Platinen entwickeln die sehr wahrscheinlich selbst oder lassen sie 
extra für sich entwickeln. Das kostet Geld, lohnt sich aber bei deren 
Preisen und Stückzahlen.

Niklas T. schrieb:
> Weil der RPI viel zu wenig Leistung.

Was kann denn dein Player so tolles? In einem CDJ ist was mit deutlich 
weniger Leistung verbaut. Allerdings ist die Arbeit auf mehrere 
getrennte CPUs verteilt (Eine für die zentrale Steuerung, eine für's 
Display, eine für das CD-Laufwerk, eine für das Frontpanel und ein DSP 
für die Audio-Verarbeitung). Das ist kein Monolith, und es ist auch 
nichts von der Stange, sondern selbst entwickelt, speziell für diesen 
Anwendungsfall. Und ein klassisches PC-Betriebssystem läuft da auch 
nicht drauf.

Gustl B. schrieb:
> Hier ein paar Bildchen die man schnell im Internet findet:

Man kann auch ein Service-Manual mit einem Blockschaltbild finden, dem 
man deutlich mehr Infos über den Aufbau und die Komponenten entnehmen 
kann. Da ich aber nicht weiß, ob das legal ist, hier kein Link. Der 
geneigte Leser sollte aber auch in der Lage sein, das mit der 
Suchmaschine des geringsten Misstrauens selber zu finden.

> Die Platinen entwickeln die sehr wahrscheinlich selbst oder lassen sie
> extra für sich entwickeln. Das kostet Geld, lohnt sich aber bei deren
> Preisen und Stückzahlen.

Das würde sich vermutlich auch bei normalen Preisen noch lohnen.

Latte Panda.

Niklas T. schrieb:
> Also, was zB Pioneer für einen PC in ihren DJ-Produkten verwendet.
> Stellen sie diese selbst her?

Der Trick ist, dass die Software stark für einen Prozessor optimiert ist 
und der Prozessor vieles in Hardware kann, was Mixxx in Software leisten 
muss.

Effekte, Decoding,... All das kann ein DSP, ohne groß darüber nachdenken 
zu müssen.

Grafische Ausgabe ist auch rechenintensiv. Das ganze "headless" ohne 
komplette OS-GUI mit ein paar GUI-Elementen auf einem kleinen 
SPI-Display zu machen, ist deutlich sparsamer.

Du brauchst also nicht unbedingt einen PC, der Mixxx laufen lassen kann, 
sondern Software, die nicht mehr macht, als sie soll. Und dafür reicht 
dann auch der Pi aus.

Ansonsten wird man um nen Intel NUC oder so vermutlich nicht 
herumkommen.

Niklas T. schrieb:
> Aber was macht Mixxx denn mehr als die DJ Funkion?
> Also abgesehen dass was ein CDJ in Hardware macht

Mixxx ist z.B. nicht wirklich für ARM-Prozessoren optimiert. Das heißt, 
einige Befehle und Funktionen, die ein x86 mit sich bringt, müssen aufm 
ARM über Umwege ausgeführt werden und das braucht Rechenleistung. Auch 
Audio-Decodierung und Grafische Dinge laufen vielleicht nicht über 
speziell dafür gedachte Teile des ARM-Prozessors, weil Mixxx nicht weiß, 
dass der Prozessor dafür eigene Funktionen hat. Stattdessen wirds 
umständlich und rechenintensiv über Software gelöst. 
GPU/Grafikbeschleunigung ist bei einem ARM einfach anders.

MP3s wiedergeben und ein sich drehendes Rädchen anzeigen ist eigentlich 
nicht aufwendig. Das kann ein billiger M4 mit 120MHz. Aber auch nur, 
wenn die Software dafür optimal genutzt wird und genau für den Prozessor 
geschrieben wurde.

Mixxx läuft auf vielen Systemen und setzt einige Dinge voraus.


Niklas T. schrieb:
> Meinst du, ich soll ein Programm entwickeln, welches nicht extra auf
> einem Betriebssystem laufen muss??

Kommt drauf an. Ich glaube nicht, dass auf den CDJs ein Linux drunter 
läuft, da wird vieles Bare-Metal sein.

Aber ein einfaches Linux (OpenWrt z.B.) kommt mit seehr wenig 
Systemvoraussetzungen klar und bietet eine vielleicht nützliche 
Abstraktionsebene wie ein standardisiertes Dateisystem und 
standardisierte Dateioperationen.

Niklas T. schrieb:
> ist das so einfach?

Für dich? Nein. Definitiv nicht. So leid es mir tut. Die Lösung ist halt 
nicht, mehr Leistung einbauen, damit Mixxx läuft, sondern die vorhandene 
Leistung so optimal zu nutzen, dass das Gerät tut, was es soll.

Niklas T. schrieb:
> Oder bestimmte Funktionen auf die Hardware bringen und dann ein ganz
> einfaches DJ Programm suchen/schreiben.

Auch das ist nicht trivial. Ein DSP ist im Prinzip auch erstmal dumm. 
Erst mit der richtigen Software kann er sehr effektiv Audio verarbeiten 
und z.B. EQ, Effekte, Mixing,... umsetzen.


Theoretisch hat ein oller RasPi 2 mehr als genug Leistung für das, was 
du vor hast. Du musst es nur optimal nutzen. Und da wirst du in deinem 
Fall nicht wirklich um ein großes Stück eigene Software umher kommen.

Mich würde es wundern, wenn für ein "bisserl Audio rechnen" ein RPi 
nicht reichen würde...

Hast du das Stromsparzeugs testweise einmal ausgeschalten und mit "top" 
mal die CPU Auslastung betrachtet?

Kann gut sein, dass dein Problem damit zu tun hat.


BTW: es gibt sogar ein RPi Howto für mixxx... google hilft :)

https://github.com/fayaaz/mixxx-pi-gen
https://github.com/dennisdebel/pi_dj

73

Geht es denn darum, eine kleine Stückzahl dieses Geräts für den 
Eigenbedarf und ggf. ein paar Kumpels zusammenzuklöppeln oder um die 
Entwicklung, Herstellung und Inverkehrbringung eines darauf basierenden 
kommerziellen Produktes?

Niklas T. schrieb:
> Wenn ich ein eigenes Programm speziell für den RPI 4 Prozessor schreibe,
> aber auf dem RPI4 Linux Ubuntu oder etwas ähnliches läuft, würde dann
> das Betriebssystem selber schon zuviel Leistung wegnehmen?

Wenn das Raspian/Ubuntu/... schon sämtliche Systemlast beanspruchen 
würde, wäre das Produkt sicherlich nicht so ein Hit geworden.

Glaub mir, da ist mehr als genug Bums, um deine "popeligen" 
Anforderungen umzusetzen. Meinetwegen sogar in Python, was nicht gerade 
für Performanz bekannt ist (Interpretersprache halt)

> Wenn ja, gibt es noch mehrere OS wie zB OpenWRT die genau für sowas
> gemacht sind?

Jedes OS reicht dafür aus. Es gibt natürlich so Sachen wie Kodi, da 
läuft aber auch nur ein Debian drunter.

Weder das Linux noch die Leistung des RasPis sind dein Problem.

Das aktuelle Flaggschiff von Pioneer (CDJ 3000) setzt übrigens keinen 
DSP mehr ein, dafür mehrere ARM Cores, Renesas RZ irgendwas, und diverse 
spezifische ICs für die Peripherie (USB, Netzwerk, etc.).

Spätestens beim Jogwheel wirst Du aber auf etwas fertiges zurückgreifen 
müssen.

Die Frage ist, was kannst Du am Ende besser als z.B. ein DDJ 400 mit 
eben der Mixxx Software (oder Rekordbox) auf einem Laptop...

Sebastian R. schrieb:
> Glaub mir, da ist mehr als genug Bums, um deine "popeligen"
> Anforderungen umzusetzen. Meinetwegen sogar in Python, was nicht gerade
> für Performanz bekannt ist (Interpretersprache halt)

Stell Dir das mal nicht zu einfach vor. Bei dieser Art von Hardware geht 
es hauptsächlich um ein latenzarmes Verhalten. Wenn man Taste XYZ drückt 
oder am Jogwheel dreht möchte eine sofortige Reaktion, und nicht erst 
nach 1/10 Sekunde. Auch der Bildschirm (Wellenform) möchte 
verzögerungsfrei aktualisiert Werden.

Wenn die Wellenformen deckungsgleich sind, muss auch der Sound 
deckungsgleich sein, man hört kleine Verschiebungen zwischen zwei Beats 
relativ schnell.

Solche Sachen wie Keylock/Keyshift sind auch eher schwer in Python zu 
implementieren.

Ich möchte mal behaupten es bedarf schon einer Compilersprache für 
diesen Anwendungsfall.

Nein... audio ist "harmlos"...

Bei 2d Grafik kommt's eigentlich nur mehr auf die Treiber an... Ich 
finde, das sieht man am schönsten in einem CAD Package bei dem man 
OpenGL an und ausschalten kann (ist zwar 3d, aber man sieht den Effekt 
schön).

Da ist das Drehen von einem recht einfachen 3d Objekt selbst auf einem 
fetten PC nicht ruckelfrei ohne opengl.
Dagegen ist das quasi mit 0% CPU Auslastung flüssig, wenn man's wieder 
einschaltet.

Gerade mit Qt habe ich ziemlich gute Erfahrungen in Bezug auf die Grafik 
Geschwindigkeit... das nutzt ziemlich die Beschleunigungsfunktionen 
ziemlich effizient.

Wie gesagt, bei sowas stören auch oft die Stromsparfunktionen enorm...
Den Scheduler zwingen den Prozess auf einem fixen Core auszuführen kann 
auch etwas bei den Latenzen helfen.
Genau so könnte man den scheduler-tick auf 1kHz zu setzen - wenn das 
nicht der Fall sein sollte...

Ansonsten müsste so ein Jogwheel an den GPIOs vom RPi eigentlich gut 
funktionieren. Bei einem PC-Mainboard müsstest du auf USB oä. 
ausweichen... kann man machen (ich würde da so einen usb-logicanalyzer 
missbrauchen) - eleganter dürfte es aber über den GPIO gehen.

73

Sebastian R. schrieb:
> Wenn das Raspian/Ubuntu/... schon sämtliche Systemlast beanspruchen
> würde, wäre das Produkt sicherlich nicht so ein Hit geworden.
>
> Glaub mir, da ist mehr als genug Bums, um deine "popeligen"
> Anforderungen umzusetzen. Meinetwegen sogar in Python, was nicht gerade
> für Performanz bekannt ist (Interpretersprache halt)

Mit diesem "langsamen" Python lese ich auf einem RasPi4 einen Strom von 
720p-Bildern von einer Logitech C920, mache eine Bewegungserkennung 
darauf und schreibe das Ergebnis in einen lokalen Redis-Server -- mit 
dauerhaft stabilen 28 bis 30 FPS. Daß das geht und wesentlich 
performanter ist als spezialisierte Lösungen in kompilierten Sprachen 
wie Zoneminder oder Motion, ist, daß eine Vielzahl von 
Python-Bibliotheken in einer kompilierten Sprache geschrieben und 
hochoptimiert sind. Nicht zuletzt aus diesem Grund ist Python besonders 
dort beliebt, wo es um die Verarbeitung riesiger Datenmengen geht, 
Stichworte Big Data, Machine Learning und Co. Inwofern möchte ich Dir 
wärmstens ans Herz legen, Deine Kenntnisse alsbald einmal zu erweitern 
und sie angelegentlich ein wenig zu aktualisieren. ;-)

Ein T. schrieb:
> Mit diesem "langsamen" Python lese ich auf einem RasPi4 einen Strom von
> 720p-Bildern von einer Logitech C920, mache eine Bewegungserkennung
> darauf und schreibe das Ergebnis in einen lokalen Redis-Server -- mit
> dauerhaft stabilen 28 bis 30 FPS.

Und mit welcher Latenz? Für die hier diskutierte Anwendung darf sie 
höchstens im unteren einstelligen Millisekunden-Bereich sein.

> Daß das geht und wesentlich performanter ist als spezialisierte Lösungen
> in kompilierten Sprachen wie Zoneminder oder Motion, ist, daß eine
> Vielzahl von Python-Bibliotheken in einer kompilierten Sprache geschrieben
> und hochoptimiert sind.

Mit anderen Worten: Nur die Steuerung wird in Python gemacht. Die 
eigentliche Verarbeitung ist gar nicht darin implementiert.

Toppings schrieb:
> Da scheint was Faul zu sein oder Infos fehlen

Vor allem die Info, ob die Bewegungserkennung wirklich in Python 
implementiert ist, oder ob das Python da nur als "Klebstoff" zwischen 
div. Bibliotheksfunktionen dient.
Weil einen Frame-Pointer aus einer Funktion entgegenzunehmen und an 
andere weiterzureichen ist nun wirklich der am wenigsten zeitkritische 
Teil an dem ganzen.

Max M. schrieb:
> Hat er doch ganz deutlich geschrieben.

Es widerspricht aber der Aussage, dass das in Python gemacht sei. Ich 
wollte damit nur darauf hinweisen, dass es eben nicht in Python 
implementiert ist, sondern nur von Python aus genutzt wird.
Die Grundaussage war ja, dass Python trotz interpretierter Ausführung 
schnell genug sei, um die Aufgaben zu erledigen. Wenn die Implementation 
aber in Wirklichkeit in einer Hochsprache erfolgt und von Python aus nur 
aufgerufen wird, ist das natürlich keine große Kunst.

Rolf M. schrieb:
> Ein T. schrieb:
>> Mit diesem "langsamen" Python lese ich auf einem RasPi4 einen Strom von
>> 720p-Bildern von einer Logitech C920, mache eine Bewegungserkennung
>> darauf und schreibe das Ergebnis in einen lokalen Redis-Server -- mit
>> dauerhaft stabilen 28 bis 30 FPS.
>
> Und mit welcher Latenz? Für die hier diskutierte Anwendung darf sie
> höchstens im unteren einstelligen Millisekunden-Bereich sein.

Jedenfalls so, daß ich keinen zeitlichen Versatz zwischen Bewegung und 
Anzeige erkennen kann. Das reicht für meinen Anwendungsfall vollkommen 
aus. Ein "unterer einstelliger Millisekundenbereich" ist für 
Überwachungszwecke und die allermeisten anderen Anwendungsfälle einer 
Bewegungserkennung gar nicht nötig.

Was den Anwendungsfall des TO angeht, so bietet so ein Linux eine ganze 
Reihe an Möglichkeiten, die die von ihm gewählte Software anscheinend 
nicht ansatzweise auszunutzen scheint. So interpretiere ich jedenfalls 
den Hinweis, daß erst neuere Versionen der SW imstande zu sein scheinen, 
eine moderne Multicore-CPU mittels Parallelisierung auszunutzen. Und 
auch sonst... der Audioserver wie Jack für Echtzeit und Low-Latency 
wurde IMHO schon genannt, zusätzlich kann man den Prozeß höher 
priorisieren (nice(1)) oder ihn sogar mit dem Bootparameter isolcpus und 
dem Programm tasksel(1) auf dedizierte CPU-Cores schieben... da geht 
schon eine ganze Menge, und Realtime-Kernels für Linux gibt es ja auch 
noch.

All das setzt aber zwingend voraus, daß der TO zunächst einmal mißt, was 
denn da saturiert wird. Denn letztlich gibt es nur drei Dinge, die man 
vor dem Beginn jedweder Optimierungsmaßnahme wissen muß, nämlich erstens 
Donald E. Knuths altes und bekanntes "Premature optimization is the root 
of all evil", die Ergänzung von Kirk Pepperdine "Measure, don't guess" 
sowie drittens das gute alte "Make it work, make it right, make it fast" 
von Kent Beck. Wer das nicht beherzigt, hat ohnehin schon verloren -- 
auch dann, wenn er fettere Hardware auf das Problem schmeißt.

> Mit anderen Worten: Nur die Steuerung wird in Python gemacht. Die
> eigentliche Verarbeitung ist gar nicht darin implementiert.

Ja, und? Der Python-Interpreter und ein großer Teil der 
Standardbibliotheken ist in nativem Code implementiert. Und Pythons 
JIT-Interpreter Pypy ist manchmal sogar performanter als C: [1], 
jedenfalls bei einem "carefully crafted example". Deshalb ist das, was 
mein Vorposter behauptet hatte -- nämlich, daß Python total langsam sei 
-- schlicht und ergreifend: nicht wahr.

[1] 
https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html

Toppings schrieb:
> Ein T. schrieb
>> Mit diesem "langsamen" Python lese ich auf einem RasPi4 einen Strom von
>> 720p-Bildern von einer Logitech C920, mache eine Bewegungserkennung
>> darauf und schreibe das Ergebnis in einen lokalen Redis-Server -- mit
>> dauerhaft stabilen 28 bis 30 FPS...
>
> Da scheint was Faul zu sein oder Infos fehlen...
> https://www.google.com/search?q=raspi+usb+langsam

Nö. Hingucken und mitdenken... ;-)

Rolf M. schrieb:

> wollte damit nur darauf hinweisen, dass es eben nicht in Python
> implementiert ist, sondern nur von Python aus genutzt wird.
> Die Grundaussage war ja, dass Python trotz interpretierter Ausführung
> schnell genug sei, um die Aufgaben zu erledigen. Wenn die Implementation
> aber in Wirklichkeit in einer Hochsprache erfolgt und von Python aus nur
> aufgerufen wird, ist das natürlich keine große Kunst.

Ganz genau.

Man kann also eigentlich zusammenfassen:

- Entweder nimmt man Standard Software (z.B. eben Linux + Mixxx) mit 
überdimensionierter Hardware um die Latenz gering zu halten, eben z.B. 
einen DJ Controller mit Laptop. Der Laptop ist eigentlich völlig 
überdimensioniert, aber bekommt es gerade so hin

- Oder spezielle Soft-und Hardware, was dann schon bei einem OS anfängt 
welches möglichst schlank und auf Realtime ausgelegt sein sollte und bei 
Verteilung der Aufgaben auf mehrere CPUs aufhört

Diese Standalone DJ-Player sind schon relativ anspruchsvoll von der 
Technik, auch wenn es ersteinmal nicht so aussieht. Aber es ist eben 
doch mehr als nur ein bisschen Audio abspielen und die Wellenform 
scrollen.

Dabei werden dann noch die Wellenformen / Beat über das Netzwerk 
synchronisiert, bei gesetzten Loops, Beatjumps oder sonstigen Eingriffen 
in den Spielfluss muss das ganze auch wirklich jitter-und driftfrei 
funktionieren, der vorgegebene Takt muss bei allen Aktionen 
berücksichtigt werden etc. sonst läuft der Mix auseinander.

Wenn so ein Player auch nur sporadisch irgendwelche Fehler oder sonstige 
Aussetzer hat wird Dir das jeder DJ um die Ohren hauen.

Wer mal eine Idee haben möchte was man aus solchem Equipment herausholen 
kann:

https://www.youtube.com/watch?v=Xr7nXWak7Jo

(und er spielt mit 4 Decks die synchronisiert sind)

Nicht ganz meine Musik, dennoch muss man sagen er hat es drauf!

Toppings schrieb:
> Lesen gelernt?

Ja, ich schon. Du hingegen...


> Ich beziehe mich auf die lahme USB-Technik im Raspi.
> Siehe Link..

Da geht es um USB Version 3. Und eine Logitech C920 hat? Genau. Fazit: 
Lesen bildet.

Toppings schrieb:
> Es schreibt weiter in Rätseln.. Lahmer Raspi-USB bleibt nunmal lahmer
> Raspi-USB. Wird langsam seeeeehr peinlich hier..

Ja, Dein Unwissen tut langsam wirklich schon beim Zugucken weh. Offenbar 
kennst Du nichtmal den Unterschied zwischen USB2 und USB3... bitte komm' 
wieder, wenn Du Dich wenigstens ein wenig (im Rahmen Deiner 
Möglichkeiten eben) schlau gemacht hast, ja?

Toppings schrieb:
> Es schreibt weiter in Rätseln.. Lahmer Raspi-USB bleibt nunmal lahmer
> Raspi-USB. Wird langsam seeeeehr peinlich hier..

Aber der USB 3.0 ist nicht lahm. Der macht so 300MB/s.
https://forums.raspberrypi.com/viewtopic.php?t=307769#p1841923

NAS mit Festplatte am USB macht 105MB/s lesend. Über 1Gbit Ethernet, was 
hier der begrenzende Faktor ist.
https://www.elefacts.de/test-107-raspberry_pi_4_b_mit_4_gb_ram_als_kleines_und_schnelles_nas