[wdmaudiodev] Re: White Papers now available

  • From: "Peter Haller" <pchaller@xxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Sat, 7 Dec 2002 23:54:58 -0500

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/

Other related posts: