On Tue, 2007-05-08 at 18:37 +0200, Steffen wrote:
Marius also ends out with some explanation of the 'block' concept. I
think that what i don't really get.I understand that decreasing the block size will possible requirer
more computation/logical time then there is real time enough to
complete.
what do you mean by computational time? logical time and the time, the cpu needs to compute something are not the same.
And therefore that the information in a block is available
to the program to process. Which also means that after that block has
been processes the information is not longer available. Is that true?
i am afraid, i couldn't fully follow. i'll try to explain it in my own words and hope that i don't tell too much rubbish, cause this is only what i assume, how things are:
a block is a number of numbers, in pd these numbers are 32bit floats. the usual blocksize is 64samples(=floats). audio signals are passed blockwise between tilde-objects, that means a tilde-object receives 64 floats on its inlet, then processes all 64 samples and then sends them to its outlet. this happens each tick for the whole dsp tree. each tick, a whole block is processed by the first object, then passed to the next object, processed by this object, passed to the next and so on. i assume, the cpu overhead, when decreasing the blocksize, comes from the communication between the tilde objects. if the packagesize is smaller, more packages need to be passed to process the same amount of data in the same time, so more exchanges between tilde objects are needed. every tick, the 'message tree' is processed as well. so, in logical time, messages always 'happen' at block boundaries. for example, when a number is sent to the left inlet of an [osc~], the [osc~] changes its frequency exactly on the blocksize boundaries. so, in logical time, messages take effect only every 1.45ms (when running pd at 44100Hz). in real time, you can't tell when exactly something is processed, it can vary between immediately and the maximum of your soundcard buffer setting. the sound card reads the samples from the buffer at a fixed rate (the samplingrate), whereas pd does fill it at a speed, that depends on the cpuload. although pd does compute things at nondefined times, the output (of your soundcard) seems well timed, because pd puts the samples in the right order into the buffer.
What is a block, what's in it, what properties does it have. Is a
block a sample or is a block made out of a number (being the block
size) of samples? And also Jamie's question: what does the 'v' stand
for?
i think, in [vd~], it stands for 'variable' (delay). i don't know, what it means in [vline~] and [vsnapshot~], vector maybe, because the messages, they receive can have an effect within the vector (read:block), not only on block boundaries. these two objects are special, because when they receive a message, that was initally triggered by a [del] or a [metro], it has an effect within the block, because the messages generated by [del][metro] are tagged with some timestamp (is that correct?), so that [vsnapshot~]/[vline~] know, for which exact time they are meant to be executed.
if i understood IOhannes correctly, he said, that other 'translations' from pd to the 'real' world beside sending data to an audiocard cannot be timed accurately, since they lack a fixed rate, like an audiocard has it. for example, if you are talking to an arduino board, it will process the data as soon as it gets it. so if the cpu load is currently a bit higher, it will get the data probably a bit later, than when cpu load is small (is that right, IOhannes?). let's say i am running pd with a buffer of 100ms and the patch switches often between high and low cpu-load (for example it does load some audiofiles into arrays from time to time). would that mean, the maximum jitter of the arduino outputs is 100ms, although i don't have any dropouts in the audio? is that correct?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de