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

Newly started stream begins with last 64 samples of previous stream #5

Closed
dechamps opened this issue Jan 22, 2019 · 3 comments
Closed
Assignees
Labels
bug Something isn't working
Milestone

Comments

@dechamps
Copy link
Owner

While doing a loopback test, I noticed that the beginning of the first input block contains what looks like the last 64 samples of the previous stream - basically the remnants of the last stream appear to be leaking into the next stream.

This happens even if the previous stream ended gracefully, and despite the fact that ASIO401 follows the QA401 reset procedure after a stream ends and before the next one starts.

I did not yet check if it's the output side or the input side that's at fault here.

@dechamps dechamps added the bug Something isn't working label Jan 22, 2019
@dechamps dechamps added this to the ASIO401 1.0 milestone Jan 22, 2019
@dechamps dechamps self-assigned this Jan 22, 2019
@dechamps
Copy link
Owner Author

According to @QuantAsylum that's normal behaviour for the QA401 - the correct fix is to end the stream with 32 zero frames. (Actually, it might make sense to make the value of these frames configurable, because that would allow the user to configure the output trim.)

@dechamps
Copy link
Owner Author

dechamps commented Jan 23, 2019

After some more extensive testing this definitely looks like it's coming from the ADC, as I don't see it when measuring the output of the DAC through various other means. The proper fix would be to ignore the first 64 samples we're reading.

@dechamps
Copy link
Owner Author

Weirdly, this doesn't seem to be 100% reproducible. Sometimes I can observe this issue, sometimes I can't, for no apparent reason.

dechamps added a commit that referenced this issue Jan 27, 2019
The main goal of this commit is to work around #9 by getting rid of
QA401::Start(), which is now folded into Reset() so that the QA401
does not get to spend any significant amount of time in a "weird"
"DC party" state.

This required a rethink of the priming logic and of the streaming
loop. The good news is, the new logic is arguably cleaner and
simpler, and it has the nice side effect of taking care of #5
without the need for additional workarounds.

Fixes #9. Fixes #5.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant