[wdmaudiodev] Re: PcAddStreamResource IRQ question

  • From: Wade Dawson <wdawson61@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Mon, 16 Apr 2018 12:22:19 -0400

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 scheduler
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/

Other related posts: