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.
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.
