processBlock-external sample counter?


#1

Hello,
Would there be a variable I can get from within the processBlock function that gives me the/a sample count from the plugin host?
It seems to me this is important, as the way I do it now - counting the samples in that function - would not take into account buffer under runs at a higher level, right?
I’ve looked through the members of the “buffer” argument, but I don’t seem to find anything. Also no luck with a forum search.
~~


#2

I think you are looking for AudioProcessor::getPlayHead()

AudioPlayHead::CurrentPositionInfo info;
if (auto* playhead = getPlayHead())
    playhead->getCurrentPosition();

It fills this struct: AudioPlayHead::CurrentPositionInfo

Some hosts don’t provide that though…

Hope that helps


#3

Thanks very much. That works (I made “AudioPlayHead::CurrentPositionInfo info” a member variable, as not to call that line at each buffer start, not sure if that’s needed though).

Would it be also appropriate to use this variable to calculate the number of buffer underruns (i.e. by also keeping a local counter in the processBlock function and taking the difference between both…), or are there better methods for that?


#4

The problem with that is, that you cannot really know, if there was a buffer underrun, or if the playhead was set by the user.

The only thing I can suggest, if you have a bigger jump, you could add a fade-in to avoid clicks.

Usually the host would keep a record of these events (ProTools does, I don’t know if other hosts expose this metric)


#5

Okay, I see, thanks.
I’m using it for a specific research purpose, with real-time audio input, so the clicking isn’t a problem for me. The buffer-underrun counter should be fine for this specific application then I guess, but if you happen to know of a more appropirate version, I’m definitely curious.


#6

Another thing you can do is to measure the time that your processBlock() took to run, and compare it with the time that corresponds to the number of processed samples at the current sample rate.
If the former is higher, you’re guaranteed to have had a buffer underrun.
If it’s only slightly lower, you may still have had a buffer underrun anyway, due to the overhead of the converters, drivers, etc.


#7

Yes indeed, that’s what I was doing first. But I’m happy to know there is also a possibility to have a counter for all buffer underruns, by subtracting the internally counted processed samples from the playhead-informed processed samples.


#8

I don’t think it’s really the job of a plugin to worry about underruns… It’s the host’s responsibility to do that, and if a particular plugin is behaving badly, it’s the host that should figure out which one and disable/warn appropriately.

A plugin should just keep on rendering the samples that the host asks for - I can’t think of a sensible use-case for it knowing that an underrun has occurred, because even if it could guess that one happened, the plugin can’t know whether it was caused by its own slowness, or by some other plugin or host activity blocking it.


#9

Aha, you’re rigth, there are no regular use cases for that, thanks! That explains why it was difficult to find a way to do it of course!
I need it, as my plugin is for a research purpose and I’m writing results to a file and over OSC from the plugin. As I would like to know if there were irregularities in the process I need to make sure to also keep track of underruns, even if they were not the plugin’s fault…
But indeed, I understand that’s not regular plugin philosophy!


#10

Logically, if you think how the pipeline is processing, once processBlock was called, it will finish regardless. So you can’t drop individual samples to catch up. Your counter will not show useful information.
What happens instead is, that the driver was reading the buffer too soon and got a crippled audio, without you knowing anything about it.
Depending on how the host is implemented, maybe the PlayHead isn’t even advancing when that happens, so your counter is still showing as if nothing happened…