avstream pin allocator framing requirements

Hi everyone,

I'm in the middle of writing my first avstream-based minidriver, and
have been experimenting with the behaviour of everything. I'm confused,
though, when it comes to the concept of allocator framing.

I gather from the DDK documentation that I should be able to declare a
KSALLOCATOR_FRAMING_EX struct and point to it in my pin descriptor, and
through it specify what frame sizes my pin's process dispatch can accept.

DECLARE_SIMPLE_FRAMING_EX(PinFraming,
STATIC_KS_TYPE_DONT_CARE,
KSALLOCATOR_REQUIREMENTF_SYSTEM_MEMORY,
1024, // Frames
FILE_BYTE_ALIGNMENT,
6, // MinFrameSize
6 // MaxFrameSize
);

Now with these requirements specified by my pin, I'd expect to be given
up to 1024 frames, each of 6 bytes in size, in one call to my process
dispatch. What I actually get passed is one frame 8192 bytes long,
clearly beyond the range I specified.


Any ideas why the system is ignoring my framing requirements?


I've tried specifying much larger frame sizes, but the system still
passes me 8192 bytes.


Help!

Thanks,
Nick

Stephan
Tue Jun 20 12:14:33 CDT 2006

The Windows XP audio subsystem ignores the framing requirements of an
AVStream driver on the playback side. You have to process what you get,
which are usually audio chunks of 10ms.

The input side of XP (but not W2k) does support the framing requirement
and will send frames of the requested size.

Some kernel streaming audio applications like Cakewalk SONAR do honor
the framing requirements for both input and output and will send
appropriate frames.

--
Stephan

Nick Dowell wrote:
> Hi everyone,
>
> I'm in the middle of writing my first avstream-based minidriver, and
> have been experimenting with the behaviour of everything. I'm confused,
> though, when it comes to the concept of allocator framing.
>
> I gather from the DDK documentation that I should be able to declare a
> KSALLOCATOR_FRAMING_EX struct and point to it in my pin descriptor, and
> through it specify what frame sizes my pin's process dispatch can accept.
>
> DECLARE_SIMPLE_FRAMING_EX(PinFraming,
> STATIC_KS_TYPE_DONT_CARE,
> KSALLOCATOR_REQUIREMENTF_SYSTEM_MEMORY,
> 1024, // Frames
> FILE_BYTE_ALIGNMENT,
> 6, // MinFrameSize
> 6 // MaxFrameSize
> );
>
> Now with these requirements specified by my pin, I'd expect to be given
> up to 1024 frames, each of 6 bytes in size, in one call to my process
> dispatch. What I actually get passed is one frame 8192 bytes long,
> clearly beyond the range I specified.
>
>
> Any ideas why the system is ignoring my framing requirements?
>
>
> I've tried specifying much larger frame sizes, but the system still
> passes me 8192 bytes.
>
>
> Help!
>
> Thanks,
> Nick
>

Stephan
Tue Jun 20 12:26:15 CDT 2006

I should add that you definitely won't get 1024 frames of 6 bytes each,
even on the input side.

If this is an audio device you would typically request something like

MinFrameSize = MaxFrameSize = 256(samples)*2(channels)*3(byte per sample)

and Frames = the number of DMA transfer registers your hardware supports

--
Stephan

Stephan wrote:
> The Windows XP audio subsystem ignores the framing requirements of an
> AVStream driver on the playback side. You have to process what you get,
> which are usually audio chunks of 10ms.
>
> The input side of XP (but not W2k) does support the framing requirement
> and will send frames of the requested size.
>
> Some kernel streaming audio applications like Cakewalk SONAR do honor
> the framing requirements for both input and output and will send
> appropriate frames.
>

Nick
Wed Jun 21 04:00:38 CDT 2006

That *is* a very useful piece of information, many thanks!

Stephan wrote:
> The Windows XP audio subsystem ignores the framing requirements of an
> AVStream driver on the playback side. You have to process what you get,
> which are usually audio chunks of 10ms.
>
> The input side of XP (but not W2k) does support the framing requirement
> and will send frames of the requested size.
>
> Some kernel streaming audio applications like Cakewalk SONAR do honor
> the framing requirements for both input and output and will send
> appropriate frames.
>