25 Sep
2002
25 Sep
'02
12:40 p.m.
Sorry, this is not directly audio related.
I'm hacking together a VU meter app for jack, using FLTK, and it works OK,
except that when the update rate falls out of sync with the video refresh
rate the window flickers. I'm pasting a bigass image as the background,
see screenshot http://inanna.ecs.soton.ac.uk/~swh/vu-ss.png (apologies
for the tacky brushed steel background, its a placholder, honest).
I seem to remeber that on the Amiga and in GL I could issue a call to wait
for the next vertical blank, forcing the redraw to be in sync with the
video hardware. Is there an equivalent in FLTK or X?
How do other people get round this?
Cheers,
Steve
PS I know a VU meter in a PCM system is about as much use as an underwater
hairdryer, but its a stepping stone to a PPM meter, and you can run it
in peak mode, but with a VU scale and balistics.
25 Sep
25 Sep
1:20 p.m.
Hi,
Steve wrote:
I'm hacking together a VU meter app for jack,
using FLTK, and it works OK,
except that when the update rate falls out of sync with the video refresh
rate the window flickers. I'm pasting a bigass image as the background,
see screenshot http://inanna.ecs.soton.ac.uk/~swh/vu-ss.png (apologies
for the tacky brushed steel background, its a placholder, honest).
I seem to remeber that on the Amiga and in GL I could issue a call to wait
for the next vertical blank, forcing the redraw to be in sync with the
video hardware. Is there an equivalent in FLTK or X?
How do other people get round this?
I am not sure how exactly you are doing this, but my first guess would
be to ask if you are rendering into an off-screen pixmap (until
everything in there is finished) and then do one quick Blt() to bring
this to your on-screen window. That should at least keep the flickering
low.
I am not sure if there are still ways to wait for vertical retrace
nowadays, but even if there are, I imagine it would not make sense,
given the overhead/latency the X protocol will put between the beginning
of the VBL and your attempt to draw things onto the screen "right at
that moment".
Hope that helps,
Frank
--
Frank Neumann (Frank.Neumann(a)st.com), VIONA Development Center
STMicroelectronics, Karlstraße 27, 76133 Karlsruhe
2:15 p.m.
Frank Neumann wrote:
> I seem to remeber that on the Amiga and in GL I
could issue a call to wait
> for the next vertical blank, forcing the redraw to be in sync with the
> video hardware. Is there an equivalent in FLTK or X?
>
> How do other people get round this?
i'd look at the GL kernel support sites, they might have a patch that
creates some sort of a '/dev/retrace', or add it to GLX. with vanilla
linux/X there's no way to do this except busy-wait reading inb
(0x3da) afaik.
but you certainly don't want to do this.
I am not sure if there are still ways to wait for
vertical retrace
nowadays, but even if there are, I imagine it would not make sense,
given the overhead/latency the X protocol will put between the beginning
of the VBL and your attempt to draw things onto the screen "right at
that moment".
you can't draw whenever you want to anyway because jackd and fellows
need to run 'before' the gui unless stalling the audio processing is
ok or the frag size is large enough (and the gui well-mannered).
tim
2:47 p.m.
On Wed, Sep 25, 2002 at 06:12:31 +0200, Tim Goetze wrote:
There is a copy-on-next-vert-refresh call in X, I think. Part of the dbe
extension.
I dont think I can use it with FLTK though, as I can't find a way of
drawing onto an non-screen surface and then using the dbe.
Its probably just a bad choice of toolkit. GDK and SDL seem to be able to
do it.
- Steve
> I seem to
remeber that on the Amiga and in GL I could issue a call to wait
> for the next vertical blank, forcing the redraw to be in sync with the
> video hardware. Is there an equivalent in FLTK or X?
>
> How do other people get round this?
i'd look at the GL kernel support sites, they might have a patch that
creates some sort of a '/dev/retrace', or add it to GLX. with vanilla
linux/X there's no way to do this except busy-wait reading inb
(0x3da) afaik. 
3:15 p.m.
Steve Harris (S.W.Harris(a)ecs.soton.ac.uk):
On Wed, Sep 25, 2002 at 06:12:31 +0200, Tim Goetze
wrote:
There is a copy-on-next-vert-refresh call in X, I think. Part of the
dbe extension.
I don't think so. X tears all the time. I think that DBE does
something else, the main X server doesn't page flip.
> I
seem to remeber that on the Amiga and in GL I could issue a call to wait
> for the next vertical blank, forcing the redraw to be in sync with the
> video hardware. Is there an equivalent in FLTK or X?
>
> How do other people get round this?
i'd look at the GL kernel support sites, they might have a patch that
creates some sort of a '/dev/retrace', or add it to GLX. with vanilla
linux/X there's no way to do this except busy-wait reading inb
(0x3da) afaik. I dont think I can use it with FLTK though, as I
can't find a way of
drawing onto an non-screen surface and then using the dbe.
Its probably just a bad choice of toolkit. GDK and SDL seem to be able
to do it.
Nope, SDL applications tear all the time also.
The reason is that to handle the vertical interrupt, you need to have
a kernel driver that provides it/does the right thing. nVidia's binary
driver does it for GL games in fullscreen. No DRI drivers can do it,
which is why and DRI-based GL driver tears like mad even fullscreen.
Michel Danzer has just donne a patch to export an ioctl for the retrace
interrupt on the Radeons though, but that's a new development.
For video overlay surfaces it's a bit easier: most cards can page flip
their overlay surfaces easily. So, you won't see tearing with
XVideo-based apps in general.
HTH,
--
Billy Biggs
vektor(a)dumbterm.net
6:03 p.m.
On Wed, Sep 25, 2002 at 12:13:46 -0500, Billy Biggs wrote:
OK, well I've recoded it (the graphics part) in SDL, and it may not be
refresh synced, but its so much faster that it doesn't matter.
SDL also makes this kind of basic pixmap stuff much easier, though I had
to write my own linedrawing routine.
Now I 'just' need to jackify the SDL code...
- Steve
Its probably
just a bad choice of toolkit. GDK and SDL seem to be able
to do it.
Nope, SDL applications tear all the time also. 
6:13 p.m.
On Wed, 25 Sep 2002, Steve Harris wrote:
SDL also makes this kind of basic pixmap stuff much
easier, though I had
to write my own linedrawing routine.
Now I 'just' need to jackify the SDL code...
What do you mean? Isn't the graphics code in a different thread than your
audio code?
Taybin
--
http://www.piratesvsninjas.com
26 Sep
26 Sep
6:51 a.m.
On Wed, Sep 25, 2002 at 04:11:34 -0400, Taybin Rutkin wrote:
What audio code :)
Actually I added it last night and it took all of 10 minutes. Before it
was just some code to paste pixmaps onto the window and scribble on them
to test for tearing.
Its looks pretty spiffy, but it needs optimnisation. It currently takes
about 10% of my cpu to render 8 meters!
- Steve
Now I
'just' need to jackify the SDL code...
What do you mean? Isn't the graphics code in a different thread than your
audio code?
25 Sep
25 Sep
2:26 p.m.
On Wed, Sep 25, 2002 at 05:16:23 +0200, Frank Neumann wrote:
No, I'm just draw()ing the bitmap to the widget, then using line draw to
draw on the pointer. I dont think FLTK supports blits or offscreen drawing
- at least I couldn't find any mention of it.
I seem to
remeber that on the Amiga and in GL I could issue a call to wait
for the next vertical blank, forcing the redraw to be in sync with the
video hardware. Is there an equivalent in FLTK or X?
I am not sure how exactly you are doing this, but my first guess would
be to ask if you are rendering into an off-screen pixmap (until
everything in there is finished) and then do one quick Blt() to bring
this to your on-screen window. That should at least keep the flickering
low. I am not sure if there are still ways to wait for
vertical retrace
nowadays, but even if there are, I imagine it would not make sense,
given the overhead/latency the X protocol will put between the beginning
of the VBL and your attempt to draw things onto the screen "right at
that moment".
Thats very true. Thanks. Maybe I should be using something like SDL,
rather than FLTK.
- Steve
26 Sep
26 Sep
7:25 a.m.
No, I'm just draw()ing the bitmap to the widget,
then using line draw
to draw on the pointer. I dont think FLTK supports blits or offscreen
drawing - at least I couldn't find any mention of it.
fltk certainly does! the easiest way is to use Fl_Double_Window,
which does everything inside the draw() method (including child
widgets) offscreen, and copies it afterwards. works like a charm.
Note that an Fl_Double_Window can be used inside a normal window!
A slightly more complicated (and not documented way) is to use the
fl_*_offscreen methods: fl_create_offscreen, fl_begin_offscreen,
fl_end_offscreen and fl_copy_offscreen. I´m not 100pct sure of the
names, but a grep offscreen /usr/include/FL/* should get you going.
i don´t think this will get rid of the problem you mentioned, though
maybe some X implementations v-sync calls to XCopyArea?
Maarten
25 Sep
25 Sep
6:16 p.m.
On Wed, 2002-09-25 at 15:38, Steve Harris wrote:
I know a VU meter in a PCM system is about as much use
as an underwater
hairdryer
I don't know. Why is useless? :)
Bob
--
Bob Ham: bob(a)ham.org http://pkl.net/~node
<riaa> All your rights are belong to us
26 Sep
26 Sep
6:56 a.m.
On Wed, Sep 25, 2002 at 09:12:22 +0100, Bob Ham wrote:
On Wed, 2002-09-25 at 15:38, Steve Harris wrote:
Because vu meters only give you an idea of the average amplitude over a
fairly long time, and say nothing about peaks, so there no good for
detecting 'overs' in digital systems.
However if you're using jack to feed 1/2" tape or broadcast FM then the're
possibly useful.
Hands up all those who record to multitrack analogue tape ;)
- Steve
I know a VU meter in a PCM system is about as
much use as an underwater
hairdryer
I don't know. Why is useless? :) 
27 Sep
27 Sep
3:09 a.m.
Steve Harris wrote:
On Wed, Sep 25, 2002 at 09:12:22 +0100, Bob Ham wrote:
there's more of us than you might think.
in fact, we are everywhere. HARHARHARHARHAR.
(still, vu meters wouldn't make sense inside a pcm system.)
--
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
On Wed, 2002-09-25 at 15:38, Steve Harris wrote:
Because vu meters only give you an idea of the average amplitude over a
fairly long time, and say nothing about peaks, so there no good for
detecting 'overs' in digital systems.
However if you're using jack to feed 1/2" tape or broadcast FM then the're
possibly useful.
Hands up all those who record to multitrack analogue tape ;) I know a VU meter in a PCM system is about as
much use as an underwater
hairdryer
I don't know. Why is useless? :)
8028
days inactive
8030
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
8 participants
participants (8)
-
Billy Biggs -
Bob Ham -
Frank Neumann -
Joern Nettingsmeier -
mdeboer＠iua.upf.es -
Steve Harris -
Taybin Rutkin -
Tim Goetze