On Monday 20 November 2006 10:49, Cesare Marilungo wrote: I second that comment An this one, too :) Flo -- Palimm Palimm! http://tapas.affenbande.org

On Tuesday 21 November 2006 18:50, Fons Adriaensen wrote: I assume you're using SDL. If you can, try OpenGL, that should take most of the work off the CPU. Apart from that... well, redrawing the entire window, 50 times a second by default, is expensive (although I'm sure there's a lot of room for optimization). Depending on what you're trying to do, a lower frame rate might suffice, and reduce the CPU load significantly. Another thing you could try is to change both occurences of SDL_HWSURFACE in video.h to SDL_SWSURFACE. Does it make any difference? On my machine it doesn't, so I wasn't sure what to use. Also note that currently, even in non-scrolling mode, jack_oscrolloscope redraws the whole window on every frame, because was easier to implement. Changing that is somewhere on my todo list :) Dominic

On Tuesday 21 November 2006 21:42, Fons Adriaensen wrote: Well, this flag is not used in GL mode, so it's no surprise that it has no effect there. But it looks like I should be using software surfaces in SDL mode. Do you have hardware accelerated OpenGL at all? Software emulated GL can be dog slow (much slower than SDL), that's the main reason why I added SDL support in the first place. For comparison, on my machine, with 12 tracks, fullscreen 1280x960, I'm getting about 30% CPU load using OpenGL. That's with an Athlon XP 3000+ and a cheap, 4 year old, passively cooled Nvidia card. Wow, 1%?! Is that using plain X11? Sounds almost too good to be true. I think it goes without saying that I'd be interested in seeing your code ;) Dominic

On Wednesday 22 November 2006 02:37, Reuben Martin wrote: Huh... This is weird. Does vsync work for other programs? try this as a normal user: __GL_SYNC_TO_VBLANK=1 glxgears -printfps It should print exactly the vertical refresh rate of your monitor. If it doesn't, there's probably something wrong with your driver setup. I don't mean to shift the blame on others ;) But this sounds a lot like a buggy driver. I too have seen one or two complete lockups while resizing the jack_oscrolloscope window. I guess that's what you get for using a binary driver on a -rt kernel it wasn't made for... Dominic

On 11/22/06, Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote: Yes, the key to fast (efficient) scrolling is to use a pixel copying routine (glCopyPixels is the GL equivalent) then draw only the new data. The copying routines are hardware accelerated by the display driver. The downside is that it is difficult to overlay drawing into this area that you don't want scrolled, which might be why freewheeling doesn't use the technique (I'm just guessing). jlc

On 11/22/06, Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote: Oops, you're right, I even do this in FreqTweak :) jlc

On Wed, 2006-11-22 at 11:59 -0500, Rick Wright wrote: it is a widely adopted convention that any floating point format normalizes the sample data to a -1.0 .. +1.0 range. doing so loses no precision or resolution or dynamic range. this applies to 32 bit and 80 bit float (there is no 64 bit floating point format, no matter what various windows audio s/w makers may claim in their advertising). if you violate this convention, you will get the results you are seeing. --p

On Wed, 2006-11-22 at 18:56 +0100, Leonard "paniq" Ritter wrote: the truly precise range is limited to the width of the mantissa: N bits, where N is fixed depending on whether its a 32 bit float or an 80 bit double. you can use those N bits anyway you want: you've got a signal that varies between zero and the maximum voltage handled by a given D/A converter, and you've got 2^N (plus or minus 1) values to represent them with. you've got choices about how you use them: a) just use 16 bits of the mantissa, and fix the exponent bits (-32768...+32767) b) use all 24 bits of the mantissa, and fix the exponent bits (-2^24 ... + 2^24 - 1) c) use all 24 bits of the mantissa, and vary the exponent bits (-2^24 ... + 2^24 - 1) * 10^{0...7} d) use a normal floating point representation e) use all 24 bits of the mantissa but with normalized values, which implies varying the exponent there are more. (a) is similar to the case you were describing, and it has only 16 bits of resolution for the non-summing mixer situation. kind of a waste of 8 bits, no? its only benefit over 16 bit values is that if you sum them and the answer > 2^16 - 1, you don't clip, you just get the potential for a small amount of distortion. the way to get this into your head, or at least the way i got it into mine, was to forget the idea of associating specific numbers with bit patterns in the floating point representation. just think of there being a set of 2^24 - 1 ordered bit patterns, each one of them representing some analog signal level. depending on what you do with the exponent bits, these bit patterns could be thought of as representing integer values between 0 and 2^24, or between -2^24..+2^24-1, or floating point values between -1 and +1, or many other ranges, or nothing at all. --p

On 11/28/06, Dominic Sacré <dominic.sacre(a)gmx.de> wrote: You can easily make it without FBO: update only one row in texture at a time (it's more efficient than a column) and use texture matrix for scrolling. This way it will work fast even with software opengl. Regards, Dmitry.