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

[Remon Sijrier]

Hi,

> > I've loaded 6 stereo and 24 mono files at the moment.
> >
> > The 'stuttering' effect happens almost always now when unsoloing, which
> > isn't nice. The buffer size doesn't matter much, even with large buffers
> > the effect also appears, perhaps I'm doing something wrong....
>
> Hm, any idea where the bottleneck is? 

Yes, I found it, was a subtle bug [1]. On a project of this size, there still 
is the problem of certain (resynced) buffers getting out of data (again) but 
I think the refill scheme can be made a bit better then it is now.

> If it's the HD bandwidth it should be 
> smoothed out by larger buffers. 

Although that might seem logical, larger buffers also _increase_ throughput 
and will trigger bandwidth saturation much easier....
It seems that smoothing out of a large number of resyncs should be done over 
time and not with larger buffer sizes.
This is what I'm doing now, a rather relaxed refill of the buffers, one at a 
time, and then restarting the process to see if 'online' buffers need refill 
first.

> How about the cpu? Are you still working on 
> your 800 MHz system?

Reading/writing data to harddisk is an I/O bound task, that is, its a process 
which most of the times wait (on the hard disk to do it's job in this case). 
CPU usage isn't a problem, reading and mixing 36 channels (the equivalent of 
16 stereo sources) only consumes ~ 17 % CPU here :-)


> > Also, using larger buffers makes seeking on this kind of projects take a
> > long long time :-(
> > Even when using a buffer size of only ~ 0.7 second of buffering (== 128
> > KB buffer @ 44100 Hz)
> >
> > Anyways, it would be nice to know if ~ 36 channels would count as a large
> > project.
>
> I would say it's very large, 

OK, then I'll keep it as a 'worst case scenario' test and see if I can improve 
the buffer filling scheme in such way no resyncing will happen, or at least 
almost never ;-)

> but keep in mind that often 24 bit wave files 
> are used for recording (44100 Hz / 24 bit is rather popular).

Actually, those 36 audio files are 32 bits (float) hehe

Greetings,

Remon

1. When multiple threads access a variable, the reading/writing of the 
variable should be atomic. The type size_t has (at least on linux) atomic 
read/write behaviour. I overlooked this, and was using a bool type.
Changing it to size_t solved the problem :-)