[wdmaudiodev] Re: PcAddStreamResource IRQ question

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 17 Apr 2018 08:24:05 +0200

"It's working really well at 32 samples" !?!

This means that you can have a stable DSP load of 80% in your audio callback 
and the audio stream is strictly continue on 24h00 (we do such validation with 
a 100Hz sinus, coming on audio board input and outgoing to an external analyzer 
counting cut in the sound).

In 20 years, I've never heard about a configuration able to pass this 
validation test with 32 samples buffer. And if it does not pass this test, it 
means it does not work.

BTW: you may know that WIN10 does not pass this test with any buffer size today 
(real time capabilities are broken by a bad memory management since 2 years) 
see our article there:
https://www.facebook.com/notes/vb-audio-software/finally-windows-10-could-support-audio/1646244165445117/
(discussion here is called "WIN10 Major Issue for Audio Processing")

We are waiting the WIN10 Spring Update with our validation tool:   
https://forum.vb-audio.com/viewtopic.php?f=11&t=519

Regards
Vincent Burel
PS: to go below 5ms latency under Windows, we need to place the system in 0.1 
ms scheduler period (while it can be 1 ms only today).  See our 2 or 3 messages 
in this mailing list called "Windows & Real Time : suggestion to Microsoft 
Kernel Developers".

-----Message d'origine-----
De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Mike Audet
Envoyé : lundi 16 avril 2018 23:30
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: PcAddStreamResource IRQ question

Hi Wade,

I'm registering the IRQ used by the Ensoniq PARIS PCI card.  PARIS is a
20 year old PCI base DAW.  Getting multiple PCI cards to operate in sync with 
really small buffers was a challenge, but a fun one. 

It's working really well at 32 samples, but I can see a need to optimize the 
Windows install to limit background processes as much as possible. I'm hoping 
that PcAddStreamResource might obviate that.

All the best!
Mike

On 4/16/2018 12:22 PM, Wade Dawson wrote:

Hi Mike.  If your underlying transport is usb, and you’re using iso 
transfers,  1ms will be the minimum callback timing that you’ll be able to 
achieve without jitter.  Since (in this case) iso transfer size is ultimately 
governed by samplerate, it is not possible to directly instruct usb to 
transfer anything other that 44/45, 48, 88/89, etc samples per millisecond.  
(Current usb host controller drivers will only Irq on multiples of 8 uFrames, 
I.e., 1ms) This mismatch between iso frame size and asio buffer size, is why 
asio jitter exists and why some driver designers are forced to call asio 
bufferswitch at non-regular intervals (jittery) when running atop a blocking 
transfer medium such as usb iso.  

Some firmware and driver implementations actually operate in a non class 
compliant mode utilizing bulk transfers for audio instead of iso so that they 
can drive their processing callback at the asio buffer size period instead of 
the usb iso (1ms) callback period.

Btw, what are IRQ are you trying to register?  
Sent from my iPhone

On Apr 16, 2018, at 10:28, Mike Audet <mike@xxxxxxxxxxxxx> wrote:

Thanks for your reply, Vincent!

I'm getting pretty good results now.  It's only when, for example, 
Windows updates the desktop wallpaper that I sometimes get a glitch.

It's my understanding that calling SetEvent from kernel mode wakes up 
the waiting thread immediately, without waiting for the next sche 
duler slot.  So, it should be possible (if I understand things right) 
to go this low.  It's only if Windows handles a high load IRQ, like 
networking, video, or hard disk, on the same CPU as the audio IRQ 
that there should be a problem (I think).  It's my understanding that 
this new function is designed for this exact situation.

I'm pretty excited to try this new function to see what impact it has. 
But, there is no sample code or description of how to use the function. 
There's not even a comment in portcls.h.

All the best!

Mike


On 4/16/2018 9:14 AM, Vincent Burel (VB-Audio) wrote:
Hello,

On current Windows O/S, It makes no sense to manage 32 samples buffer size 
on ASIO driver (or any audio driver).
First because Windows cannot manage time slot below 1 ms (1ms must be 
considered as Real Time Jitter under Windows - from XP to current WIN10 - 
but the validated value is more closed to 3ms).
Secondly because interrupt incident (due to multitask, page out etc... can 
bring 2 or 3 ms penalty in an audio callback process). so you may consider 
buffer size above 2.5 to 5 ms to provide a reliable real time audio stream 
(it makes usually 128 to 256 samples at 48kHz).

Some audio board manufacturers already did it, they can provide down to 32 
or even 16 samples buffer size but it's a disaster in term or stability and 
real time (because they are obliged to call the process several time in the 
same time slot, breaking the basic DSP time rules) and finally get a real 
latency bigger than on well implemented drivers using 128 or 256 samples 
buffer.

Regards
Vincent Burel

-----Message d'origine-----
De : wdmaudiodev-bounce@xxxxxxxxxxxxx 
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Mike Audet ;
Envoyé : lundi 16 avril 2018 14:34 À : wdmaudiodev@xxxxxxxxxxxxx 
Objet : [wdmaudiodev] PcAddStreamResource IRQ question

Hi everyone,

Does anyone know how to use the new PcAddStreamResource function to 
register an IRQ?

The Interrupt stricture in PCSTREAMRESOURCE_DESCRIPTOR looks like this:

struct {
           ULONG Version;
           PVOID Generic;
} Interrupt;

I'm not sure what to assign to either Version or Generic.

I've searched online and in the archive, and I've only been able to find 
sample code that relates to registering a thread.

I'm trying to make an ASIO driver more robust at a 32 sample buffer size.

Below is some code I've roughed in to my ConnectInterrupt routine.

Thanks so much!

Mike

roughed in code:

PCSTREAMRESOURCE_DESCRIPTOR_INIT(&ResourceDescriptor);
ResourceDescriptor.Pdo = DeviceExtension->PhysicalDeviceObject;
ResourceDescriptor.Type = ePcStreamResourceInterrupt; 
ResourceDescriptor.Resource.Interrupt.Version = ???;//no idea at all....
ResourceDescriptor.Resource.Interrupt.Generic = 
(PVOID)DeviceExtension->InterruptObject; //just a guess....is this right?
ResourceDescriptor.Resource.ResourceSet = NULL; result = 
PcAddStreamResource(DeviceExtension->PhysicalDeviceObject,
NULL, &ResourceDescriptor, &DeviceExtension->irqResourceHandle);
if (!NT_SUCCESS(result))
{
      DbgPrint("Error calling PcAddStreamResource: %u", result); }

******************

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.com/

******************

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.com/


******************

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.com/

******************

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.com/



******************

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.com/

******************

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.com/

Other related posts: