Hallo Leute, ich möchte einen eigene DJ-Player entwickeln. So ähnlich bei zB ein Pioneer XDJ oder CDJ. Ich habe bereits einen Prototypen, wo jedoch die DJ-Software auf einem Raspberry Pi läuft. Nun frage ich mich wie ich einen RPI professionell ersetzen kann. Also, was zB Pioneer für einen PC in ihren DJ-Produkten verwendet. Stellen sie diese selbst her? Wie nennt man solche PCs, kann man die kaufen (Industrie PCs?)? Ich kenne noch das Up-Squared Board, was eine Art RPI aus Steroide ist, oder natürlich so NUC PCs von Intel. Aber ich suche wie gesagt nach einer besseren Lösung bzw. nach einer professionellen Lösung, ähnlich wie es zB Pioneer macht. Am besten wäre es natürlich wenn auf dem PC am Ende Linux drauf laufen könnte. Ich hoffe Ihr könnt mir weiterhelfen, kenne mich nicht gut mit so etwas aus. LG NIMANS :)
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.
:
Bearbeitet durch User
Was du suchst ist ein Single Board Computer (SBC) beziehungsweise System on Module (SoM). Auch den Raspberry Pi gibt es als solches Modul zum Einsatz auf eigenen Leiterplatten (Raspberry Pi Compute Module). Die Raspberry Pi CM sind eigentlich ziemlich gut skalierbar, wenn dir die Rechenleistung vom größten nicht ausreicht, wirst du für eine ausreichende Alternative denke ich ziemlich tief in die Tasche greifen müssen, wenn du nicht in der Lage bist ein solches Embedded System selbst zu entwickeln.
Würde sagen mein Gerät wird viel weniger können, aber ich habe halt momentan alles auf einem einzelnen RPI laufen. Also Betriebssystem, Software, Display, DAC... Also entweder ich teile das auch auf, aber da müsste ich mich mal informieren wie so etwas geht, denn momentan kann ich das noch nicht oder ich hole mir einen stärkeren PC der alles gleichzeitig machen kann.
Diese RPI CMs sind ja nichts anderes als die normalen RPIs nur flach gebaut(?). Habe einen RPI 4 mit 8 GB Ram und der war auch zu schwach, aber ich denke vom Prozessor aus. Tiefer in die Tasche zu greifen wäre kein Problem, hätte aber ein Preislimit bei 300 Euro, wenn es geht viel lieber bei maximal 200 Euro.
Niklas T. schrieb: > Diese RPI CMs sind ja nichts anderes als die normalen RPIs nur flach > gebaut(?). Wenn das Dein Niveau der Marktanalyse ist... > Habe einen RPI 4 mit 8 GB Ram und der war auch zu schwach, > aber ich denke vom Prozessor aus. Denken und Glauben ist Mist: Wenn Du einen vollstaendiges Linux am Laufen hast, kannst Du mit Top & Co. schon gucken, wo die Rechenleistungen verbraten wird. Denn mit 4 x 1.5GHz hast Du schon richtig Ompf auf der Platine. >Tiefer in die Tasche zu greifen wäre > kein Problem, hätte aber ein Preislimit bei 300 Euro, wenn es geht viel > lieber bei maximal 200 Euro. Vielleicht ist Dein Konzept verbesserungsfaehig, z.B. kein Betriebssystem sondern bare Metal. Aber Du weisst schon, dass z.B. Pioneer mehrere Ingenieure beschaeftigt und dass sind nicht nur Marketing-Leute. Gruesse Th.
Niklas T. schrieb: > Ich habe bereits einen Prototypen, wo jedoch die DJ-Software auf einem > Raspberry Pi läuft. > Nun frage ich mich wie ich einen RPI professionell ersetzen kann. > Also, was zB Pioneer für einen PC in ihren DJ-Produkten verwendet. > Stellen sie diese selbst her? > Wie nennt man solche PCs, kann man die kaufen (Industrie PCs?)? Du darfst den Rapsberry Pi auch dafür einsetzen, wenn er deinen Anforderungen genügt. Und da harkt es leider häufig. Das geht bei der SD-Karte los und hört bei der Langzeitverfügbarkeit auf. Ansonsten schau dir mini-ITX-Boards an. Die gibt es in allen möglichen Geschmacksrichtungen. Sonst gäbe es natürlich echte Boards für Embedded in allen Geschmacksrichtungen. Beispiel: https://www.congatec.com/de/congatec/pressemitteilungen/article/neues-congatec-com-express-computer-on-module-mit-3-ghz-intelr-coretm-i3-prozessor/
Niklas T. schrieb: > Habe einen RPI 4 mit 8 GB Ram und der war auch zu schwach, Erzähle etwas mehr über deine Software. Was genau machst du da, welche Sprache verwendest du? Ich mag nicht so richtig glauben, dass der Pi mit ein paar Audio Effekten am Anschlag ist.
Andre schrieb: > Erzähle etwas mehr über deine Software. Was genau machst du da, welche > Sprache verwendest du? Ich mag nicht so richtig glauben, dass der Pi mit > ein paar Audio Effekten am Anschlag ist. Ich benutzte lediglich die OpenSource Software Mixxx. Aber sobald ich zwei Songs gleichzeitig manipuliere fing es immer an zu haken. Und in den Systemanforderungen steht, dass man mindesten 2 Ghz benötigt
Niklas T. schrieb: > Ich benutzte lediglich die OpenSource Software Mixxx. Das ist ein QT6-Prograemmchen. Qt6 ist nicht bekannt fuer sparsame Programmierung. > Aber sobald ich zwei Songs gleichzeitig manipuliere fing es immer an zu > haken. Dann fehlt Dir ein leistungsfaehiger Massenspeicher, und nein, eine SD-Karte ist weder Masse noch Leistungsfaehig. -> Suche Dir einen NUC oder Industrie-PC. Gruesse Th.
Im professionellen embedded Bereich verwendet man für sowas gerne COM, also computer-on-module. Ich weiß nicht wie deine sonstige Hardware aussieht, kann sein, dass allein das zu entwerfende Carrierboard den Aufwand sprengt. Anschauen kannst du es dir aber ja mal: https://www.aaronn.de/produkte/board-level/computer-on-modules/
Mit Mixxx 2.3.0 soll erst Multicore Nutzung und ein erheblicher Geschwindigkeitsboost gekommen sein.
Burps schrieb: > und hört bei der Langzeitverfügbarkeit auf. Ach her je. Schon mal über die Langzeitverfügbarkeit von Schrauben oder sonstigen Halbzeugen nachgedacht? Das ist der Teil den hier viele nicht kapieren: Software schreibt man gegen ein vernünftiges Universal-Betriebssystem in einer Hochsprache und sucht sich ein Board mit genügend Rechenpower aus. Wenn ein Raspi nicht reicht nimmt man halt irgendwas mit einem AMD oder Intel-Prozessor. Und welches Board in zwei Jahren eingebaut wird, interessiert heute nicht die Bohne. Denn dank Hochsprache und Betriebssystem spielt die konkrete Hardware einfach keine Rolle mehr. Spezialisierte Hardware interessiert nur für echte Massenproduktion. Und wenn man doch irgendeine Spezial-Hardware benötigt, hält man den Teil so klein wie nur irgendwie möglich und bindet den über USB oder Ethernet an.
Einer schrieb: > Denn dank Hochsprache und > Betriebssystem spielt die konkrete Hardware einfach keine Rolle mehr. > Spezialisierte Hardware interessiert nur für echte Massenproduktion. Gerade anders herum. Ich mache Kleinststückzahlen, extreme Sonderentwicklungen nach Kundenwunsch, meist für Luftfahrt und da ist Langzeitverfügbarkeit DAS Ding. Denn alle Arbeiten, alle Tests, jede Änderung und sei sie noch so klein muss komplett neu durch die Zulassungen, mit allen Papieren und gigantischen Aufwand. Und das verteilt sich dann auf z.B. 6 Geräte. Je kleiner die Stückzahl um so härter haut das auf den Gerätepreis durch. Bei 100K Stk./Jahr ist sind mir 100K für ein Redesign egal. Wenn es dann danach 2€ billiger zu bauen ist, habe ich sogar 100K durch das Redesign verdient als Hersteller. Bei 10 Geräten tut das richtig weh, denn der Kunde sieht nicht ein das zwei mal zu bezahlen.
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.
Sebastian R. schrieb: > 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. Aber was macht Mixxx denn mehr als die DJ Funkion? Also abgesehen dass was ein CDJ in Hardware macht. Meinst du, ich soll ein Programm entwickeln, welches nicht extra auf einem Betriebssystem laufen muss?? --> ist das so einfach? Oder bestimmte Funktionen auf die Hardware bringen und dann ein ganz einfaches DJ Programm suchen/schreiben.
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.
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 ja, gibt es noch mehrere OS wie zB OpenWRT die genau für sowas gemacht sind?
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
Ja die zwei kenne ich bereits und habe ich ausprobiert, aber trzd funktioniert es nicht immer einwandfrei. Beschreibt er auch in seinem Repo
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.
Niklas T. schrieb: > ich möchte einen eigene DJ-Player entwickeln. So ähnlich bei zB ein > Pioneer XDJ oder CDJ. Super viel Erfolg > Am besten wäre es natürlich wenn auf dem PC am Ende Linux drauf laufen > könnte. > > Ich hoffe Ihr könnt mir weiterhelfen, kenne mich nicht gut mit so etwas > aus. Evtl. einen Thinkcentre Tiny (Kann man auch aus dem Gehäuse nehmen). Gibt es gebraucht, haben massig Power und Linux läuft wohl auch drauf.
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
Der Raspi ist wohl etwas lahm, was Massenspeicher angeht. Mit den 8GB kannst du es mal mit einer Ramdisk versuchen.
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.
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
Markus M. schrieb: > Bei dieser Art von Hardware geht > es hauptsächlich um ein latenzarmes Verhalten. Netter Vergleich: Ich hatte gerade eine ISP bedingte Netzwerkstörung. Super geile Datentransferraten im Up und Download, aber VIOP,Teams oder Fernwartung war nahezu unmöglich. (Doof mit Festnetz über IP only) Auch Whatsapp Tel im Wlan war betroffen. 50Mbit down, 5mbit up, reichen nicht für 8Khz packenden Sprachcodec? Tja, wenn die Ping Zeiten zwischen 20ms und 2s liegen, werden eben eine Menge Pakete verworfen, weil ich die Daten entweder rechtzeitig bekomme oder dann auch nicht mehr brauche. Das Ohr ist schon ein extrem anspruchsvolles Organ. Störungen, Jitter, Laufzeitunterschiede,Echos die man nur mit erheblichen Aufwand gemessen bekommt aber die im Höreindruck ganz erheblich störend wirken. Irgendwie schwammig, dumpf, kratzig, verzerrt ... Man greift zu völlig bekloppten Beschreibungen weil man es einfach nicht besser ausdrücken kann und auf dem Oszi sieht es eigentlich toll aus. So bald ein OS ins Spiel kommt ist meist vorbei mit exaktem Timing. Dann hilft nur noch HW die absurd übertrieben Power hat und SW Skills vor denen ich neidlos den Hut ziehe. Oder eben auf bescheidener HW bare metal und hartes Timing und GUI völlig von einander Trennen.
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.
Rolf M. schrieb: > Mit anderen Worten: Nur die Steuerung wird in Python gemacht. Die > eigentliche Verarbeitung ist gar nicht darin implementiert. Εrnst B. schrieb: > Vor allem die Info, ob die Bewegungserkennung wirklich in Python > implementiert ist, oder ob das Python da nur als "Klebstoff" zwischen > div. Bibliotheksfunktionen dient. Hat er doch ganz deutlich geschrieben. Ein T. schrieb: > 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.
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... ;-)
Lesen gelernt? Ich beziehe mich auf die lahme USB-Technik im Raspi. Siehe Link..
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.
Es schreibt weiter in Rätseln.. Lahmer Raspi-USB bleibt nunmal lahmer Raspi-USB. Wird langsam seeeeehr peinlich hier..
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?
Jojo, Ethernet und der ganze andere Krempel über USB.. und auch noch frech werden.. o&o
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.