libvisual
libvisual copied to clipboard
Libvisual
actor_jakdaw, actor_lv_scope: waveform glitch
Somehow the waveform is distorted (maybe due to a buffering issue). With input_debug it shows as small "spikes" that break the waveform that should be a perfect sine (attached screenshot showing enlarged portion of waveform rendered by lv_scope & jakdaw):
Closing this as it's a side-effect of the way actors use a fixed size input buffer.
reopened until actually fixed. Even if this is related to another issue (which one exactly?) it's a seperate bug. Those two issues can be closed at the same time when they have been fixed.
Just to elaborate, this is not a bug or limitation with the audio input system. Almost all the actors draw their input data from a fixed size buffer. The problem occurs when some of them apply a wraparound when they need more samples. The number of samples for a single frame may also vary depending on frame dimensions.
One solution is to read as many samples as necessary for a 'smooth' waveform, and pad with zeros when there are insufficient samples.
whether this is a bug or not I wouldn't like to discuss. I think it's nasty and in case of a DFT taken of the glitchy waveform, it produces wrong results. I don't really like the idea of padding an incomplete waveform with zeroes. It would be much better to provide the correct waveform and thus limit the possible framerate/maximum resolution/amount of samples per frame
For certain kinds of actors, there will always be frames where there are insufficient samples, given large enough dimensions. You can either wrap, scale, or zero pad.
i'd say there is a sane limit. Why would an actor, say, render 5 seconds of samples in one frame? I think the best would be to "pad" with old samples and thus buffering (according to the size of the last request). So if an actor requests 1024 samples but only 800 are available, deliver 224 old samples and append the most recent 800 to them. Only if there are no previous samples, pad with zeros.
One more thing: the DFT should be unaffected by the 'glitch'. As mentioned, the issue is with individual actor code using fixed size buffers and applying wraparound, not LV core. Where DFT is applied by the actor, it is applied on the buffer.
The right solution is actor specific. However, LV core can provide some support in the form of zero padding for cases where the actor requests for more samples than what's available.
So far it seems that only lv_scope and jakdaw are affected by this. This is an actor specific problem, so this issue needs to be retitled.