Topic: Measure delay to encoder - is my logic correct?

[konnex]

In my case I need the DSPs to run to fill the Push Stream, but this will probably be helpful at a later point in time.
Also I can further optimise this by fixing my “garbage” array permanently, that way there is no need to marshal that in every STREAMPROC callback.

One more thing: What happens if a playing channel “falls behind” or even stalls because of long running DSPs, will that be compensated for by requesting more data? I am asking because I noticed that the Push stream queue was gone after running this for a longer period of time.

[Ian @ un4seen]

One more thing: What happens if a playing channel “falls behind” or even stalls because of long running DSPs, will that be compensated for by requesting more data? I am asking because I noticed that the Push stream queue was gone after running this for a longer period of time.

Yes, when an update cycle is delayed, the next cycle(s) will process more data to catch up. So long as the delay is somewhat shorter than the playback buffer (see BASS_CONFIG_BUFFER/BASS_ATTRIB_BUFFER) then there should be no gap in the playback, as there's still buffered data to play during the delay.