Open fengalin opened 6 years ago
Instead of using flags indicating whether the WaveformBuffer
has already been handled, it should be possible to use dedicated Buffer
queues for each WaveformBuffer
. Buffer
s memory would not be duplicated and each buffer would pop buffers from the queue and the reference counting mechanism would take care of releasing memory when possible.
While it should be possible to avoid copying the gst::Buffer
s, we are bound to keeping the history mechanism as we need it to render with new sample steps after a zoom in / out.
The
AudioBuffer
/WaveformBuffer
design is now pretty close to the point where it would no longer be necessary to keep up to 30s of samples inAudioBuffer
. When a seek back is performed, a mechanism allows holdingWaveImage
rendering until enough samples are available. This means that we could also remove the code that deals with merging existing samples with incoming ones.Considering that, current design could transition to this:
AudioBuffer
and theWaveformBuffer
s /WaveformImage
s. Add the incomingGstBuffer
to theAudioBuffer
'sVecDeque
with flags indicating whichWaveformBuffer
has already handled the buffer.VecDeque
and mark it has not handled yet.On the
DoubleAudioBuffer
could select whether or not to swap theWaveformBuffer
s depending on the last buffer handling status. Current working buffer could be filled (converting samples to pixels on the fly) until the exposed buffer window range becomes too short, marking the buffer as handled by the working buffer, then theWaveformBuffer
s would be swapped. When a buffer has been handled by bothWaveformBuffer
s the buffer is dropped.This would avoid copying samples in the
AudioBuffer
(we would just get a reference on theGstBuffer
) saving CPU cycles and memory. The only new cost would be induced by the double conversion samples -> pixels. It should be possible to use SIMD to handle multiple samples at once (either several channels or several consecutive samples at once).