After talking on Skype:
Solution is to make parameter ResetTimeNeeded_MAX (current 30 seconds, which means that after 30 seconds of having a huge delay in the output, the thing resets) configurable. So you can set it to - say - 0.1 seconds to make it reset immediately whenever this occurs. Or keep it at a high value if cutting audio is not acceptable (for example for radio stations).
Basically, the black bar in the input sound card blue bar in the Stand Alone version means:
- Hey, I'm receiving input data and nobody is processing it.
That occurs when the CPU load is high - the input gathering is done at a higher priority, processing is done at normal priority.
Basically, the idea is that after the high CPU load, the processing can catch up, and hiccups are not noticeable because there is a big enough output buffer.
However, when watching Youtube videos on a Netbook, you want a very very short output buffer, so basically any browser action would cause hiccups. And after such a hiccup the audio should be synchronized with the input (without extra latency) as soon as possible. (Also, because there is no big enough output buffer, there's no way the output buffer would hide the hiccup anyway).
My 'gut feeling': For LOW LATENCY use, the ResetTimeNeeded_MAX should be just slightly higher than the output buffer size. For NORMAL LATENCY (radio station) use, it should still be high.
So the easiest solution would be to add a button to reset as soon as possible when needed, which would then look at the output buffer size.
Edit: NO, I should automatically check whether the output buffer COULD fix the issue. If that's completely impossible, for example because it is already completely empty, I should just reset the input as well. I'm not completely sure of this though.
Edit 2: NO this is not true. Windows also can have a buffer of upto 300 ms which I cannot detect at all. And maybe some people don't mind the hiccups as much as loosing audio. So this should still be configurable
