HydrogenAudio

Hosted Forums => foobar2000 => Development - (fb2k) => Topic started by: elventear on 2004-07-15 10:49:53

Title: chunk size for DSP plugins
Post by: elventear on 2004-07-15 10:49:53
Hello,

How is the chunk size determined for audio_chunk object? Is it possible to know the chunk size before processing (on_chunk calling)? For instance for some declarations on the constructor of the object?

Thanx!
Title: chunk size for DSP plugins
Post by: Garf on 2004-07-23 17:46:20
You must be prepared to handle any size. The DSP in front of you can output chunks in whatever size it pleases.
Title: Re: chunk size for DSP plugins
Post by: mero on 2019-10-24 15:52:38
Refreshing this old topic to get more info.

Now from the perspective of the developer of that first DSP, should he care about the size of the chunks he/she inserts? Either as a courtesy for the next DSP or for the overall performances?

In my case I may buffer like 1 minute of audio. In some case I want to release it all at once and wonder if I should bother splitting that minute in smaller chunks of say 1024 samples or just insert the full thing at once?

I would say that insert_chunk may fail when allocating on the fly such large buffer but I prefer to check.

Cheers
Title: Re: chunk size for DSP plugins
Post by: Case on 2019-10-24 16:35:39
Everything is expected to handle large chunks so there should be no need to split it. That is also the way every first party component releases buffered contents when requested (happens on DSP setting change).
I don't think worrying about allocation here is necessary. For example quite extreme 192 kHz 6 channel audio would only require 264 MB of memory for a minute.
Title: Re: chunk size for DSP plugins
Post by: mero on 2019-10-25 14:35:41
"only require 264 MB" ! I have to get used to writing code for PCs where there is just too much memory !

Thanks for the answer.
Title: Re: chunk size for DSP plugins
Post by: lvqcl on 2019-10-25 14:40:38
There are also people that like to resample everything to 705600/768000 Hz. Higher is better, right?