jopohl
commented
6 years ago I guess that you are using some syscall sleep to wait (low precision+kernel scheduler delays), while in the generator the pauses are made by soundcard samples (more precise).
True, the sleep action is not really intended to be used as a precise pause but to wait for external actions to occur e.g. press a button.
The preferred way to solve this would be to make the pauses for messages configurable at sample level in simulator just like they are in generator. I will have a look on this.
Expected Behavior
Using a pause of 4ms should add a pause of 4ms
Using a pause of 27ms should add a pause of 27ms
Actual Behavior
Using a pause of 4ms is not visible in the sent audio
Using a pause of 27ms adds a pause of 10ms (not always, sometimes it's not visible)
I guess that you are using some syscall sleep to wait (low precision+kernel scheduler delays), while in the generator the pauses are made by soundcard samples (more precise).
on windows sleep and GetTickCount has 1ms precision (more or less), to get higher precision there is QueryPerformanceCounter.
But is better to just send many zero samples on the soundcard, unless maybe the precision is not sensitive (delay > 5 seconds?)
My use case: i have this thermometer signal where data is repeated three times and i'd like to send all possible values to check what is actually supported (kind of fuzzing).
but i can't use generator fuzzer since each transmission is repeated three times.
Bonus: auto-add delays in simulator like it happens in generator
Steps to Reproduce the Problem
Add a pause and record the signal using audacity
Platform Specifications
msi, latest version