Lautstärkeabhängiger Input-EQ - wer kann es?

Nun, in dem Thread ging es ja eigentlich um simples dynamisches Filtern - das war zumindest der Stand des Zitats.
Weiß auch nicht wer dann mit komplexen Systemen und unmöglich angefangen hat ;-)

VG Frank
 
Die Aussage "unmöglich" stimmt doch auch noch, in deinen Ausführungen manipulierst du das Ausgangssignal. Ich vermute mal dies müsste dann auch noch Hersteller/Modell/Ausstattungsabhängig customized werden?
Ein universales "Herausmessen und Korrigieren" mit einem "simplen System", wenn das Signal nur als Eingang für den Prozessor vorliegt, ist in der Praxis nicht möglich.
 
Verstehe eh nicht warum man Signale von der Headunit verwendet ???
Ich verwende einen Raspberry PI als Hotspot / SPDIF Ausgang. mit Tiny Core Linux und MPD-Server, darauf ein große FLAC -Sammlung gespeichert.
Mit meinem Android Handy wird dann alles mit WLAN und Bluetooth gesteuert, voll einfach und easy
Für mich die beste Klangqualität
 
Die Aussage "unmöglich" stimmt doch auch noch, in deinen Ausführungen manipulierst du das Ausgangssignal. Ich vermute mal dies müsste dann auch noch Hersteller/Modell/Ausstattungsabhängig customized werden?
Ein universales "Herausmessen und Korrigieren" mit einem "simplen System", wenn das Signal nur als Eingang für den Prozessor vorliegt, ist in der Praxis nicht möglich.
Wenn man es sich selber genügend schwierig macht, dann wird es irgendwann unmöglich, da hast Du recht.
Eine zusätzliche Schnittstelle für Daten war allerdings schon in meinem ersten Post dazu vorausgesetzt.

VG Frank
 
Verstehe eh nicht warum man Signale von der Headunit verwendet ???
Ich verwende einen Raspberry PI als Hotspot / SPDIF Ausgang. mit Tiny Core Linux und MPD-Server, darauf ein große FLAC -Sammlung gespeichert.
Mit meinem Android Handy wird dann alles mit WLAN und Bluetooth gesteuert, voll einfach und easy
Für mich die beste Klangqualität
Verstehe ich schon. Streaming, Freisprechen, Navi-Ansagen, YouTube bzw. Videos, Podcasts, Warntöne, Dashcam? Dazu eben die bessere Bedienung, Lenkradtasten, etc. Ein Handy ist schon sehr minimalistisch. Hatte ich Jahre so, jetzt n Dudu. Dudu gewinnt für mich um Längen.
 
Ja, man kann das bestimmt alles entsprechend manipulieren und codieren, das will ich nicht in Abrede stellen und wenn eh alles Standard und dokumentiert ist umso besser.
Ich vermute jedoch die wenigsten hätte unter "einer externe Regelgrösse" einen entsprechenden Adapter und Codierung o.ä. vermutet mit aktivem Eingriff in die Fahrzeugelektronik. Ich glaube es freuen sich alle, wenn so etwas verfügbar käme aber es ist eher eine hochindividuelle Sonderanfertigung als ein fertiges Massenprodukt im Sinne "welcher Prozessor kann das?" was du beschrieben hast.

Weitermachen und gerne zeigen was geht. Je universaler desto gut.
 
Die guten/hochbegabten Absolventen sitzen im Silicon Valley und basteln für 500.000+ an KI und autonomen Fahren.
Ich mache Car Audio, daher trifft die Einschätzung wohl ganz gut zu - wie auf viele meiner Kollegen in der Branche.

Das zu Wissen ist schonmal der erste Schritt diese Problemstellung anzugehen.
Sowohl OEM als Aftermarket bedienen sich standarisierter, breit bekannter und dokumentierter Technik. Niemand erfindet hier das Rad neu.

Konkret:
Alle mir bekannten OEM Verstärker in Burmester Systemen basieren auf ADSP Shark (ARM, die günstigen 450MHz 218x) als DSP und Atmel ATS (auch ARM) als MCU.
Kommunikation zum Fahrzeug bewährt via CAN, Onbord via SPI. Bei bisher allen Verstärkern waren alle nötigen Schnittstellen inkl. Standard ARM Jtag 2x7 auf dem PCB vorhanden und müssen nur mit Pinheadern bestückt werden.
ARM / SPI / CAN - alles offene Bücher, GitHub ist voll von Tools und debugging Hardware gibt es direkt von AD und Microchip bei Mouser & Co. CrossCore und VisualDSP sind auch keine Raketenwissenschaft.
So ergeben sich mehrere Möglichkeiten mit aufsteigendem Level:
1. Codierung des Fahrzeugs.

.... wenn das nicht geht:

2. Dem dynamischen System die Verbindung zu Fahrzeugdaten kappen und dadurch statisch machen (oder zumindest Komplexität nehmen). Ein simpler Pi als CAN Gateway kann Drehzahl, Fahrstufe, Fahrmodi etc. rausfiltern und statische Daten vorgaukeln. Tools dafür -> GitHub.

.... da vermutlich nicht alle Daten gekappt werden dürfen:

3. Die Parametrierung des Shark durch die MCU (SPI) ebenfalls über ein Gateway filtern. So darf die MBux die Geschwindigkeit wissen, der ADSP aber nicht.

.... für den unwahrscheinlichen Fall das es bis hier nicht reicht stellt

4. Analog Devices JTag und DMA samt Hardware, Dokumentation und Support in der Engineer Zone zur Verfügung. Mit Verweis auf den ersten Satz erwarte ich im ADSP nichts cryptisches, verschlüsseltes oder gegen Zugriff geschütztes.

Aus meiner Erfahrung ist man mit (2.) vermutlich schon am Ziel. Punkt (3.) habe ich mal rein aus Neugierde gemacht um zu sehen was geht. Bei (4.) müsste ich mich reinfressen und wäre wohl auf OpenAI angewiesen. Keine Schande, denn nirgendwo habe ich von "kein Problem" gesprochen. Mit "sportlich" meint der Rheinländer: Aufwändig/herausfordernd - mag sein das das nicht überall so gedeutet wird. "Unmöglich" wurde im ersten Semester aus meinem Wortschatz gestrichen.

VG Frank

Hi

Du solltest da Deinen Kenntnisstand mal up to date halten was die Prozessoren ect betrifft.
 
Zurück
Oben Unten