Nubert Lautsprecher, HiFi- und Surround-Elektronik

Hallo,

Frank Klemm hat geschrieben:Die Audio-Task kommt nach jedem Hardwareinterrupt der Soundkarte
dran und gibt, wenn sie nichts mehr zu tun hat, die Rechenzeit ab.
Macht z.B. ASIO so.

Der Interrupt nützt natürlich nicht viel, wenn der Kernel selber nicht preemtive ist.
Was ist denn ASIO? Sone Art asynchrones IO unter Windows?

Weiterhin empfinde ich die Scheduler der üblichen Betriebssysteme
ziemlich altertümlich.

Naja ich finde den Scheduler bei 2.6 schon einen erheblichen Fortschritt, grade auch bei sehr vielen Prozessen auf einer Maschine. Gut das betrifft eher meinen Arbeitsbereich als die Geschichte hier.

Probleme lauern wo ganz anders. Zum Beispiel kenne ich keine
einzige Echtzeitimplementierung eines Dateisystems. Zum Beispiel
habe ich einen Dateihandle zu einer Datei, und ich möchte immer
24 Kbyte/s aus dieser Datei lesen, egal, was andere Prozesse
machen.

Probier mal tmpfs aus, das sollte recht fix sein.

Linux hat da z.B. sehr ernsthafte
Probleme mit FAT32. 24 kByte/s sind ein Problem selbst auf Platten,
die eigentlich 30...40 MByte/s schaffen.

Das kann verschiedene Ursachen haben. Die komische Linkliste bei FAT skaliert auch nicht wirklich.

Generell sind die ganzen Treiber eher selten auf Echtzeitbedingungen ausgerichtet, deswegen auch mein Einwand bezüglich RTOS.

Cu,
Stefan

teite hat geschrieben:

Frank Klemm hat geschrieben: Die Audio-Task kommt nach jedem Hardwareinterrupt der Soundkarte
dran und gibt, wenn sie nichts mehr zu tun hat, die Rechenzeit ab.
Macht z.B. ASIO so.

Der Interrupt nützt natürlich nicht viel, wenn der Kernel selber nicht preemtive ist. Was ist denn ASIO? Sone Art asynchrones IO unter Windows? ;)

Audio Stream Input Output. Von Steinberg Media Technologies.

Der Scheduler ist uninteressant. Die Echtzeitverarbeitung findet
nicht in einer Applikation, sondern im Kartentreiber statt.
Übliche Latenzzeiten über AD-DA liegen bei 1,5 ms bis 5 ms,
wobei einiges davon die AD- und DA-Wandlung verursacht.

Ich will ja nichts sagen, aber bevor mal über Echtzeit den ...

Weiterhin empfinde ich die Scheduler der üblichen Betriebssysteme
ziemlich altertümlich.

Naja ich finde den Scheduler bei 2.6 schon einen erheblichen Fortschritt, grade auch bei sehr vielen Prozessen auf einer Maschine. Gut das betrifft eher meinen Arbeitsbereich als die Geschichte hier. ;)[/quote]
Der 2.6er hat endlich einen Scheduler auf Windows NT-Niveau.
Insgesamt sind aber beide Scheduler um den Faktor 1000
vom technisch Machbaren entfernt, wenn es um präzise
Zeitabläufe geht.

Probleme lauern wo ganz anders. Zum Beispiel kenne ich keine
einzige Echtzeitimplementierung eines Dateisystems. Zum Beispiel
habe ich einen Dateihandle zu einer Datei, und ich möchte immer
24 Kbyte/s aus dieser Datei lesen, egal, was andere Prozesse
machen.

Linux hat da z.B. sehr ernsthafte
Probleme mit FAT32. 24 kByte/s sind ein Problem selbst auf Platten,
die eigentlich 30...40 MByte/s schaffen.

Das kann verschiedene Ursachen haben. Die komische Linkliste bei FAT skaliert auch nicht wirklich.[/quote]
Solange ich die Datei sequentiell lese, spielt das ganze keine Rolle.
Positionieren in riesigen Dateien ist bei FAT etwas tricky, wenn
es O(ld(x)) statt O(1) sein soll.

Generell sind die ganzen Treiber eher selten auf Echtzeitbedingungen ausgerichtet, deswegen auch mein Einwand bezüglich RTOS.

Professionelle Karten kannst Du ohne entsprechende Treiber gar nicht verkaufen. Sieh' Dir mal Tests in der C't von etwas höherwertigen Soundkarten an. Dort wurde teilweise die Latenzzeit der Treiber
angegeben.

Insgesamt kann ich mich mit einem funktionierenden Treiber
auf der mitgelieferten Treiber-CD mehr anfreunden als mit
einem nicht existierenden unter QNX oder einem vollständig
fehlenden Audio-Interface unter VxWorks.

Weiterhin hast Du unter allen Betriebssystemen das Problem,
daß schlechte Treiber oder schlechte Hardware Dir die
Echtzeitfähigkeit versauen kann.

Und zu guter letzt muß auch die Echtzeit-Applikation so aufgebaut
sein, daß die zu lösenden Aufgaben machbar sind. Auch das ist
bei komplexen Applikationen nicht trivial.

Hallo,

Frank Klemm hat geschrieben:Der Scheduler ist uninteressant. Die Echtzeitverarbeitung findet
nicht in einer Applikation, sondern im Kartentreiber statt.

Und damit im Kernel.

Insgesamt kann ich mich mit einem funktionierenden Treiber
auf der mitgelieferten Treiber-CD mehr anfreunden als mit
einem nicht existierenden unter QNX oder einem vollständig
fehlenden Audio-Interface unter VxWorks.

Hihi ich geb mich geschlagen, und bin dann mal auf die Realisierung gespannt.

Hast du vor die Software-Applikation so zu schreiben, das man definierte Streams bzw. Schnittstellen hat, wo man seine Filtermodule einhängen kann? Der Audiostream muss ja verschiedene Phasen durchlaufen, wo man dann geeignete Hooks braucht.

Cu,
Stefan

g.vogt hat geschrieben:Hallo Chip,

*-chipmunk-* hat geschrieben:(pentium 60 oder so)

Schlechtes Beispiel. Es geht das Gerücht um, dass sich insbesondere der pentium 66 derart aufgeheizt habe, dass sich der Sockel regelrecht ausgelötet hat (insbesondere, wenn der 40mm-Kühler "endlich" stehengeblieben ist)
Alte CPU heißt ja nicht zwangsläufig geringer Stromverbrauch und für eine verkaufbare Lösung bräuchte es auch entsprechend zuverlässig auch über einen längeren Zeitraum erhältliche Bauteile.

Mit internetten Grüßen
Gerald Vogt

Der besagte Pentium 60 hatte eine Verlustleistung von ca 25W was lächerlich wenig ist zu heutigen CPUs. Aber es gibt am Markt so genannte Ultra Low Power CPUs, deren Leistung als der ersten Pentium 4 oder Athlon XP Generation ist. Die Verlustleistung liegt zwischen 25-35W, zudem verfügen sie über ausgeklügelte Stromsparfunktionen und passen die Geschwindigkeit und Spannung nach der geforderten Rechenleistung an.
Der Preis solcher CPUs liegt bei bei ca. 200€ am Retailmarkt.

burki hat geschrieben:Hi Frank,
mir ist schon klar, was Du moechtest, doch frage einfach mal Hr. Nubert warum seine aelteren DSP-Boxen nicht den Sprung ins Sortiment fanden und warum nicht schon laengst z.B. das DBA-System in den Regalen steht ?
Ein Studio kauft sich dann halt eine handvoll von FIR-Controllern bei K+H (bzw. einer renommierten Firma) oder gleich die O500C.
Der "kleine" Homeanwender dagegen versteht nicht den Vorteil, wenn er sich eh schon einen AVR mit "Einmesssystem" gekauft hat ...
Ich sehe im Homebereich fuer solch ein Geraet keine grossen Chancen (mach mal wirklich eine handfeste Kalkulation) auf dem Markt.
Etwas anders waere es, wenn der Kontroller in einer modularen Vorstufe integriert waere und deshalb mein obiger Einwand.
Gruss
Burkhardt

Ein solches Gerät hat durchaus sehr gute Martkchancen, es ist schlicht und einfach eine Marketingsache. Man muss sich nur mal eine kurzen Überblick machen was in den Testzeitschriften hochgejubelt wird. Es sind immer monströse Endstufen möglichst Monoblocks, Vorstufen mit unzähligen Features und Updateversprechen, die jedoch mit einem vernünftigen Bassmangement oder Akustikanpassung nichts zu tun haben, Externe DA Wandler für CD Player usw. ...

Den Leuten wird suggeriert, dass man für alles einen teuren Spezialisten braucht und das braucht Zeit um es zu ändern.
Generell ist der Markt jedoch da für so ein System, der Markt verlangt immer mehr für weniger Geld und alleine die Wohnintegration in einem 0815 Haushalt wäre um ein vielfaches besser.