Hi Peter, feels like we are back in the Wasabi discussion ;) I agree with everything you're saying but isn't all of this supported by the DirectShow (here I go again ;) model? If you look to your code today then isn't the capture/render part not an interface to the DS based mixer and the hardware? What if there were high performance and low latency filters available that would provide such interface for you? Everyone seems to do this, Sonar is using WDM/KS and MME for this. Microsoft layers DirectSound on top of WDM/KS and then uses the DirectSound based render filter to provide the interface between DirectShow and the hardware. I think other applications are doing something similar. The common point is the translation from DirectShow to the streaming capabilities of a device or vice versa. The hacks to synchronous start several streams today (both in and out) come from the fact that the hardware driver(s) doesn't know about the relation between them. It assumes that if the devices are opened at roughly the same time then all operations on them should be treated as atomic. DirectShow takes the guesswork out of this because related streams have a common reference clock. It's the driver's job to synchronize correctly to it. This would even work across disimilar hardware, even from different manufacturers. The key here is the timestamping of the "media samples", if done right, everything aligns properly. The buffer management can be taken care of by such a capture/render filter if it supplies a (custom) memory allocator to the application. All necessary buffer information would be available from such an allocator. Sharing is directly controlled by the driver. If it can't handle it, subsequent connects will simply fail. The pins will tell the application exactly what formats they support. All of this can be extended, the host doesn't need to understand all of them. Bit-transparency can be dealt with in these formats also. Samplerate conversion, busing,... can be disabled by the driver if the connection format requires this. So, IMHO, the needed API is already there, it only needs to be implemented correctly. An argument against DirectShow is the complexity. But because DS is extendable using custom interfaces, this complexity can be decreased if not needed by the application. If a connection agrees that it will never change the format during streaming then a simpler interface could be used to increase performance... Best regards, Dirk > -----Original Message----- > From: Peter Haller [mailto:pchaller@xxxxxxxxx] > Sent: Sunday, December 08, 2002 5:55 AM > To: wdmaudiodev@xxxxxxxxxxxxx > Subject: [wdmaudiodev] Re: White Papers now available > > > > Hi Alejandro , > > Latency is introduced by the layers between the hardware and > the host. The > ability to keep the Windows "Play everything always" user > experiance out of > the picture when a host tells it to is important. If it is under host > control, then the user can choose how the host will interact with the > hardware/drivers. > > Work at the device level, not ports of the device. It is > implicit that a > device has ports. This implies having exact knowlege of > channel capabilites > of devices. If a device has 8 mono inputs and 10 mono outputs > I need to know > this. I don't want two sets of apis - one for input and one > for output . > > This will provide synchronous behavior between input and > output on multiport > devices. We currently have to rely on hacks in drivers to > assure that input > and output are started synchronously. I need to > create/define/open/start/stop inputs and outputs atomically. > This _has_ to > be at the driver level to be truely atomic and can't be > wrapped up at user > mode level. > > Example: > > waveOutOpen() + waveInOpen() should be one atomic > audioOpenDevice() call. > > Also keep it simple. No locking of buffers, no setup api to > discover devices > and ports. > > Needed methods: > Enum, Query, Open, Start, Stop, Close > > Simple and would cover 90% of what we (host developers) need to do. We > basically want to stream audio buffers in both directions, > nothing more. > Complexity adds to interpretation, interpretations leads to > inconsitent > behavior. > > Please, no pins and handles to pins and other such architectual/design > overhead. Make it simple to use file i/o based handles to devices. > Abstactions like this lead to confusion. > > A audio hardware card is a device. > A device has ports. > Simple. > > (An alternative would be to use file i/o and IOCTLs. Defining > this level > would be no different than the OS defining a new user mode > streaming model. > Far more complex for host developers, but we would be right > at the metal > then and I have no problem with that. Simple device names for > CreateFile(). > Share level attributes are defined. IOCTLs are easy to add > and extend and > can be created by groups of interested parties vs having to > define them > upfront for some API wrapper. This method would also permit > any driver model > to be written on top of the kernel mode driver. ) > > Event based signaling of completion. Pull model. I don't > want to have to > poll the device. The hardware must tell me when it needs > data, has data, or > has completed an operation. The hardware just streams data > when it is told > to start. It notifies the host that an event has occurred, > the primary event > being "service my buffers." This implies that both playback > and record are > serviced on a single event notification. > > Take the guess work out of the process of determining optimal > buffer sizes. > Let the driver define its buffer size. The only way the host > can deal with > additional buffering correctly is by knowing exactly what the > hardware is > running at. This is the best way to achieve low latencies. > Have the driver > allocate the buffers vs host allocation and preparation. If > the host wants > to pad buffering/prerender/preroll, then this is a host > problem. Let the > hardware run at the best of its abilities all the time buy > design and then > let the host deal with host related buffering issues. If the > driver can > provide the direct buffer it will be using, great. > > System level time stamps of all operations so we know when things have > occurred at the driver level. This is very important when dealing with > buffer times and to provide accurate position information in the host. > > App level control of sharing and even the multiclient > behavior of the driver > itself. That is let the app decide whether ports/devices are > shared. No > sharing means lower latencies. Sharing means kmixer type > helper inbetween. > (It would be nice to know the impact of sharing exactly, but > this could be > determined by the buffer size that the device opens with.) If > a device can > support one host using 4 of 8 of its port and another host using the > remaining 4 ports, then let this be discoverable. > > Communication of native hardware buffer formats would be > nice. If a driver > wants interleaved then let us know. If the driver prefers > non-interleaved > data, then let us know. If the host can prepare data in the > best format for > the driver, then this will improve performance and possibly > latency. If a > particular driver has a unique format, the driver vendor > could always define > this as a new wave format type. Of course the driver would > have to support > standard formats. > > If you want a starting point, look at ASIO. ASIO is > problematic not in its > functional purpose, but in its definition leading to various > interpretations > in implementation. > > Peter Haller > Sonic Foundry, Inc. > > > ----- Original Message ----- > From: "Alejandro Goyen" <agoyen@xxxxxxxxxxx> > To: <dvm@xxxxxxxx>; <wdmaudiodev@xxxxxxxxxxxxx> > Sent: Thursday, December 05, 2002 5:51 PM > Subject: [wdmaudiodev] Re: White Papers now available > > > > > > A pleasure to meet you all. My name is Alejandro Goyen, > Core Audio Program > > Manager at Microsoft. > > > > The low latency platform is open for discussion and I would > be pleased to > > hear about your requirements. > > > > Thanks, Alejandro. > > > > Alejandro Goyen > > Core Audio Program Manager > > Microsoft Corporation > > > > > > > > _________________________________________________________________ > > The new MSN 8: smart spam protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > ****************** > > > > WDMAUDIODEV addresses: > > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx > > Subscribe: > mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe > > Unsubscribe: > mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe > > Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx > > > > URL to WDMAUDIODEV page: > > http://www.wdmaudiodev.de/ > > > > ****************** > > WDMAUDIODEV addresses: > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx > Subscribe: > mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe > Unsubscribe: > mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe > Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx > > URL to WDMAUDIODEV page: > http://www.wdmaudiodev.de/ > ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.de/