Moin! Ich habe für ein Studienprojekt einen Raspberry Pi mit Simulink zu einem Effektpedal für meine E-Gitarre verwandelt. Es funktioniert alles tadellos. Das ganze hat ein Display bekommen, ein hübsches Gehäuse und via Drehimpulsgeber kann ich die Parameter einstellen. Allerdings ist da diese Latenz! Ich weiß, dass der Pi nicht so viele Mukkies hat. Kann es aber dennoch sein, dass der Flaschenhals am Ethernet-Buffer liegt? Irgendwie habe ich das Gefühl, dass aufgrund der Anbindungspflicht an meinem PC er die Daten an den PC schickt, dort berechnet und das Ergebnis dann wieder an dem Pi weiter gibt. Hat jemand eine Idee, wie man ohne Kompilierung des Programms in C den Pi vom Ethernet trennt? Gruß, Amadeus
Du könntest mit einem Netzwerksniffer deine Theorie überprüfen, wenn er alles an den PC schickt sollte das ja bemerkbare Trafficmengen erzeugen. Die Herstellerwebseite klingt nicht so als ob es so wäre, aber wer weiß.
Hi, > > Allerdings ist da diese Latenz! > > Ich weiß, dass der Pi nicht so viele Mukkies hat. Kann es aber dennoch > sein, dass der Flaschenhals am Ethernet-Buffer liegt? Irgendwie habe ich > das Gefühl, dass aufgrund der Anbindungspflicht an meinem PC er die > Daten an den PC schickt, dort berechnet und das Ergebnis dann wieder an > dem Pi weiter gibt. > Typischerweise bäckt Simulink schon den Code für das Target, also den ARM auf dem R'Pi. Dass Simulink noch eine Verbindung möchte, hat wohl mit deiner Lizenzvariante zu tun... > Hat jemand eine Idee, wie man ohne Kompilierung des Programms in C den > Pi vom Ethernet trennt? > Ausser Selberschreiben der ganzen Filterpipeline: Nein. Die Latenz kommt sehrwahrscheinlich von der internen Verarbeitungskette von Simulink. Von einer anderen Architektur weiss ich, dass die Codegeneration nicht gerade auf Effizienz ausgelegt ist und an Latenz dabei schon gar nicht gedacht wurde. Ich vermute mal, dass für jede Stufen deiner Verarbeitungspipeline Buffer-Queues angelegt werden. Da kannst Du höchstens mal versuchen, ob Du an diesen Parametern drehen kannst (kleinere Buffer). Du kannst ja mal messen, wie die Latenz abnimmt, wenn Du einen Filter bypasst. Wäre interessant. Grüsse, - Strubi
Moin! Vielen Dank für die Antworten! Ich habe mir jetzt probehalber einen Pi 2 bestellt. Da er 6 mal schneller sein soll, würde die Latenz theoretisch abnehmen. Das irrsinnige daran ist ja, dass selbst im Bypass die Latenz fast identisch groß bleibt. Da ich allerdings alle Buffer die ich finden konnte so klein wie möglich realisiert habe, wundere ich mich, dass selbst dies keinen Effekt auf die Latenz hatte. Daher kam ich überhaupt auf die Idee, dass es ein Ethernet Buffer sein könnte, auf den ich keinen Einfluss habe. Das wäre auch der schmalste Flaschenhals, der mir einfiel. Ich verwende Parallel nämlich am USB-Port eine billige Soundkarte. Beides hängt im Pi leider am gleichen Hub. Ich werde dann mal die Tage schauen, wie ich am besten die Daten über Lan sniffen kann. Gruß, Amadeus
Hi, > > Ich habe mir jetzt probehalber einen Pi 2 bestellt. Da er 6 mal > schneller sein soll, würde die Latenz theoretisch abnehmen. > Das würde ich mal eher für unwahrscheinlich halten, die CPU-Last macht typischerweise nicht die Latenz aus, nur die Pufferung. > Das irrsinnige daran ist ja, dass selbst im Bypass die Latenz fast > identisch groß bleibt. Da ich allerdings alle Buffer die ich finden > konnte so klein wie möglich realisiert habe, wundere ich mich, dass > selbst dies keinen Effekt auf die Latenz hatte. > Daher kam ich überhaupt auf die Idee, dass es ein Ethernet Buffer sein > könnte, auf den ich keinen Einfluss habe. Das wäre auch der schmalste > Flaschenhals, der mir einfiel. Ich verwende Parallel nämlich am USB-Port > eine billige Soundkarte. Beides hängt im Pi leider am gleichen Hub. > > Ich werde dann mal die Tage schauen, wie ich am besten die Daten über > Lan sniffen kann. > Schneller Tip: Wireshark und libpcap (wenn unter Windows). Kann mir aber kaum vorstellen, dass die Daten zweimal durchs Ethernet gehen. Da wäre der ganze Aufbau irgendwie absurd, mit netten Nebeneffekten wie Jitter, usw. Um die auszugleichen, bräuchte es natürlich einen grösseren Puffer (ergo Latenz). So 'braindead' sollte Simulink nicht sein...
Moin! Wireshark hat tatsächlich nichts Auffälliges ergeben. Zwar werden regelmäßig Pakete versendet, die sind aber recht klein für den steten Betrieb. Ich habe einen Hinweis im Matlab Forum erhalten, dass der Buffer fest eingestellt sei und man dies in der MW_alsa_audio.c ändern könnte. Von Matlab/Simulink aus kann man das leider nicht tun. Leider finde ich diese Datei nicht. Die Linux Distri von Matlab für den Pi scheint da sehr zugriffsgeschützt zu sein. Hat da jemand eine Idee? Gruß, Amadeus
Es würde mich ziemlich wundern, wenn du auf dem Raspberry Pi mit Simulink brauchbare Latenzen (<<100ms) hinbekommen würdest. Unter http://wiki.linuxaudio.org/wiki/raspberrypi gibt's ein paar allgemeine Tips für low latency Audio auf dem Raspberry Pi, anscheinend ist das aber auch ohne Simulink schon schwierig genug. Das Problem ist dabei nicht die Rechenleistung, sondern die Audiotreiber und allgemein die fehlende Echtzeitfähigkeit von Linux.
:
Bearbeitet durch Admin
Hi! Vielen Dank für den Link! Leider kannte ich den schon und habe schon einiges mit dem Pi herum gespielt. Mir ist bewusst, dass dies unter Linux ein Problem darstellt. Daher wollte ich direkt an den Treiber ran, um den fest eingestellten Buffer zu verringern. Unter 100ms wäre ein Traum. Hm... ich schau mir mal die ALSA Geschichte mal genauer an. Vielleicht ergibt sich da was. Danke! Gruß, Amadeus
Moin, Echtzeit ist bei neueren Linuxkernels nicht das Problem, ausserdem bewegen sich da die Latenzen der Antwortzeiten von Prozessen auf eintreffende Daten im Bereich von wenigen ms, und das auch mit sehr geringem Jitter. Mit etwas Konfiguration habe ich auf dem Blackfin um die 80us garantierte Latenz hinbekommen. Hängt im Detail von der Treiberarchitektur ab, aber auch da kommen typischerweise im Kernel keine 5ms zustande. Ich vermute mal, dass bei diesen Simulink-Hacks eine Menge Layer (Jack? Matlab-Bufferqueues?) dazwischensitzen. Schau doch mal, ob Du über die BUffer in der Alsa-Queue was herausbekommst, die lassen sich auch konfigurieren.
Amadeus schrieb: > Ich weiß, dass der Pi nicht so viele Mukkies hat. Selbst DSPs mit 30MHz wie der alte ADSP2181 haben mehr als genug "Mukkis" für solch einen Filter. Offensichtlich vertrödelt der Rpi seine Zeit an einer anderen Stelle.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.