[wdmaudiodev] Re: SYSVAD source code has changed , not for the best.

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 31 May 2018 06:36:53 +0200

In fact it’s the m_ullLinearPosition that should directly work as a buffer
offset

If (m_ullLinearPosition >= m_ulDmaBufferSize) m_ullLinearPosition -=
m_ulDmaBufferSize;

UpdatePosition Function needs to be re-designed to avoid DIV too… 

There is a big confusion in this part of code… 

while it should be simple and clear. 

Regards

Vincent Burel

 

De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Vincent Burel
(VB-Audio)
Envoyé : mercredi 30 mai 2018 20:59
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: SYSVAD source code has changed , not for the best.

 

I’m sure to have seen the other source code in 2018, but Google might have
routed me to old GitHub… 

So in 3 years, there is no one to point the problem in the SYSVAD source
example ? J

 

Division is not used in DSP or Audio Real time programming (except if
obliged – in rare cases – some DSP has even not the DIV instruction
available). 

 

So Why using division taking 30 or 40 cycles when you could just spend 2 or
3 cycles by a simple code like this below? 

ULONG bufferOffset = m_ullLinearPosition;

If (bufferOffset > m_ulDmaBufferSize) bufferOffset -= m_ulDmaBufferSize;

 

Regards

Vincent Burel

PS: Someone can tell us the energy required to  perform 40 cycles, 100 time
per second,  on 2 billion computers, running 1 audio driver with 2 streams ?


 

 

De :  <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx [ <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Tim Roberts
Envoyé : mercredi 30 mai 2018 19:13
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: SYSVAD source code has changed , not for the best.

 

Vincent Burel (VB-Audio) wrote:

  

SYSVAD Sample Code changed since January 2018 and I don’t know why , except
to bring confusion !?

 
<https://github.com/Microsoft/Windows-driver-samples/blob/master/audio/sysva
d/EndpointsCommon/minwavertstream.cpp>
https://github.com/Microsoft/Windows-driver-samples/blob/master/audio/sysvad
/EndpointsCommon/minwavertstream.cpp


This code did not change in January 2018.  All the code in WriteBytes today
was added in July 2015 with the Windows 10 WDK.  You can do a "git annotate"
to verify that.  You have to go back to the Win 8.1 WDK to get the old
behavior.

However, I agree with you that the philosophy here is utterly confusing.
How can the displacement be so large as to require many loops?  If we've
overflowed the DMA buffer, then we're screwed anyway.  Might as well
generate silence.




VOID CMiniportWaveRTStream::WriteBytes( _In_ ULONG ByteDisplacement) 

{

    //this first line just says “I’m not a DSP programmer, I’ve no clue
about real time general rules”.

    ULONG bufferOffset = m_ullLinearPosition % m_ulDmaBufferSize;


Why, because of the %?  Integer division on a modern processor takes no more
than 30 cycles, and usually less, depending on the number of non-zero bits.
It's not worth worrying about.




    // this comment below is just incredible ! 

    // Normally this will loop no more than once for a single wrap, but if

    // many bytes have been displaced then this may loops many times.

    while (ByteDisplacement > 0) 


Agreed.  This really needs notes about the philosophy, and how this could
happen.  It was mostly because of this confusion that I abandond SYSVAD and
went back to MSVAD for my recent virtual audio driver project.




    {

        ULONG runWrite = min(ByteDisplacement, m_ulDmaBufferSize -
bufferOffset);

        m_ToneGenerator.GenerateSine(m_pDmaBuffer + bufferOffset, runWrite);

       // again a fucking div for what ? or BufferOffset goes back to zero
or its finished

        bufferOffset = (bufferOffset + runWrite) % m_ulDmaBufferSize; 


To replace this, you'd have to introduce a comparison and a jump.  I'm not
sure that's better.

-- 
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

Other related posts: