multichannel WaveRT

Hi,
I have an audio device which hardware could be serviced with a WaveRT miniport driver.
The circular buffer is a multi channel buffer, which will contain a mixture of digital and analog audio. In turn the digital channels could feed various digital connectors like an SPDif or ADAT.
The missing link is how can I tell the audio engine which channel offset the various supported data formats do have? I.e. for AC3

Its clear to me how I would implement this with a solution like WaveCyclic, where the portclass driver itself controls the buffer reads/writes.

Can I define the channel offset for the WaveRT audio engine to read/write into/from the circular buffer with the Format.dwChannelMask of a WAVEFORMATEXTENSIBLE KSDATARANGE_AUDIO from the GetDescription() method? Or how would I do this otherwise?
Does Format.nChannels still hold the max amount of the audio channels in the multichannel buffer?
How about the bit width? The multichannel audio buffer could be organised generally as 24bit samples, but can the audio engine deliver AC3 to 24bit samples?

Thanks a lot for any hint in which direction I need to look,
cheers,
Hagen.

Maybe I should simplify the question:
Is it possible to access distinctive audio channels from a multichannel WaveRT buffer?
Thanks & cheers,
Hagen.

xxxxx@dynax.at wrote:

Maybe I should simplify the question:
Is it possible to access distinctive audio channels from a multichannel WaveRT buffer?

Are you saying your circular buffer has one section that is PCM, one
section that is AAC, one section that is FLAC, etc?

Why would one create a design like that? A given endpoint can only have
one format at a time.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim,
no, our circular buffer could contain audio for digital and analog interfaces. The digital interface could be an SPDif and therefor should support PCM as well as AC3 for example. Thats a pretty standard design as no extra synchronization is needed between the various supported hardware interfaces.

But apart from being able to have various hardware interfaces addressable in an multichannel WaveRT it would also make sense to provide a “head phone pin” and “main speaker” stereo pin, etc. which route audio to a certain channel in the multichannel WaveRT buffer.

But my question is, is it possible to address a certain channel in the interleaved multichannel WaveRT for the Windows audio engine mixer. From all I have read on MSDN it doesn’t look like this. And that would make the multichannel WaveRT pretty useless for a professional audio interface, where a user would also want to use the digital IO separately on an own pin - since for most player application (i.e Windows Media Player) there is no option to address a certain channel in a multichannel pin, apart from the impossibility to define AC3 i.e. on a global multichannel pin. (Without an option for the WaveRT miniport driver to provide pins which access certain channel offsets the whole WaveRT multichannel design would only be suitable for surround or maybe for DAWs which open the whole stream and do the routing itself i.e. Cubase.)

Maybe its the wrong place to ask such questions, but knowing that would also help.

Cheers and thanks,
Hagen.

xxxxx@dynax.at wrote:

no, our circular buffer could contain audio for digital and analog interfaces. The digital interface could be an SPDif and therefor should support PCM as well as AC3 for example. Thats a pretty standard design as no extra synchronization is needed between the various supported hardware interfaces.

But apart from being able to have various hardware interfaces addressable in an multichannel WaveRT it would also make sense to provide a “head phone pin” and “main speaker” stereo pin, etc. which route audio to a certain channel in the multichannel WaveRT buffer.

Maybe I’m just being confused by your use of the terminology. In
Windows terms, a “multichannel WaveRT buffer” means something like 5.1
or 7.1 data – a single audio signal in a single format, with data for
several speakers. Stereo on steroids. You can’t have a headphone jack
and a main speaker jack both active at the same time, getting the same
output signal with different formats.

But my question is, is it possible to address a certain channel in the interleaved multichannel WaveRT for the Windows audio engine mixer. From all I have read on MSDN it doesn’t look like this.

I just can’t visualize what you’re asking here. If you have a 5.1 audio
signal, then all 6 channels of audio are basically a single unit. It
sounds like you want to route the front-right channel to a separate
jack. Is that what you mean? You could do that in an application, but
not in the mixer. The mixer doesn’t separate the components.

And that would make the multichannel WaveRT pretty useless for a professional audio interface, where a user would also want to use the digital IO separately on an own pin

You could certainly have a crossbar in your audio hardware that lets you
route the current audio stream to two output ports at the same time, and
you could control that through custom properties, but there’s nothing in
the Audio Engine to do that, because most hardware can’t do it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks, Tim,

Maybe I’m just being confused by your use of the terminology. In
Windows terms, a “multichannel WaveRT buffer” means something like 5.1
or 7.1 data – a single audio signal in a single format, with data for
several speakers. Stereo on steroids.

I see. What you are saying is that WaveRT is only capable for a consumer surround product, but not for lets say a 32, 64 or 128 channel audio interface. In that sense you would be right, that my understanding and therefor “terminology” of a multichannel audio buffer seams to differ from the surround-only-use-case: a multichannel audio buffer is something that contains multiple audio channels, wether they relate to a certain speaker or not. So a “multichannel WaveRT buffer” is actually a “surround WaveRT buffer”.

You can’t have a headphone jack
and a main speaker jack both active at the same time, getting the same
output signal with different formats.
But that was not the question. The example was 2 pins i.e. one called headphone another called “main out” or headphone2 or simply channel#15 or whatsoever referring to its own audio channels in an interleaved multichannel audio buffer.

> But my question is, is it possible to address a certain channel in the
interleaved multichannel WaveRT for the Windows audio engine mixer. From all I
have read on MSDN it doesn’t look like this.

I just can’t visualize what you’re asking here. If you have a 5.1 audio
signal, then all 6 channels of audio are basically a single unit. It
sounds like you want to route the front-right channel to a separate
jack. Is that what you mean?
no, not at all. I dont care about speaker mapping. I want to be able to open a pin and stream to/from a dedicated audio channels in the multichannel buffer.

You could do that in an application, but
not in the mixer. The mixer doesn’t separate the components.
Well that is at least not entirely true. Since Windows can allow to open a pin with different amounts of channels, which means that depending on the amount of channels the channels addressed are different. Which also means Windows must be able to mix different amounts of audio channels into a WaveRT buffer.

In i.e. a WaveCyclic miniport driver the pin format or pin number or other means can be used to relate the pin or even stream on the same pin to a certain channel in the multichannel buffer, because the driver accesses the buffer directly.

You could certainly have a crossbar in your audio hardware that lets you
route the current audio stream to two output ports at the same time, and
you could control that through custom properties, but there’s nothing in
the Audio Engine to do that, because most hardware can’t do it.
That would be an odd design for a very questionable use-case.

Maybe an example can illustrate what is needed for a multichannel audio interface:

The device has 4 audio streams that it interleaves in a circular buffer, which can be addressed by a driver. Those 4 audio streams do not relate to any speaker setting, nor are used for surround. They represent something like 2xMic with preamp, 2xLine in.
Now if I want to represent this to an audio application, I can do so by providing a multichannel stream containing 4 channels. And/or I could define 3 other pins: Mic1,Mic2 and Line-in stereo. or whatsoever.

If I want to use the WaveRT model - which technically would fit perfectly - since the buffer is fed by my hardware directly, while the hardware has registers for RX,TX, clock etc. - I would need to be able to tell which channel offset into the multichannel buffer the Mic1 pin or the Line-In stereo require, so the Windows audio engine can extract the data belonging to the pin. And as far as I have found out thats impossible and therefor the WaveRT does not support a generic multichannel buffer, but only a surround buffer, which is always addressed from the first channel on.

Cheers and thanks,
Hagen.

xxxxx@dynax.at wrote:

Maybe an example can illustrate what is needed for a multichannel audio interface:

The device has 4 audio streams that it interleaves in a circular buffer, which can be addressed by a driver. Those 4 audio streams do not relate to any speaker setting, nor are used for surround. They represent something like 2xMic with preamp, 2xLine in.
Now if I want to represent this to an audio application, I can do so by providing a multichannel stream containing 4 channels. And/or I could define 3 other pins: Mic1,Mic2 and Line-in stereo. or whatsoever.

OK, I finally see what you’re saying. You’re using “multichannel” here
in the sense of a big mixer board carrying 32 independent channels of
audio. The Windows audio model just doesn’t work that way. In Windows
audio terms, the scenario you have described here is not a single
multichannel stream. It is three separate streams, two of which have
one channel and one of which has two channels. They aren’t related. It
would require three different WaveRT buffers. The Windows meaning of
“channel” is directly linked to speakers and positions, not to sources.

If I want to use the WaveRT model - which technically would fit perfectly - since the buffer is fed by my hardware directly, while the hardware has registers for RX,TX, clock etc. - I would need to be able to tell which channel offset into the multichannel buffer the Mic1 pin or the Line-In stereo require, so the Windows audio engine can extract the data belonging to the pin. And as far as I have found out thats impossible and therefor the WaveRT does not support a generic multichannel buffer, but only a surround buffer, which is always addressed from the first channel on.

Correct. It’s a different basic philosophy.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim,
for the clarification!

Are the amount of channels in a WaveRT driver limited?

Would it make sense to additionally create a filter driver (i.e. WaveCyclic) which sits on top of a WaveRT and providing the means of accessing individual channels? While a DAW would normally use the big multichannel (complete mixer) pin with the better performance and latency, the Media Player could use the filter driver pin, which accesses spdif, the main outs or headphones, where latency does not matter - if it can compensated.
Should that be a miniport driver itself or better something else i.e a GFX?

Thanks for the thoughts and all the help so far,
cheers,
Hagen.

xxxxx@dynax.at wrote:

Are the amount of channels in a WaveRT driver limited?

Probably, but I don’t know the limit.

Would it make sense to additionally create a filter driver (i.e. WaveCyclic) which sits on top of a WaveRT and providing the means of accessing individual channels? While a DAW would normally use the big multichannel (complete mixer) pin with the better performance and latency, the Media Player could use the filter driver pin, which accesses spdif, the main outs or headphones, where latency does not matter - if it can compensated.

You can’t really have a filter driver on top of WaveRT. Remember that
the data transfer in a WaveRT stack never passes through kernel mode.
The special user-mode Audio Engine process reads and writes the circular
buffers directly, with no kernel participation.

If you have separate sources mixed into a single mega-multi-channel
audio signal, how can they possibly have different latencies? The
timing is all going to be identical.

I suppose you could implement a WaveCycle driver on top of your RT-like
hardware, but that means increasing the number of user/kernel
transitions dramatically, and it means copying the data.

Should that be a miniport driver itself or better something else i.e a GFX?

The way you do this in Windows is to have multiple pins (meaning
multiple WaveRT buffers), each reflecting one source or sink. By doing
anything else, you’re just going to hurt yourself. You don’t want to
fight the paradigm – that leads to unhappiness.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks, Tim,
for your valuation!

If you have separate sources mixed into a single mega-multi-channel
audio signal, how can they possibly have different latencies? The
timing is all going to be identical.
Thats the reason to put all in a big buffer. They relate and they need to be in sync. Or are you referring here to the different hardware latencies i.e. a AD/DA converter has in comparison to a digital interface? The latency differences do matter and therefor the different interfaces should be addressable by different pins. (I understood its not possible with WaveRT - but that were the constraints when looking into WaveRT). But actually talking Windows audio - it looks like we have bigger issues than worrying hardware latencies. If I have to go the road with WaveCyclic we will not be able to provide low latency audio at all. Everything above 5ms is pretty unusable for monitoring live performance, etc.

I really wonder, all the effort put into the various reincarnations of the of Windows audio from the first MM to WaveRT, and never thought of supporting professional audio or asking for the requirements. Thats why we still stick to ASIO.

Cheers and thanks,
Hagen

xxxxx@dynax.at wrote:

… If I have to go the road with WaveCyclic we will not be able to provide low latency audio at all. Everything above 5ms is pretty unusable for monitoring live performance, etc.

I really wonder, all the effort put into the various reincarnations of the of Windows audio from the first MM to WaveRT, and never thought of supporting professional audio or asking for the requirements.

On the contrary, the almost total rewrite of the audio subsystem in
Vista was made with professional audio applications primarily in mind.
After all, the consumer segment has been adequately addressed for a very
long time. It was the cutting edge applications that ran into trouble
with the old model.

Also remember that WaveRT is as much a hardware spec as it is a software
spec. WaveRT and HDAudio go hand-in-handm and HDAudio came from Intel
(with friends).

I think the issue here is just that your mental model differs from the
Windows model. You simply have a different definition of “channel”.
What you want to do can be done, it just can’t be done the way you want
to do it. You just need to find a way to map your vocabulary onto the
Windows vocabulary. Windows doesn’t put unrelated audio information in
a single stream. If you start thinking about them as different streams,
then your tasks can be accomplished.

The audio team at Microsoft is competent, thoughtful, and experienced,
and they are VERY much interested in hearing stories of professional use
cases that don’t fit into their models. It might be worthwhile for you
to try to set up a short face-to-face meeting with members of that team
to see if there is a better way to do what you want, or to see if you
can change their minds.

Thats why we still stick to ASIO.

I hear that a lot, but I think that’s just because you’re used to it.
ASIO still uses the same old Windows drivers to get at the hardware.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks, Tim,
I don’t doubt the competence of the audio team at Microsoft. Maybe the focus is different: When I talked to the Windows audio development team on the Windows Driver Developer Conference in 2003 I was surprised about the understanding of the needs for professional audio support: Latency did not seem to be understood as a fundamental issue for digital audio workstations, nor has been multichannel support, apart from consumer surround. 8 channels seemed to be all that was needed. At that time we already had a 32 channel IO looking for some Windows rendezvous.
But I would be pleased to have to change my mind!

I think the issue here is just that your mental model differs from the
Windows model. You simply have a different definition of “channel”.
What you want to do can be done, it just can’t be done the way you want
to do it. You just need to find a way to map your vocabulary onto the
Windows vocabulary. Windows doesn’t put unrelated audio information in
a single stream. If you start thinking about them as different streams,
then your tasks can be accomplished.
Exactly, unrelated audio does not belong into a single stream. Nobody would need that. But being able to combine i.e digital and analog audio in a single stream makes sense. Imagine an interface with (several) ADAT combined with analog channels, the user could extend the analog IO with external AD/DA converters connected to ADAT on demand. Nearly all pro-audio devices on the market work like that. But in Windows term thats an obscure understanding of an audio “channel”, because it doesn’t fit into a Left/Right/Front/Back/etc. scheme.
Those channels could be as well in different streams, but to get them in sync is a hassle with the Windows audio model. Apart from that I don’t know any DAW that would allow opening several audio pins of the same direction at the same time for synchronously streaming.

> Thats why we still stick to ASIO.
I hear that a lot, but I think that’s just because you’re used to it.
Then there could be some truth in it. Although I would love to get rid of it as ASIO has its own limitations, as well as the additional support effort. In the end thats the reason to look again into portclass audio, while already having shipped around some of issues with portclass. But deploying a pro-audio interface requires ASIO with no change insight!

ASIO still uses the same old Windows drivers to get at the hardware.
Yes. It must reach the hardware somehow. But which one is the “same old Windows driver”?

Cheers and thanks for your thoughts and insights,
Hagen.