Re: [Traverso-devel] Behaviour of mute/solo

[Remon Sijrier]

Hi,

> Am Freitag, 22. September 2006 16:00 schrieb Remon Sijrier:
> > The question however is, what should be prefered?
> > A (relatively) small optimization by not syncing 'silenced' AudioClips,
> > or a slightly better user experience by not having a 'lag' after an
> > unsolo/mute before the audioclip is 'audible' again.
>
> Is it just the position of the play cursor that would be kept in sync? 

My original intend is to keep the buffers in sync with the play cursor.
This means that the only thing an AudioClip does when it is muted/soloed is 
reading in the audio data from hard disk, and doesn't do any further 
processing.

> Or 
> would all real time effects be processed, but not played back? What is
> important IMO is that all sound processing steps of muted tracks are
> bypassed in order to save cpu consumption. 

Thats one reason why I like to have an 'active' state for audioclips, saving 
cpu cycles.

> The gap between switching and 
> hearing the effect is no problem IMO, 

For small projects, the gap would be very small. However, if you have a large 
project, the gap becomes bigger and bigger since more time is spend to fill 
all the buffers...

> but it should be possible to reduce 
> cpu *and hard disc* usage by muting certain tracks. This can be handy when
> working close to the limit of cpu and disc performance.

I think the cpu limit can be reached much more easily then saturating the hard 
disk, but I could be wrong of course.
When using a 44.1 KHz audio file, the byte rate is:
44100 * 4 = 176400 bytes / second
(float == 4 bytes)
or 0.168 MB/s
A reasonable hard drive should be able to achieve about 20 MB/s ?
That would be about 120 audio files or 60 stereo audioclips.

(if it can do better, you should keep in mind that seek time reduces overall 
througput by quite a bit, so 20 MB looks like a good guestimate.
Looking at a setup of 5 stereo files and the _time_ spend on filling the 
buffers, my  hard disk should be able handle ~200 files or ~100 stereo 
audioclips at a time....(seagate 7200.8))

A side effect I observed is that when you solo a track and say 10 buffers get 
out of sync, unsoloing the track starts a rather massive refill of those 
buffers, which potentially could cause buffer underruns, _specially_ if the 
hard drive bandwidth is close to becoming saturated ;-)


> > The buffers size will become user configurable btw.
>
> That's great, as the setting is heavily dependent on hardware performance
> and type of project (e.g. many tracks vs. a stereo project).

I've been fidling with the buffer size, and well, to make it an option seems 
like a userfriendly thing.
But larger/smaller buffers doesn't garantuee better overall behaviour, so it's 
more to make it possible to adjust the memory consumption of Traverso on 
certain types of projects :-)
And indeed, one type of buffer size could do perhaps a better job on certain 
hardware then another buffer size, so thats also the reason why I made it 
user configurable.

To summarize:
* keeping buffers in sync gives no lag when un-solo/mute, and reduces the 
chance of a buffer underrun when hard disk reaches saturation, but users 
could start to wonder why the hard disk keeps busy when all tracks or muted 
hehe
* not keeping them in sync reduces a little on cpu and disk usage, with a bit 
higher chance of buffer underrun when the hard disk is close to saturated, or 
when a large amount of buffers suddenly get synced.

At least, those are my experiences so far during my attempt to tweak the 
(re)fill of audio buffers..


Greetings,

Remon