Menu
▾
▴
[Linuxsampler-devel] Re: qsampler , buffer fill pecentage methods
|
From: <be...@ga...> - 2004-05-16 13:55:09
|
On Sat, 2004-05-15 at 14:39, Rui Nuno Capela wrote: > > I'm working on something that works in the first place; whether it's nice > > it's kind of subjective ;) > > > > But,... tada... I have already something that you can look at: > > > > It's qsampler! Hi Rui, compiles fine, indeed nice work :) I think once LS stabilizes, GIG engine gets tuned and the GUI works and an all in one tarball will be released the userbase will grow fast. (since qsampler is our official GUI so I suggest when we will decide to release the first alpha or beta tarball to put everything in package that's easy to compile or even make some binaries). A question about the handling CHANNEL BUFFER PERCENTAGE LSCP commands in GUI. Since this command returns all the buffer fill percentages relative to one single channel and the channel has only one fill status bar (which is the right thing to do), I think the best way to display the buffer fill data is computing the percentage of the least filled buffer. And then display this in the horizontal bar. That way if we have 20 active voices on sampler channel 1 we always see the status of the most empty buffer, which makes sense since we don't care if all others are filled because they are not going to cause eventual troubles in high load situations. About the buffer fill status messages. I'd like to ask you guys an opinion how LS should construct them. As we know each sample consists of a RAM part, usually 32k samples which is played when the note is started. At the same time a stream is created and the disk thread starts reading data from disk and filling the associated ringbuffer. As soon as the RAM part of the sample got played, LS seamlessly switches to the ringbuffer and reads the samples to output to the audio card from here. The main purpose of these buffer fill bars are to give the user visual feedback if there are bottlenecks during the playback which is caused by buffers which are too filled with too less data which poses a high risk of a voice dropout. There are multiple ways to interpret the buffer fill status. 1) simply return the percentage of filling of the ringbuffer associated to the (disk based) voice, regardless if the voice is in RAM or disk playback mode. This is not optimal since as soon as the voice is started, the ringbuffer is created and will have a 0% fill status and the GUI since it always displays the lowest value associated to a sampler channel will display 0% which could mean that there is a problem (but in effect there isn't any problem). In this mode the buffer fill bar would constantly jump back and forth everytime new notes are started. So I'd say let's forget about this mode since it does not offer useful information to the GUI user. This is the method currently used by LS see String DiskThread::GetBufferFillPercentage() in Stream.cpp 2) return the percentage of filling of the ringbuffer associated to the voice but only return a value if the associated voice is in disk mode. So basically during the RAM playback no buffer fill percentage is sent even if the ringbuffer was already created and it's currently getting filled with data readed from disk. Over method 1) this method has the advantage that it shows only the fill percentage when in use so as soon as the voice switches to disk playback it shows how much headroom we have in the buffer before we get a dropout. This is ok but still not perfect since voice dropouts could occur because the system is under high load and while the RAM part of a voice is played the disk thread does not fill the associated ringbuffer in time so when the voices wants to switch to disk playback no data is ready in the ringbuffer. So in order to have feedback about the worst case "buffer head room", we need to take into account RAM preload bufffers too. See the next method 3) while the voice is in RAM playback mode return a buffer percentage based on (RAM preload size - playback position) + ringbuffer fill percentage Let's make an example: mono sample we preload 32k samples , ringbuffer 128k samples. When we start the note playback begins from position 0 of the 32k RAM preload buffer. So we return 32k/128k = 25% Assume the disk thread takes a while to read the data from disk. RAM playback has advaced to position 8k (in samples). So according to the above equation we return (32k-8k)/128k=24k/128k = 18% Now assume playback has advanced to position 12k but the disk buffer meanwhile contains 40k of samples so we return (32k-12k+40k)/128k = 60k/128k = 46% As soon as the ram playback finished and the voice switches to disk playback. In this more we return only the ringbuffer fill percentage because the RAM part is not accessed anymore and does not contribute to the total "buffer headroom" which describes the number of samples wich equals to a certain headroom time (just divide by the samplerate). So when we play a single note we see first the buffer fill bar dropping to 25% and then go down a bit and then quickly go up to almost 100%. If we have sequences of notes we see that at each note on the buffer drops to 25% or below (since the RAM part is 25% of the ringbuffer size). but if it starts to drop well below the 25% during high polyphony passages then in means that active ringbuffers are very empty and this could signal to the user potential bottlenecks. (which can in some cases be solved by increasing either RAM preload or ring buffer sizes). I think mode 3) is the best for the user of the GUI since it always shows how much headroom LS has during the disk streaming. What do you think guys ? As said as a user I want to know how much headroom (in terms of buffer time) the streaming engine has during high polyphony situations and I think method 3) is the best way to give the user this real time feedback. Keep in mind since LS has uses the same ringbuffer sizes for mono and stereo, but the preload sizes are twice as big for stereo samples (otherwise stereo samples would risk causing dropouts since they use twice the buffer space per time unit compared to mono samples), if we take the above example, a stereo samples preloads 32k stereo samples = 64k mono samples which is 50% of the 128k samples that the ringbuffer holds. This would mean that during note ons this buffer size (using method 3) would jump pack to 50% (instead 25%) giving the user even better visual feedback. But even with 25% in case of mono samples the user has good feedback if things are ok or if sh*t is about to happen :)) let me know. cheers, Benno http://www.linuxsampler.org he only thing that LS must take care of when sending these messages is (I haven't looked at the code that emits these messages yet so I could say nonsense). ------------------------------------------------- This mail sent through http://www.gardena.net |
