On Thu, 26 Aug 2004 zmoelnig@iem.at wrote:
Ah, sorry then. I have to admit that I haven't used that for a long time, and I could vaguely remember that in order to get a waterfall display with the new pix2sig you had to use a large blocksize with overlap, which in theory should reduce the performance "overlap" times.
i don't quite understand the last sentence.
hmm, thats probably because it isn't really understandable, sorry :(
I really can't remember exactly, but I had the feeling that in order to achieve the waterfall effect you had to use a certain overlap factor. This makes it slow. I don't think that the conversion from float to int at a rate of 44kHz can do the performance much harm.
On the other site, the original sig2pix external was optimised for just doing that, a waterfall. This was done by having a buffer twice as large as the image and filling this with the audio data, line per line. Each time a new line was added, the image scrolled by one line. This was done by repositioning the image pointer only. Each turn around there was an additional copy of the whole image.
Well, probably something like this should be called pix_waterfall~ already.
Guenter
however you are right; [pix_sig2pix~] uses huge blocks which will get peaks in performance.
mfg.ca.srtz IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev