Seite 2 von 2

Verfasst: 16.01.2005 11:26
von Froggerprogger
@Hroudtwolf
Jeglicher Soundoutput ist gepuffert. Du füllst also einen Speicherbereich fester Größer mit deinen Sounddaten (RAW PCM) z.B. mit einer Sinuswelle und übergibst diesen dann an den Treiber, bzw. meist ist es andersherum, DirectX/fmod, etc. rufen eine Callback-funktion von dir auf, übergeben dieser einen Pointer auf einen Buffer und dessen Länge, Du kannst darin beliebiges Zeug reinschreiben, und wenn die Funktion beendet wurde, kümmert sich der Treiber darum, diesen Buffer nahtlos an den vorher abgespielten an die Soundkarte zu übertragen.
Dazu findest Du hier einige Beispiele, die zwar fmod nutzen, aber das Buffer-befüllen ist wohl überall dasselbe. http://fmod.2mal2mal.de , dort insbesondere SineMouse als das einfachste. Aber auch Danilos oben erwähntes Beispiel nutzt einen solchen Buffer. Wenn man da übrigens einfach Zufallswerte reinschreibt, gibt es ein lautes Rauschen.

@traumatic
weitere Fragen:
a) dann greifen also die WinMM-Funktion intern nicht auf DirectX zu, weswegen WinMM dann auch auf Windows-Rechnern ohne DirectX läuft ?
b) Was ist mit MCI-commands? Sind das einfach nur 'Wrapperfunktionen' für kompliziertere WinMM-Befehle ? Oder haben die wiederum einen eigenen Treiber ? Oder greifen die auf DirectSound zu ?
c) Mit MCI kann man ja ohne weiteres sämtliche Formate abspielen, für die Treiber auf dem Anwenderrechner installiert sind (selbst MIDI und Videos). Gilt selbiges für WinMM (Vermutung: wohl nicht. Demnach wäre MCI ggf. (wenn b zutrifft) ein WinMM vorgeschaltetes Interface, welches sich zusätzlich um die Konvertierung von Fremdformaten kümmert).
d) Bietet DirectX direktes MP3/Ogg-Abspielen, bzw. sämtliche anderen installierten Formate ?
e) ASIO-Treiber ermöglichen ja enorm geringe Latenz- und Reaktionszeiten. (Sowohl beim IN->OUT, als auch generell beim Abspielen durch kleine Buffer), und setzen sogar Hardwareanforderungen an die Soundkarte, weswegen nicht jede Karte ASIO kann. Aber ist ASIO - sofern vorhanden - für den Programmierer auch 'nur' eine API, der man Buffer zusenden kann ?
f) Verfolgt WDM denselben Ansatz wie ASIO ? Oder ist WDM eine Erweiterung davon? Oder ganz woanders für gedacht ?
g) Danke! :allright:

@DarkDragon
Auch jau, OpenAL gibt es ja auch noch!

Verfasst: 16.01.2005 18:01
von traumatic
Froggerprogger hat geschrieben: a) dann greifen also die WinMM-Funktion intern nicht auf DirectX zu, weswegen WinMM dann auch auf Windows-Rechnern ohne DirectX läuft ?
Ja.
b) Was ist mit MCI-commands? Sind das einfach nur 'Wrapperfunktionen' für kompliziertere WinMM-Befehle ? Oder haben die wiederum einen eigenen Treiber ? Oder greifen die auf DirectSound zu ?
Die MCI-Commands sind ebenso ein Teil der winmm.dll.
c) Mit MCI kann man ja ohne weiteres sämtliche Formate abspielen, für die Treiber auf dem Anwenderrechner installiert sind (selbst MIDI und Videos). Gilt selbiges für WinMM (Vermutung: wohl nicht. Demnach wäre MCI ggf. (wenn b zutrifft) ein WinMM vorgeschaltetes Interface, welches sich zusätzlich um die Konvertierung von Fremdformaten kümmert).
Keine Konvertierung. Wenn die passenden CoDecs nicht installiert sind,
kann man ja auch nichts abspielen. Mit MCI-Commands werden lediglich
Befehle an MCI-Gerätetreiber geschickt; Was der entsprechende Treiber
oder das Device dann damit macht, ist "seine Sache".
d) Bietet DirectX direktes MP3/Ogg-Abspielen, bzw. sämtliche anderen installierten Formate ?
DirectShow bietet von Haus aus MP3-Support. Ogg-Vorbis oder ähnliches
kann auch wieder nur mittels passendem CoDec abgespielt werden.

Siehe auch PB-Befehl LoadMovie() - ein simpler DirectShow-Wrapper -
je nach installierten CoDecs können die unterschiedlichsten Formate
abgespielt werden - ohne CoDec: himmlische Ruhe...

Sollte man nativ OggVorbis o.ä. abspielen wollen, muss man sich um das
decodieren selbstverständlich selbst kümmern (oder meine ov:Lib benutzen ;))
e) ASIO-Treiber ermöglichen ja enorm geringe Latenz- und Reaktionszeiten. (Sowohl beim IN->OUT, als auch generell beim Abspielen durch kleine Buffer), und setzen sogar Hardwareanforderungen an die Soundkarte, weswegen nicht jede Karte ASIO kann. Aber ist ASIO - sofern vorhanden - für den Programmierer auch 'nur' eine API, der man Buffer zusenden kann ?
AFAIK gibt es ein ASIO-SDK von Steinberg, genauer habe ich mir das jedoch
auch noch nicht angeschaut.
f) Verfolgt WDM denselben Ansatz wie ASIO ? Oder ist WDM eine Erweiterung davon? Oder ganz woanders für gedacht ?
WDM ist kein Soundtreiber per se, sondern eine generelle Verbessung der
Kernel-Mode-Treiberarchitektur von NT. In Zusammenhang mit Echtzeit-
Sound ist WDM deshalb interessant, weil Streaming-Daten mit niedriger
Latenz und hohem Datendurchsatz ermöglicht werden. AFAIK geschieht
das Streaming mit WDM-Treibern auf OS-Ebene und nicht auf Anwendungs-
ebene, wie es vor WDM der Fall war.

Bzgl. WDM kann Dir Rings vielleicht noch genaueres sagen.

Aus eigener Erfahrung kann ich nur berichten, dass die Latenz in meinem
HD-Recordingsystem von ca. 6ms auf 1ms gefallen ist, seitdem ich WDM-
Treiber benutze :)
g) Danke! :allright:
:D

Verfasst: 16.01.2005 18:52
von traumatic
Was mir gerade noch einfällt: OpenAL ist auch nur ein "API um ein API",
unter Windows z.B. wird auch MMSystem oder DirectSound genutzt IIRC.

Verfasst: 15.09.2005 16:12
von inc.
Hatte bzgl. DirectX gesucht und diesen Thread hier auch gefunden, daher das "hoch holen" des Threads.

@ Froggerprogger

Traumatic hats ja bereits gesagt, das MCI Bestandteil der WinMM.dll ist.
Die WinMM.dll sowie die AviFil32.dll sind sozusagen Entkapselungen der ehemaligen vfw.dll. Alle Funktionen/Deklarationen etc. jener beiden Dlls sind z.B. in der vfw.h beschrieben, auf welche sich sehr oft in c++ Audio/Video Applikationen bezogen wird.

Demnach ist MCI eigentlich VideoForWindows basierend und benötigt demnach zum abspielen den entsprechenden vfw codec.
Ich habe viel mit MCI rumprobiert und gemerkt, dass ebenso Dateien via MCI abgespielt werden, für die z.B. lediglich ein Dshow Codec auf dem System installiert ist. Demnach "denke ich" gehen Routinen in der WinMM.dll hin und nutzen bei nicht vorhandenem vfw-Decoder eben Dshow Decoding-Routinen.

Es wäre ein großes "Adding", wenn Fred nicht nur die API der WinMM mit in Purebasic übernimmt, sondern die gesamte vfw API incl. ihrer Deklarationen etc.
Man könnte wunderbar die gesamten AviFileXXX() Befehle direkt ansprechen.