[wdmaudiodev] Re: Pull mode versus push mode

  • From: "David A. Hoatson" <dhoatson@xxxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 17 Nov 2010 22:08:46 -0800


Here is a strange thought... In pull or push mode the driver is in control
of the buffer size, not the application.  The application suggests a buffer
size, and the driver can modify that an allocate a different amount of
memory.  Why can't it allocate much MORE than the application requested even
in pull mode?  Wouldn't that solve both concerns?

If the streams are going to come and go, ASIO isn't going to be the best
option since you have to tear down the entire driver to add channels.  You
would have to have all the channels running all the time.

Thank you,

David A. Hoatson
Lynx Studio Technology, Inc.

-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Jeff Pages
Sent: Wednesday, November 17, 2010 9:37 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Pull mode versus push mode

Thanks David for your comments and suggestions.

>Even if using push mode, wouldn't the timer interrupt be running for 
>each streaming device?  Doesn't the timer interrupt act just like a 
>hardware interrupt with regard to the CPU state?

From my understanding, the system timer is a single piece of hardware shared
by all the audio engine instances, so in push mode there's only one actual
hardware interrupt per polling interval regardless of how many instances
there are.

>Having written drivers for radio station automation systems in the 
>past, having any glitches in the audio would be a problem for station 
>running 24/7.  Pull mode does give a more 'hardwired'
>connection between the hardware position and the software streaming 
>engine.  It just makes me 'feel better' to know that the hardware is 
>controlling the position instead of the software guessing.

Our cards are radio receivers, principally used for broadcast logging, not
as on-air program source. In any case, though, in push mode it's still the
hardware determining the stream position through its position registers, the
only difference is that the registers are polled asynchronously to the audio
stream. The benefit of pull mode is that it allows smaller buffers to be
used, giving lower latency, but that isn't a requirement here. Provided the
buffers are big enough in push mode to allow for the asynchronous timing,
there shouldn't be glitches, and we haven't had any glitch problems in
systems running on Vista (push mode only).

>Is ASIO an option?  That would give a single hardware interrupt at the 
>bufferSwitch point for all the channels and bypasses everything 
>Microsoft so you don't have to worry about a system sound from an error 
>dialog box interrupting the on-air audio.
>No worrying about something in the streaming engine resampling the 
>audio or having to worry about the two extra limiters that are put into 
>the audio stream whether you want them or not.
>Exclusive mode fixes most of that... :-)  OK, I admit that I am an ASIO 

With one exception, we only provide the hardware, with our customers
choosing whatever recording software they want to use, so unless all that
software was ASIO compatible, it wouldn't be a solution. Also, in the case
of the DAB+ card, the number of stations can vary dynamically as services
are added or removed, and I'm not sure if ASIO would handle that.



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


Other related posts: