It is just RUN user mode, and provides a interface layer to the filters which reside in the kernel .
But who are these filters? Are these filters included in the drivers whick below to the " kmixer.sys" ? And is also the core issue of the ASIO which means direct access to the hardware ? Because the stream does not pass through the " kmixer.sys" ?
To be continue:
For example , If there is ASIO driver for a USB audio device , then it means that "these filters? " is in the "usbaudio.sys " ?
If this is true, How to find the programing interface of the "usbaudio.sys " ?
xxxxx@gmail.com wrote:
It is just RUN user mode, and provides a interface layer to the filters which reside in the kernel .
Correct. It is a library that allows user-mode access to kernel
streaming drivers.
But who are these filters? Are these filters included in the drivers whick below to the " kmixer.sys" ? And is also the core issue of the ASIO which means direct access to the hardware ? Because the stream does not pass through the " kmixer.sys" ?
Virtually all streaming drivers (meaning audio and video) are kernel
streaming drivers. Kernel streaming was introduced in Windows 2000, so
it is a stable technology. A kernel streaming driver creates one or
more “filters” (that term coming from DirectShow), each of which exposes
one or more “pins”. The KS framework creates connections between the
pins to allow data to pass.
Whether kmixer.sys is involved or not depends in large part on your
operating system. Older systems use kmixer.sys. Vista and beyond do not.
For example , If there is ASIO driver for a USB audio device , then it means that "these filters? " is in the "usbaudio.sys " ?
Usbaudio.sys is a kernel streaming driver. It exposes KS filters for
any USB audio devices.
If this is true, How to find the programing interface of the "usbaudio.sys " ?
It is a kernel streaming driver. The programming interface is through
the kernel streaming APIs. Have you tried Google or MSDN even once?
Most user-mode applications access these filters through the
“ksproxy.ax” DirectShow wrapper, by using the system device enumerator
(CLSID_SystemDeviceEnum) to find the device and return an IBaseFilter
interface. From there, you can ask for an IKsControl interface and send
kernel streaming requests directly. DirectKS provides another way to
gain access to those requests.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi, Tim , Thanks for your reply.
I compare the pictures in the “Introduction to Port Class” both in the WDK 7600, and DDK 2600, The kmix.sys does disppeared in the newer windows . I also googled and find the Microsoft has make some effort to reduce the delay, I guess this might be the issue.
Let’s just talk about the “Older windows systems”.
The biggest matter I want to know is: If the ?chief criminal? that cause the delay of audio is the “kmix.sys” in the “Older systems” , and the ASIO’s main purpose is make the stream to “BYPASS” the kmixer.sys ?
I also find a statement that says by compared to the DirectSound, if the DirectSound is a formed by C++ language , the ASIO may be formed by assembly language. So ,the ASIO is more “dircetly” to the hardeware ?? I thind this should be the explains of you , the DirectSound uses the wrapper filter “ksproxy.ax” , and these is a layer over the hardware?? not dircetly.
So, how about the ASIO? How does it communicate to the hardware? It use “kernel streaming API”, that does clearly, well, how these “kernel streaming API” commnicate to the hardware? I thinks these API must reside in the "usbaudio.sys " (the stream class driver ) or in the “USBD.sys”(the bus class driver ) , this can be seem from the picture I mentioned above , then , which layer?
I puzzle to the functions in the Streaming part of the DDK , I puzzled if it is a kernel functions or can be called from user mode ,can you give a example of the “kernel streaming API” ?
You wrote:
Let's just talk about the "Older windows systems".
The biggest matter I want to know is: If the ?chief criminal? that
cause the delay of audio is the "kmix.sys" in the "Older systems" , and
the ASIO's main purpose is make the stream to "BYPASS" the kmixer.sys ?
What makes you think that audio latency is a problem? Are you just assuming that it must be, or do you actually have a product that exhibits a problem?
I also find a statement that says by compared to the DirectSound,
if the DirectSound is a formed by C++ language , the ASIO may be formed
by assembly language. So ,the ASIO is more "dircetly" to the hardeware
??
No, that's silly. The difference in performance between a C++ program and an assembler program is utterly trivial. Whatever difference there might be is swamped by the movement of data, kernel/user transitions, and device communication.
I thind this should be the explains of you , the DirectSound uses the
wrapper filter "ksproxy.ax" , and these is a layer over the hardware??
not dircetly.
No.
So, how about the ASIO? How does it communicate to the hardware? It
use "kernel streaming API", that does clearly, well, how these "kernel
streaming API" commnicate to the hardware?
It's all layers. Applications (and DirectSound and ASIO) make kernel streaming requests. Those requests go to usbaudio.sys, which translates them into USB packets and sends them to USBD. USBD sends the packets to the device.
I thinks these API must reside
in the "usbaudio.sys " (the stream class driver ) or in the
"USBD.sys"(the bus class driver ) , this can be seem from the picture I
mentioned above , then , which layer?
Usbaudio.sys is an audio driver. USBD doesn't know anything about audio.
I puzzle to the functions in the Streaming part of the DDK , I
puzzled if it is a kernel functions or can be called from user mode ,can
you give a example of the "kernel streaming API" ?
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I also find a statement that says by compared to the DirectSound, if the DirectSound is a formed by
C++ language , the ASIO may be formed by assembly language.
USB driver written in assembler? looks like nonsense.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
No ,You misunderstand me , just a way of analogy.
Re: RE:The “directks” IS NOT a deriver?
You wrote:
Let’s just talk about the “Older windows systems”.
The biggest matter I want to know is: If the ?chief criminal? that
cause the delay of audio is the “kmix.sys” in the “Older systems” , and
the ASIO’s main purpose is make the stream to “BYPASS” the kmixer.sys ?
What makes you think that audio latency is a problem? Are you just assuming
that it must be, or do you actually have a product that exhibits a problem?
Some advanced or professional music instruments have critically demand about these.
I think there do exist some latency to some extent , I just want to know if it is caused by the "kmix.sys" , and the improving method is BYPASS the the stream .
> I also find a statement that says by compared to the DirectSound,
>if the DirectSound is a formed by C++ language , the ASIO may be formed
>by assembly language. So ,the ASIO is more "dircetly" to the hardeware
>??
No, that's silly. The difference in performance between a C++ program and an
assembler program is utterly trivial. Whatever difference there might be is
swamped by the movement of data, kernel/user transitions, and device
communication.
>I thind this should be the explains of you , the DirectSound uses the
>wrapper filter "ksproxy.ax" , and these is a layer over the hardware??
>not dircetly.
No.
~~~~~~~~~~~~~~ What do you mean?
Do you consider that the DirectSound can be also thought to access to the hardware directly?
> So, how about the ASIO? How does it communicate to the hardware? It
>use "kernel streaming API", that does clearly, well, how these "kernel
>streaming API" commnicate to the hardware?
It's all layers.
~~~~~~~~~~~~~~~~ Can you give me some more information? What are all layers?
Applications (and DirectSound and ASIO) make kernel streaming
requests. Those requests go to usbaudio.sys, which translates them into USB
packets and sends them to USBD. USBD sends the packets to the device.
>I thinks these API must reside
>in the "usbaudio.sys " (the stream class driver ) or in the
>"USBD.sys"(the bus class driver ) , this can be seem from the picture I
>mentioned above , then , which layer?
Usbaudio.sys is an audio driver. USBD doesn't know anything about audio.
I think you mean that the audio data “should / must / have to” be pass though some filters , can not go to the USB bus directly.
I puzzle to the functions in the Streaming part of the DDK , I
puzzled if it is a kernel functions or can be called from user mode ,can
you give a example of the “kernel streaming API” ?
Most of the “kernel streaming API” is a set of ioctls (IOCTL_KS_PROPERTY,
IOCTL_KS_WRITE_STREAM, etc). DirectKS happens to provide a nice callable
interface to those ioctls.
--
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim, thanks for your patience.xxxxx@gmail.com wrote:
Some advanced or professional music instruments have critically demand about these.
Yes, some have done so. However, that’s mostly the lunatic fringe. 99%
of users never have a problem. If you do not have a specific problem
you are trying to solve, then you will experience nothing but
frustration. You need to have a number you can measure, so you can
prove that things aren’t good enough, and so you can prove whether or
not your changes have any effect. Otherwise, you’re just wasting your time.
I think there do exist some latency to some extent , I just want to know if it is caused by the “kmix.sys” , and the improving method is BYPASS the the stream .
Windows XP is 9 years old. If there were a simple answer, it would have
been implemented a very long time ago. Latency has a large number of
possible causes, and each one adds a little bit to it.
> I thind this should be the explains of you , the DirectSound uses the
> wrapper filter “ksproxy.ax” , and these is a layer over the hardware??
> not dircetly.
>No.
Do you consider that the DirectSound can be also thought to access to the hardware directly?
Look, NONE of these audio APIs “access the hardware directly”. You need
to get rid of that concept. It is simply impossible. It cannot be
done. ALL of these APIs go through an audio driver (the SAME audio
driver). The only difference is how many additional layers they add.
The audio driver, in the USB case, is usbaudio.sys. Usbaudio.sys
supports the kernel streaming protocol (through those IOCTL_KS ioctls I
mentioned previously). Anybody that wants to use a USB audio device in
Windows will eventually be sending IOCTL_KS ioctls to usbaudio.sys.
For DirectShow, the application hooks up a set of DirectShow filters to
ksproxy.ax, which talks to usbaudio.sys. For ASIO, the application
talks to the ASIO “driver”, which uses DirectKS to talk to
usbaudio.sys. For DirectSound, the DirectSound DLL talks to
usbaudio.sys (although this changed somewhat in Vista).
It’s all layers.
All hardware access in Windows happens in layers. Each driver talks to
the driver below it, using whatever interface it supports, and offers
services to drivers and applications above it, using some well-defined
interface. Thus, each layer is responsible for a relatively small part
of the puzzle, which makes things much easier to manage.
Usbaudio.sys is an audio driver. USBD doesn’t know anything about audio.
I think you mean that the audio data "should / must / have to" be pass though some filters , can not go to the USB bus directly.
Well, “filters” or “layers”. Audio data doesn’t know anything about
USB, so it has to pass through usbaudio.sys. After that, they’re just
USB packets with no concept of audio.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Maxim S. Shatskih wrote:
> I also find a statement that says by compared to the DirectSound, if the DirectSound is a formed by
> C++ language , the ASIO may be formed by assembly language.
>USB driver written in assembler? looks like nonsense.
Well, ASIO is a layer for audio performance loonies. It’s not
impossible that large parts are in assembler, although that would be
silly; the compiler is not the bottleneck.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Tue, May 18, 2010 at 8:05 PM, Tim Roberts wrote:
>
> Well, ASIO is a layer for audio performance loonies. It’s not
> impossible that large parts are in assembler, although that would be
> silly; the compiler is not the bottleneck.
>
I am an pro-amateur musician. ASIO is not used in playback, it is only
used in recording. Professional audio interfaces come with:
1) 8-32 channels
2) ASIO drivers.
I don’t really know how ASIO works internally, but I know what it
does. It gives you soft-real time deterministic latency. I know I can
record with ASIO, while I can’t record with standard drivers. It’s not
a matter of audio subjective quality or anything. I can deliver the
product with ASIO, while I can’t deliver the product at all without
it. It simply cannot be done.
–
Aram Hăvărneanu
Aram Hăvărneanu wrote:
On Tue, May 18, 2010 at 8:05 PM, Tim Roberts wrote:
>
>> Well, ASIO is a layer for audio performance loonies. It’s not
>> impossible that large parts are in assembler, although that would be
>> silly; the compiler is not the bottleneck.
>>
>
> I am an pro-amateur musician. ASIO is not used in playback, it is only
> used in recording.
That’s not true. The “IO” in the name specifically stands for
“Input/Output”. It might not be as necessary on the output side because
latency is less important, but it still applies.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>record with ASIO, while I can’t record with standard drivers.
I expect that the professional equipment is either a) PCI hardware or b) USB hardware which does not use usbaudio.sys
Is it correct?
Wrapping ASIO around usbaudio.sys provides you no value, except possible support of El Cheapo USB hardware (without ASIO drivers) in the ASIO-based apps like Steinberg’s one.
You will not have better latency by using ASIO app -> ASIO4ALL -> usbaudio.sys, then by using DirectSound app -> KS/AVStream -> usbaudio.sys
To have better latency, all driver stack must be replaced.
So, ASIO is useless as a generic interface, it is only usable for special hardware - otherwise, it has no advantages over DirectSound.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On Wed, May 19, 2010 at 2:55 AM, Tim Roberts wrote:
>
> That’s not true. The “IO” in the name specifically stands for
> “Input/Output”. It might not be as necessary on the output side because
> latency is less important, but it still applies.
>
Well of course. You have to listen to what you just recorded anyway
and the DAW programs use ASIO for output :-). I was saying that
usually people use ASIO in the recording process and that it has no
value for your average person that just listens to music.
–
Aram Hăvărneanu
On Wed, May 19, 2010 at 3:23 PM, Maxim S. Shatskih
wrote:
> I expect that the professional equipment is either a) PCI hardware or b) USB hardware which does not use usbaudio.sys
>
> Is it correct?
Actually it is Firewire :-). Some middle end hardware may be PCI or
USB, but that’s used in the mastering/mixing process, on the input
side people use Firewire becase signal/noise ratio is much better for
external devices, you can have more channels and it seems that CPU
usage is lower for Firewire compared to USB.
> Wrapping ASIO around usbaudio.sys provides you no value, except possible support of El Cheapo USB hardware (without ASIO drivers) in the ASIO-based apps like Steinberg’s one.
>
> You will not have better latency by using ASIO app -> ASIO4ALL -> usbaudio.sys, then by using DirectSound app -> KS/AVStream -> usbaudio.sys
>
> To have better latency, all driver stack must be replaced.
Absolutely correct.
> So, ASIO is useless as a generic interface, it is only usable for special hardware - otherwise, it has no advantages over DirectSound.
Absolutely correct.
–
Aram Hăvărneanu
>USB, but that’s used in the mastering/mixing process, on the input
side people use Firewire becase signal/noise ratio is much better
Digital wires has no notion of signal/noise 
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On Wed, May 19, 2010 at 5:30 PM, Maxim S. Shatskih
wrote:
>>USB, but that’s used in the mastering/mixing process, on the input
>>side people use Firewire becase signal/noise ratio is much better
>
> Digital wires has no notion of signal/noise
>
It’s not the digital wires that matter, but the analogue ones. More
precisely, it’s about the noise in the analogue part of the device up
to the analog to digital converters. The ADCs in PCI cards are
influenced by the electric noise in the computer case. Externals
devices are better isolated from that, plus external devices use a
different ground then the computer their connected to minimizing
ground loops leaks.
External interfaces can have 120-130dB of S/N ratio, PCI cards can
rarely go beyond 90dB.
–
Aram Hăvărneanu
On Wed, May 19, 2010 at 5:58 PM, Aram Hăvărneanu wrote:
> On Wed, May 19, 2010 at 5:30 PM, Maxim S. Shatskih
> wrote:
>>>USB, but that’s used in the mastering/mixing process, on the input
>>>side people use Firewire becase signal/noise ratio is much better
>>
>> Digital wires has no notion of signal/noise
>>
>
To make a clarification, I was talking about internal vs. external
interfaces in respect to noise levels, not Firewire vs. USB. Obviously
USB is as good as Firewire when it comes to noise, because the
analogue part is shielded the same way. Firewire is preferred because
it gives lower latency, and CPU utilization is lower. Audio devices on
a Firewire bus can talk to each other via DMA without the CPU.
> It’s not the digital wires that matter, but the analogue ones. More
> precisely, it’s about the noise in the analogue part of the device up
> to the analog to digital converters. The ADCs in PCI cards are
> influenced by the electric noise in the computer case. Externals
> devices are better isolated from that, plus external devices use a
> different ground then the computer their connected to minimizing
> ground loops leaks.
>
> External interfaces can have 120-130dB of S/N ratio, PCI cards can
> rarely go beyond 90dB.
–
Aram Hăvărneanu
To Maxim:
Thanks, your reply is very useful.
record with ASIO, while I can’t record with standard drivers.
I expect that the professional equipment is either a) PCI hardware or b) USB
hardware which does not use usbaudio.sys
Is it correct?
Wrapping ASIO around usbaudio.sys provides you no value, except possible support
of El Cheapo USB hardware (without ASIO drivers) in the ASIO-based apps like
Steinberg’s one.
What is the exact that you want to express ? where does the 'possible support' should reside ? The apps like Steinberg's one, or the 'El Cheapo USB hardware' ?How about the ASIO drivers ?Can you explain more?
You will not have better latency by using ASIO app -\> ASIO4ALL -\> usbaudio.sys,
then by using DirectSound app -\> KS/AVStream -\> usbaudio.sys
To have better latency, _all_ driver stack must be replaced.
So, ASIO is useless as a generic interface, it is only usable for special
hardware - otherwise, it has no advantages over DirectSound.
I think you mean that if I want a good latency performance, I must build a USB audio driver for my USB audio device to replace the ‘usbaudio.sys’.
And maybe the USB audio device should be designed specially in order to cooperate with the special ’ USB audio driver’ to reduce the latency.
xxxxx@gmail.com wrote:
> record with ASIO, while I can’t record with standard drivers.
>I expect that the professional equipment is either a) PCI hardware or b) USB
hardware which does not use usbaudio.sysIs it correct?
I’m not convinced that’s correct, but this is not the right forum for
this question. You should be on wdmaudiodev. The real Windows audio
nuts live over there. Those people have real-world experience in this
arena.
Wrapping ASIO around usbaudio.sys provides you no value, except possible support
of El Cheapo USB hardware (without ASIO drivers) in the ASIO-based apps like
Steinberg’s one.
“El cheapo” is a slang term in pseudo-Spanish, meaning “cheap”.
What is the exact that you want to express ? where does the ‘possible support’ should reside ? The apps like Steinberg’s one, or the ‘El Cheapo USB hardware’ ?How about the ASIO drivers ?Can you explain more?
He’s trying to say that, if usbaudio.sys has latency issues, then
wrapping ASIO around it will not improve those latency issues. This is
part of Amdahl’s Law – you cannot optimize a process faster than its
slowest component.
I think you mean that if I want a good latency performance, I must build a USB audio driver for my USB audio device to replace the ‘usbaudio.sys’.
And maybe the USB audio device should be designed specially in order to cooperate with the special ’ USB audio driver’ to reduce the latency.
Please remember that USB itself places limitations on the minimum
possible latency. USB is not just a wire. It’s a scheduled protocol
bus. Your device has to live within the limitations of the USB
scheduling algorithm.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.