Hi RJ, That's a very nice piece of analysis. The only piece of useful comment I can think of about EngineBuffer is a discussion we had a couple of weeks ago which was just that currently EngineBuffer uses a ring buffer to buffer decoded audio. This is obviously generally a bit unhelpful because any seek outside the last n blocks causes a cache miss possibly all the way back to disk i/o to decode a block of audio. Obviously you can't fight totally random seeking without using loads of memory but we discussed the fact that if EngineBuffer should ever be reworked some day it would be nice to have a more general caching algorithm where we could hint the fact that places like the start of the song, the cue point and maybe some other things are likely to be good things to keep in cache.
Adam 2008/11/20 Russell Ryan <[EMAIL PROTECTED]>: > Hi everybody, > > Just an update on what I've been poking around at. > > I'm trying to figure out how to implement looping, and in the process > I've spent a lot of time staring at how EngineBuffer works. Anybody with > some experience here please do chime in and correct anything I've gotten > wrong or give background/history of some of what is in here. > > I made a brief summary of how EngineBuffer::process works. Interestingly > enough, it actually has some looping code baked into it, and after > looking at it more and more it looks like it might have worked at one > point. Does anybody know if it ever did work? > > Furthermore, there's this 'crossfading' thing inside of EngineBuffer. As > far as I can tell, the crossfading is supposed to happen when you ask > for a beat-synchronized loop so that there is less abrupt jumping > between the end of the loop and the start. Does anybody know the intent > or who wrote the crossfading stuff? (keep in mind, this is inside one > engine buffer, not crossfading between two enginebuffers). > > I'm leaving out some minor details and summarizing some of the parts > there. Basically I'm trying to find a way to split up this beast and > segment whatever is possible into a submodules. EngineBufferCue is a > good example of this. All the cueing stuff happens and the logic/control > objects/state aren't crammed into EngineBuffer. > > If anyone's interested in checking out what I'm working on, I'm doing my > work in branches/Features_rryan-looping > > Also the wiki page for the looping spec is here > http://mixxx.org/wiki/doku.php/looping > > The following is meant for a monospace font, so sorry if it doesn't show > up that way. (I'm sending HTML email in the hopes that setting mono > works). I'll be making a wiki page about EngineBuffer soon. > > Logic summary of EngineBuffer::process(): > > PAUSE-LOCK > READER-LOCK > get file buffer variables from reader > READER-UNLOCK > > - Calculate rate for this section of audio > - start with base rate of audio > - take into account wheel moving > - do scratch rate shifting > > - if rate changed, set it in the scale object > > === do audio processing for this round === > - if rate==0 or at extents then ramp-out > - else (do scaling of audio) > - if not crossfading > - if looping > - do looping using temporary buffer > - scale the temporary buffer using the scaling engine > - else (not looping) > - scale the audio using the scaling engine object > - else (crossfading) > - if crossfade finished > - scale the audio using the scaling engine object > - else > - crossfade in temporary buffer > - scale the temporary buffer using scaling engine > - copy pOutput[i] = output[i] for buffersize > > === update internal state === > - update filepos_play > - detect at_end, at_start > - 'ensure valid range of idx' (idx = idx % READBUFFERSIZE) > - bufferpos_play = idx > > - if we have new reader info (and filepos_end>0 ??) > - Wake reader so it reads more data from the sound file > - Notify listeners of changes (playposition slider, visual waveform) > > - End of Track Mode processing (next-track, loop, etc) > > PAUSE-UNLOCK > > - ramp-out if we just paused > - force ramp-in if previously paused > > Cheers, > RJ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
