Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SYSVAD Render Exclusive Mode cannot work !? #255

Open
vburel2018 opened this issue Jul 2, 2018 · 0 comments
Open

SYSVAD Render Exclusive Mode cannot work !? #255

vburel2018 opened this issue Jul 2, 2018 · 0 comments

Comments

@vburel2018
Copy link

vburel2018 commented Jul 2, 2018

When testing SYSVAD by sending audio to Speaker in WASAPI exclusive mode, the generated file is not correct (noise is added).

If analyzing the method used in minwavertstream.cpp, we see no way to get something working.

When sending audio to SYSVAD Speaker in exclusive mode, the function CMiniportWaveRTStream::AllocateBufferWithNotification is called

REM: it makes no sense to test if the buffer size is multiple of NotificationCount_ (2) while the buffer is expected to be multiple of m_pWfExt->Format.nBlockAlign
if ((NotificationCount_ == 0) || (RequestedSize_ % NotificationCount_ != 0))
buffer size must be converted in sample before...

Anyway, the method is expected to be simple: AllocateBufferWithNotification is called to allocate a buffer multiple of 2 (NotificationCount_ ) in order to be able to manage the entire DMA Buffer in 2 equal size buffers to make a simple double buffering process: while one process is reading a buffer, the other process is writing in the second buffer...

However this method is not implemented correctly.
First because the buffer timing is wrong per definition m_ulNotificationIntervalMs introduces a jitter of 0.99 ms in the buffer duration

In this render exclusive mode the function TimerNotifyRT is called every ms to check if a notification must be sent, that we could call the “buffer swap”. But the condition is wrong by design:
if (TimeElapsedInMS < _this->m_ulNotificationIntervalMs)

the first buffer is surely not finished at this time, because missing up to 0.99 ms… it means there is no chance to be sure that the HALF DMABuffer is processed at this time.

Secondly because the timer does not survey any position regarding the DMABuffer management: nor m_ullPlayPosition (managed by UpdatePosition()), nor m_ulCurrentWritePosition (set by SetCurrentWritePosition by the system I guess).

So, how this example of code could work? Did anyone test this mode successfully yet ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant