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

[Remon Sijrier]

Hi Nicola,

> (Remon: Sorry for the double post, 'reply' always fills in your personal
> address.)

It's kinda weird, I had this behaviour too with kmail, but now by default it 
fills in the mailinglist address....


> > > 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...
>
> Just to clarify: When you write 'gap' do you mean drop outs in playback or
> a delay between clicking and hearing the result? The latter shouldn't be a
> problem, but drop outs or stuttering playback just because solo/mute is
> pressed would be nasty.

The latter one, just a delay between clicking and hearing the result.
But as I explained in the previous mail, I observe a little 'stutter' effect 
when a lot of sources need to be resynced. For some reason it happens that a 
resynced source runs out of data and starts a second resync.
Very odd, not sure why it behaves this way. It occurs only sometimes, not 
always.
Since hard disk usage doesn't vary that much if a couple of sources are muted, 
does it perhaps make sense to keep the sources always in sync?


> > A reasonable hard drive should be able to achieve about 20 MB/s ?
> > That would be about 120 audio files or 60 stereo audioclips.
>
> I experienced some HD overloads on my Samplitude DAW, but only occassionaly
> in huge projects with crossfades. There was probably also some OS related
> HD activity in the background.

I've worked on a naive refiling scheme for buffers. The more empty, the higher 
the priority, which makes the buffer refilled first on a new refill round.
Saturating the hard disk drives bandwidth by a useless grep action gave 
excelent results!
No buffer underrun at all, however when using the solo/mute it again did 
happen that (synced) sources got out of data and started a (re) sync.

I'm using the cfq scheduler from the linux kernel now, the complete fair queue 
(iirc) which you can give a priority on a per proces bases.
I've set the priority for Traverso to max, but I'm not sure if it makes a lot 
of a difference.
At least, it seems to work very well, even when hard disk is saturated by 
another 'application', just the occasional resync of a buffer that just 
finished resyncing in case of a solo/unsolo action.


Thanks,

Remon

P.S.
Note that I'm only testing with about 5-6 stereo sources at this time. I 
should perhaps import some more to make the stress test really a stress 
test :-)