[LAD] FLTK vs GTKmm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm just curious what your long-time experiences with these gui-libraries are. Considering to use one of these two but can't really decide. But I do not want to switch in a year or two... Thanks for your advices! Christian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp/wE0ACgkQVC26eJ+o0+2UQACePLcVXkXSwPygZrC1sQnDUWC0 hk0AmgNmgru7KzOfYCkGppoqldsam5GH =BzmB -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 08:38 +0200, Christian wrote: > I'm just curious what your long-time experiences with these > gui-libraries are. > Considering to use one of these two but can't really decide. > But I do not want to switch in a year or two... Well, I can't say anything about developing with either one of them, but I think you should also take into account how the result will look and feel. All examples of FLTK I know of look horribly out of place on a modern desktop. Like, the 80ies want their GUIs back! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Wilms schrieb: > On Mon, 2009-08-10 at 08:38 +0200, Christian wrote: > >> I'm just curious what your long-time experiences with these >> gui-libraries are. >> Considering to use one of these two but can't really decide. >> But I do not want to switch in a year or two... > > Well, I can't say anything about developing with either one of them, but > I think you should also take into account how the result will look and > feel. > > All examples of FLTK I know of look horribly out of place on a modern > desktop. Like, the 80ies want their GUIs back! > > Well you can design an fltk gui pretty well. GTKmm guis are always using your desktop theme which might be bad, too. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp/4xQACgkQVC26eJ+o0+0UCgCeL5W0DlCi8eESuZpVbslUBx9C 0x4An2X+0tlngoHBiOygePAMRdBG1RQQ =wMkr -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, Aug 10, 2009 at 5:06 AM, Christian wrote: > GTKmm guis are always using your desktop theme which might be bad, too. not true. ardour uses gtkmm and doesn't use the desktop theme. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Davis schrieb: > On Mon, Aug 10, 2009 at 5:06 AM, Christian wrote: > >> GTKmm guis are always using your desktop theme which might be bad, too. > > not true. ardour uses gtkmm and doesn't use the desktop theme. > > Thats interesting. Will have a look how this works. I think I'll go for gtkmm. I like the nice docu ;) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp/5z4ACgkQVC26eJ+o0+3zugCgg8H/kkxePDzkmcvwMtXcAt01 lGwAn3ibuP4KjYA5u0lIAmpKtJlhI15+ =4JRs -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Monday 10 August 2009 05:51:52 Thorsten Wilms wrote: > On Mon, 2009-08-10 at 08:38 +0200, Christian wrote: > > I'm just curious what your long-time experiences with these > > gui-libraries are. > > Considering to use one of these two but can't really decide. > > But I do not want to switch in a year or two... > > Well, I can't say anything about developing with either one of them, but > I think you should also take into account how the result will look and > feel. > > All examples of FLTK I know of look horribly out of place on a modern > desktop. Like, the 80ies want their GUIs back! There are other GUI toolkits that can look so much better. For instance, Qt and wxWidgets. Why are you settling for the two choices given? Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> I'm just curious what your long-time experiences with these >>> gui-libraries are. >>> Considering to use one of these two but can't really decide. >>> But I do not want to switch in a year or two... >> Well, I can't say anything about developing with either one of them, but >> I think you should also take into account how the result will look and >> feel. >> >> All examples of FLTK I know of look horribly out of place on a modern >> desktop. Like, the 80ies want their GUIs back! > > There are other GUI toolkits that can look so much better. For instance, Qt > and wxWidgets. Why are you settling for the two choices given? > > Raymond Well I don't want to get into qt as I don't need these dependencies(and qmake) And I don't like wxWidgets example code. I'll stick to gtkmm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp/8jwACgkQVC26eJ+o0+37jQCfdHs/u9IMYEfk5B8r6wzxGfPd 4gYAn0GRlnSZI5QnQ1Ary6SgZCDZI2WI =07/f -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 11:51 +0200, Thorsten Wilms wrote: > All examples of FLTK I know of look horribly out of place on a modern > desktop. Like, the 80ies want their GUIs back! > Supercollider was some time ago. Current Version of FLTK has more than one engine, including one that clains to be a "Clearlooks" knock-off > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
Bzzt ... SPIRALSYNTH, not Super- .. Whatever. On Mon, 2009-08-10 at 13:28 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 11:51 +0200, Thorsten Wilms wrote: > > > All examples of FLTK I know of look horribly out of place on a modern > > desktop. Like, the 80ies want their GUIs back! > > > > Supercollider was some time ago. Current Version of FLTK has more than > one engine, including one that clains to be a "Clearlooks" knock-off > > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Monday 10 August 2009 06:11:08 Christian wrote: > >>> I'm just curious what your long-time experiences with these > >>> gui-libraries are. > >>> Considering to use one of these two but can't really decide. > >>> But I do not want to switch in a year or two... > >> > >> Well, I can't say anything about developing with either one of them, but > >> I think you should also take into account how the result will look and > >> feel. > >> > >> All examples of FLTK I know of look horribly out of place on a modern > >> desktop. Like, the 80ies want their GUIs back! > > > > There are other GUI toolkits that can look so much better. For instance, > > Qt and wxWidgets. Why are you settling for the two choices given? > > > > Raymond > > Well I don't want to get into qt as I don't need these dependencies(and > qmake) You can always recompile with less dependencies, and you do not have to use qmake to compile either. You can use CMake or something else. > And I don't like wxWidgets example code. Seems like an odd reason to rule it out. Have you seen Audacity? Looks pretty good, IMO. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
>> Well I don't want to get into qt as I don't need these dependencies(and >> qmake) For what is worth, Qt's documentation is simply superb (reference, examples, tutorials), I suggest you give it a look, for me it was the selling point. http://doc.qtsoftware.com/4.5/index.html You can use any build system you want with it as long as it takes into account Qt's idiosyncrasies: autotools, cmake or scons are possibilities I have toyed with, although in the end I haven't found any reason to use anything other than qmake in my Qt projects. About dependencies, what are you referring to precisely? It has its drawbacks too (dual licensing, non-standard C++ syntax extensions...) but I find it easy to learn, powerful and well supported. Anyway, all toolkits are fine once you get used to them, just pick the one with the more appealing features to you. http://en.wikipedia.org/wiki/List_of_widget_toolkits#Comparison Cheers, Luis ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 11:06 +0200, Christian wrote: > Thorsten Wilms schrieb: > > All examples of FLTK I know of look horribly out of place on a modern > > desktop. Like, the 80ies want their GUIs back! > > > > > Well you can design an fltk gui pretty well. > GTKmm guis are always using your desktop theme which might be bad, too. Ick! Using the desktop theme is not bad! The user chose it for a reason! Less atrocious and weird looking "skinned" UI's designed by seemingly half-blind artistically retarded programmers, please :) -dr (half-blind artistically retarded programmer who at least knows it) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 12:10 -0400, David Robillard wrote: > Ick! Using the desktop theme is not bad! The user chose it for a > reason! The default GTK+ Theme in the incarnation of Mandriva I have here is absolutely stunning and good looking ... But redraws at a crawl when the machine is close to full rt-dsp load. Hey, you can even watch how it paints the faders in gnome-volume-control from right to left when there is no load /at all./ Really, an Atari ST is more responsive. Another theme supplied with this dist (La-Ora Grey) looks almost as good and works just fine under heavy load. Now tell me again, what was the reason for choosing this theme rather than that theme? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 18:31 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 12:10 -0400, David Robillard wrote: > > > > Ick! Using the desktop theme is not bad! The user chose it for a > > reason! > > The default GTK+ Theme in the incarnation of Mandriva I have here is > absolutely stunning and good looking ... But redraws at a crawl when the > machine is close to full rt-dsp load. Hey, you can even watch how it > paints the faders in gnome-volume-control from right to left when there > is no load /at all./ Really, an Atari ST is more responsive. > > Another theme supplied with this dist (La-Ora Grey) looks almost as good > and works just fine under heavy load. > > Now tell me again, what was the reason for choosing this theme rather > than that theme? ... in other words, being able to choose your theme is nice? Indeed ;) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 13:57 -0400, David Robillard wrote: > > Now tell me again, what was the reason for choosing this theme rather > > than that theme? > > ... in other words, being able to choose your theme is nice? > Yes, but why is UNIX always by default configured in the least useful way? > Indeed ;) > > -dr > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On 08/11/2009 04:05 AM, Jens M Andreasen wrote: On Mon, 2009-08-10 at 13:57 -0400, David Robillard wrote: Now tell me again, what was the reason for choosing this theme rather than that theme? ... in other words, being able to choose your theme is nice? Yes, but why is UNIX always by default configured in the least useful way? I'm sure that someone is getting their kicks out of it. As a comparison on my 64 bit version of Gnome I find the default theme to be very responsive... Patrick Shirkey Boost Hardware Ltd Indeed ;) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 04:14 +1000, Patrick Shirkey wrote: > As a comparison on my 64 bit version of Gnome I find the default theme > to be very responsive... As a comparison, the machine I have today is the equivalent of a Cray2 - the most outrageous 200KW 'supercomputer' of the time when (the quite responsive) Atari/Amiga were the bread and butter machines for audio/video hackers. Spending that much clockcycles on screen redraws of bland widgets just ain't sane anymore. Ohh, and I forgot: I even have a graphics card on top with computational power exceeding that of the Cray2 by a factor of four ... Still feels like my Linux desktop will be forever stuck on pear with that of a Spectrum-48 :-/ /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On 08/11/2009 04:42 AM, Jens M Andreasen wrote: On Tue, 2009-08-11 at 04:14 +1000, Patrick Shirkey wrote: As a comparison on my 64 bit version of Gnome I find the default theme to be very responsive... As a comparison, the machine I have today is the equivalent of a Cray2 - the most outrageous 200KW 'supercomputer' of the time when (the quite responsive) Atari/Amiga were the bread and butter machines for audio/video hackers. Spending that much clockcycles on screen redraws of bland widgets just ain't sane anymore. Ohh, and I forgot: I even have a graphics card on top with computational power exceeding that of the Cray2 by a factor of four ... Still feels like my Linux desktop will be forever stuck on pear with that of a Spectrum-48 :-/ Isn't this Sergey's Law? i.e. The faster the hardware becomes, the slower the software performs... I think he has tried to start a movement against this unwritten law of computing. I can't recall the name right now though. Patrick Shirkey Boost Hardware Ltd /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 20:05 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 13:57 -0400, David Robillard wrote: > > > > Now tell me again, what was the reason for choosing this theme rather > > > than that theme? > > > > ... in other words, being able to choose your theme is nice? > > > > Yes, but why is UNIX always by default configured in the least useful > way? My default theme, and that on most distributions, is stock ClearLooks, which is both attractive and relatively fast (and colour configurable) as far as I can tell. If your slowness is truly as bad as your description suggests, it sounds like you may have an X/driver/configuration problem. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 20:42 +0200, Jens M Andreasen wrote: > Spending that much clockcycles on screen redraws of bland widgets just > ain't sane anymore. Ohh, and I forgot: I even have a graphics card on > top with computational power exceeding that of the Cray2 by a factor of > four ... Still feels like my Linux desktop will be forever stuck on pear > with that of a Spectrum-48 :-/ Let me guess Nvidia? Proprietary drivers? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 14:49 -0400, David Robillard wrote: > If your slowness is truly as bad as your description suggests, it sounds > like you may have an X/driver/configuration problem. > IIRC the default GTK+ is indeed Clearlooks. It is an Nvidia X driver running. There is an Intel framebuffer builtin into the chipset. You say that I should try that and check if I can still follow the right to left drawing order of gnome-volume-control, or else shut up? Yes why not ... cu later! > -dr > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 14:59 -0400, David Robillard wrote: > Let me guess Nvidia? Proprietary drivers? > This is such BS .. Let me Guess Intel? Opensource and broken GL!!! > -dr > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 21:14 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 14:59 -0400, David Robillard wrote: > > > Let me guess Nvidia? Proprietary drivers? > > > > > This is such BS .. Let me Guess Intel? Opensource and broken GL!!! Funny, my desktop is nice and snappy, and well supported by all recent advancements in X. Reality seems to have a "BS" bias. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 15:22 -0400, David Robillard wrote: > > This is such BS .. Let me Guess Intel? Opensource and broken GL!!! > > Funny, my desktop is nice and snappy, and well supported by all recent > advancements in X. > > Reality seems to have a "BS" bias. > Ah, your 2D driver works .. But that is not what I said. > -dr > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 21:26 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 15:22 -0400, David Robillard wrote: > > > > This is such BS .. Let me Guess Intel? Opensource and broken GL!!! > > > > Funny, my desktop is nice and snappy, and well supported by all recent > > advancements in X. > > > > Reality seems to have a "BS" bias. > > > > Ah, your 2D driver works .. But that is not what I said. Actually, it is what you were complaining about (and blaming "UNIX" for, unfairly for obvious reasons). You only brought up GL because I mentioned your drivers and you got triple-exclamation-point agitated for some reason. I guessed, and I guessed right. That is all. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 15:41 -0400, David Robillard wrote: > Actually, it is what you were complaining about (and blaming "UNIX" for, > unfairly for obvious reasons). You only brought up GL because I > mentioned your drivers and you got triple-exclamation-point agitated for > some reason. > > I guessed, and I guessed right. That is all. > OK, I have been around BIOS now, and changed the monitor connection as well (so I can see what I write ... ) I have no GL whatsoever now, but - lo and behold - Clearlooks is actually snappy? I wouldn't have believed that without trying it out. Going down again ... cu! > -dr > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 22:04 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 15:41 -0400, David Robillard wrote: > > > Actually, it is what you were complaining about (and blaming "UNIX" for, > > unfairly for obvious reasons). You only brought up GL because I > > mentioned your drivers and you got triple-exclamation-point agitated for > > some reason. > > > > I guessed, and I guessed right. That is all. > > > > OK, I have been around BIOS now, and changed the monitor connection as > well (so I can see what I write ... ) > > I have no GL whatsoever now, but - lo and behold - Clearlooks is > actually snappy? I wouldn't have believed that without trying it out. > > Going down again ... cu! Lots of info on the web about this, but most of it looks pretty old. Xorg logs (/var/log/Xorg.0.log on debian at least) are usually informative when stuff like this is happening. Render accel is probably not working, or maybe compositing is involved... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 22:04 +0200, Jens M Andreasen wrote: > OK, I have been around BIOS now, and changed the monitor connection as > well (so I can see what I write ... ) > > I have no GL whatsoever now, but - lo and behold - Clearlooks is > actually snappy? I wouldn't have believed that without trying it out. > > Going down again ... cu! > While I was at it, I updated my driver to the latest ... And you know what? (Yes, you probably gussed it :) Clearlooks is now snappy with Nvidia as well (driver 190.18, X:1.3.0 ) I wonder if this positive effect is also reflected in the behaviour of scrolling in Firefox at certain (most!) 'wordpress' sites, while simultaniously doing audio processing on the GPU ... So I suppose we can conclude that commercial vendors never fix bugs except for some of them and then only sometimes. > > > -dr > > > > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 23:09 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 22:04 +0200, Jens M Andreasen wrote: > I wonder if this positive effect is also reflected in the behaviour of > scrolling in Firefox at certain (most!) 'wordpress' sites, while > simultaniously doing audio processing on the GPU ... What do you use to do this? (audio processing on the GPU) > So I suppose we can conclude that commercial vendors never fix bugs > except for some of them and then only sometimes. The problem is that you have to rely on them to ;) -dr P.S. commercial != proprietary ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 17:14 -0400, David Robillard wrote: > What do you use to do this? (audio processing on the GPU) > Hardware is the most humble later 8400GS (revision g98 [1.4 GHz × 8 madd]) Software is the free 'C for CUDA' compiler and SDK from Nvidia > > P.S. commercial != proprietary Mmmm, but !proprietary == !commercial (once the cat is out of the bag und so weiter und sofort ...) > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 23:35 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 17:14 -0400, David Robillard wrote: > > > What do you use to do this? (audio processing on the GPU) > > > > Hardware is the most humble later 8400GS (revision g98 [1.4 GHz × 8 > madd]) > > Software is the free 'C for CUDA' compiler and SDK from Nvidia Latency low enough to make realtime use feasible? > > P.S. commercial != proprietary > > Mmmm, but !proprietary == !commercial (once the cat is out of the bag > und so weiter und sofort ...) ? The countless companies using free software in commercial ways might disagree... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 17:40 -0400, David Robillard wrote: > > Software is the free 'C for CUDA' compiler and SDK from Nvidia > > Latency low enough to make realtime use feasible? What I do is - imagining that I am a Jack client with near zero processing time - what I do is that I 'receive previous/send next/launch kernel' in one go. Current process is in principle a 192 voice Minimoog style polysynth with 4 external audio inputs + a ton of midi in. Mixdown to 16 stereo (midi)channels, further mixdown to 8 out (1 stereo 'house' + 3 stereo 'fx send') Sorting the dynamically assigned voices to their respective channels is currently the main bottleneck - or so it seems. With buffersize 3 × 1.3 ms @96KHz I have clockcycles to spare and can at ease display a stream of video (320×200) simultaniosly for doing a soundtrack to some movie or something. And more ... With buffersize 3 × 0.7 ms .. I'll have to back off somewhat regarding number of voices. With buffersize 3 × 0.3 ms nope, can't do that, sorry! (but still works for code on the host) The Jack interface is not really here yet though. It must be understood that there can only be one transfer to the device for each run which must include all inputs, otherwise you'll get absolutely nothing done. That transfer can OTOH be pretty huge, way more than I personally have any use for at this point in time. 64in + 64 out @96KHz + lots of controllers, left in some place we all (as well as Jack) knows about would not be asking for too much from the hardware. That is not the problem. The general hostility against non-GPL software is tougher though, and unfortunately makes me feel like - by presenting these ideas - like I've just dressed up in pink rubber-suit with a sign on my back saying "puke on me" ... Oh well, you'll have to wipe off your own monitors when you are done :-D /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 00:43 +0200, Jens M Andreasen wrote: > On Mon, 2009-08-10 at 17:40 -0400, David Robillard wrote: > > > > Software is the free 'C for CUDA' compiler and SDK from Nvidia > > > > Latency low enough to make realtime use feasible? > > What I do is - imagining that I am a Jack client with near zero > processing time - what I do is that I 'receive previous/send next/launch > kernel' in one go. Current process is in principle a 192 voice Minimoog > style polysynth with 4 external audio inputs + a ton of midi in. Mixdown > to 16 stereo (midi)channels, further mixdown to 8 out (1 stereo 'house' > + 3 stereo 'fx send') Sorting the dynamically assigned voices to their > respective channels is currently the main bottleneck - or so it seems. > > With buffersize 3 × 1.3 ms @96KHz I have clockcycles to spare and can at > ease display a stream of video (320×200) simultaniosly for doing a > soundtrack to some movie or something. And more ... Interesting... I am surprised you can crunch DSP on these things with this kind of latency at 96Khz. 48Khz should be a breeze then... > The general hostility against non-GPL software is tougher though Huh? Are you using "non-GPL" here to mean "not open source"? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 21:43 -0400, David Robillard wrote: > > With buffer-size 3 × 1.3 ms @96KHz I have clock cycles to spare and can at > > ease display a stream of video (320×200) simultaneously for doing a > > soundtrack to some movie or something. And more ... > > Interesting... I am surprised you can crunch DSP on these things with > this kind of latency at 96KHz. 48KHz should be a breeze then... Most certainly. The driver is very predictably processing each batch to completion, so if there are no X-events queued up, then you 'own' the GPU. Anything OpenGL and you're fried though - not even GLX gears in a small window, at least not with buffer sizes around 1ms. Increasing the buffers/jitter to around 5ms does away with that problem though, so that glxgears can run in 256×256 (along with the previous smallish video stream and Atari ST emulation [running a MIDI-sequencer]), oh and apparently also GLX in full screen. Increased buffers also does away with artifacts coming from certain Firefox redraws (where this site http://carlbildt.wordpress.com/ mysteriously is affected while this site http://arstechnica.com/ is not.) This is with the tiniest most out-fashioned device almost available which do not have newer features like overlapping processing/transfers for alternating streams. The motherboard chipset on say the ION-platform would have near twice the processing power, and you could then also do away with any transfers and just read from normal memory, leaving the Intel companion chip to do interrupt processing and nothing much else. If anybody would be interested in doing a concerted effort of optimizing PCIe transfers in jackd for cross platform CUDA audio processing, then - well - I am here, as well as over at the CUDA forums. I imagine that, as seen from say qjackctl, this should just look the same as any other hardware you may have - like a sound-card - with 32 or perhaps 64 channels in/out. What happens at the other side, what those channels connects to, would be up to the user/programmer. Running several kernels in succession, the one piped into the other has very little overhead, although it might be a better strategy to do different parts of the scene in parallel on neighboring processors. Very few people who does not work at TU-Berlin actually needs more than 640 channel strips ;) The reward would be having huge arrays of GHz processors for about one dollar a pop! Memory bandwidth in the triple digit range to go with that. Or like me, just enjoy the bliss of silent computing on something a little less ambitious. /j 8<-- update: The performance increase for GTK pixmaps I experienced earlier came because the X conf defaulted to 8bit after the Nvidia card was disabled ... darned! I'll have to redo that experiment with the Intel driver again some other day, and for now just remember that switching to 8bit might allow for more 'blinkenlights' while still processing near RT on the GPU. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On 11 Aug 2009, at 07:16, Jens M Andreasen wrote: > > If anybody would be interested in doing a concerted effort of > optimizing > PCIe transfers in jackd for cross platform CUDA audio processing, > then - > well - I am here, as well as over at the CUDA forums. I imagine > that, as > seen from say qjackctl, this should just look the same as any other > hardware you may have - like a sound-card - with 32 or perhaps 64 > channels in/out. What happens at the other side, what those channels > connects to, would be up to the user/programmer. Running several > kernels > in succession, the one piped into the other has very little overhead, > although it might be a better strategy to do different parts of the > scene in parallel on neighboring processors. Very few people who does > not work at TU-Berlin actually needs more than 640 channel strips ;) If that's what the CUDA interface to the outside world looks like then wouldn't it be better to expose it as a JACK App, which loads CUDA- specific plugins onto the graphics card? I don't see why you'd want to embed it in the jack daemon. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 07:45 +0100, Steve Harris wrote: > O > If that's what the CUDA interface to the outside world looks like then > wouldn't it be better to expose it as a JACK App, which loads CUDA- > specific plugins onto the graphics card? > > I don't see why you'd want to embed it in the jack daemon. > It is the scatter/gathering of data that is killing. I need to have one and only one transfer on the PCIe line for each period to be efficient, preferably in the 10 - 20KB range or more. The jack model of one channel, one buffer does not fit very well here. Potentially It should also be possible to stream from harddisk via DMA directly to the device without bothering the CPU at all. That OIOH hand would work for prerecorded material with say ardour, since you can look ahead as many bytes as you like. Doing live performances requres another approach though. Do you believe it would be very difficult to implement? I do unfortunately not have the required knowledege of jackd internals to judge wether or not. > - Steve > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Monday, August 10, 2009, Luis Garrido wrote: > For what is worth, Qt's documentation is simply superb Agreed. Another excellent C++ multiplatform toolkit is Juce. It is worth to try it if you are writting audio/MIDI software. http://juce.sourceforge.net Regards, Pedro ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On 11 Aug 2009, at 08:04, Jens M Andreasen wrote: > > On Tue, 2009-08-11 at 07:45 +0100, Steve Harris wrote: >> O >> If that's what the CUDA interface to the outside world looks like >> then >> wouldn't it be better to expose it as a JACK App, which loads CUDA- >> specific plugins onto the graphics card? >> >> I don't see why you'd want to embed it in the jack daemon. >> > > It is the scatter/gathering of data that is killing. I need to have > one > and only one transfer on the PCIe line for each period to be > efficient, > preferably in the 10 - 20KB range or more. The jack model of one > channel, one buffer does not fit very well here. It's not ideal, but assembling all the jack buffers into one big one is not going to be that much load on the CPU. > Potentially It should also be possible to stream from harddisk via DMA > directly to the device without bothering the CPU at all. That OIOH > hand > would work for prerecorded material with say ardour, since you can > look > ahead as many bytes as you like. Yeah, I think that would have to be app specific. Another tack would be to provide a library that could execute LV2 plugins (with CUDA versions of the code in the bundle). It would presumably need a daemon or such, but would be more generally useful than a hacked jackd. > Doing live performances requres another approach though. > > Do you believe it would be very difficult to implement? I do > unfortunately not have the required knowledege of jackd internals to > judge wether or not. Not difficult, just not what anyone really wants. The whole point of jack is that it lets you combine bits of software in different ways, this would take that away to some extent. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
Continuing this increasingly inaccurately christened thread .. On Tue, 2009-08-11 at 11:26 +0100, Steve Harris wrote: > It's not ideal, but assembling all the jack buffers into one big one > is not going to be that much load on the CPU. > OK .. Adrian Knoth showed some interest and says he knows his way around in jackd as well as a colleague involved with CUDA. If the idea after evaluation does not appear to be worth the effort, then we'll just drop it by then. > Another tack would be to provide a library that could execute LV2 > plugins (with CUDA versions of the code in the bundle). It would > presumably need a daemon or such, but would be more generally useful > than a hacked jackd. > That would have to be a collection of generally useful plugins, at least 32 channels wide to be worth it. A mega plugin so to say. This ain't no lawn-mover you can turn around on a platter. Doing little things here and there /only/ would be very difficult in general. The thing to notice is that, although several kernels can be launched the one after the other, at any given time there is only one running which will have to be aware of which codepath to take depending on what processor it is running on. Or else you'll end up with 640 identical channel-strips rather than something like a synth-collection, 64 fully equipped channel-strips + a few reverb units as well as an autocomposer based on neural networks (Well OK, that last one might be a bit over the top... :) As long as you only have a single 8 core multiprocessor, the GPU can be utilized fully by a single somewhat demanding project. It is when there are dozens of cores to feed that the need for cooperation arises, and this is as far as I can see where things are heading, also over in Intel/Larrabee land. > The whole point of > jack is that it lets you combine bits of software in different ways, > this would take that away to some extent. > To some extent, yes. But provided that the host isn't spending much time on moving buffers around, you'll still have all of your (much more flexible) CPU left to use for additional processing. Having this much processing power available in a way also eliminates /the need/ for carefully selecting what channels should be processed by what plugin. Just do everything for all, possibly with all settings turned down to zero or bypassed on some, even most channels. Some effects will still be optional - like say time stretching, which might not be a natural choice for the basic bread-and-butter setup, no matter how much icing you put on it. Or maybe it is? Some people will most likely disagree with me here .. To put things in some economical perspective, I am talking about upgrading this tiny desktop-machine to having bandwidth and processing power twice that of a current top-of-the-line Intel Nehalem for less than $200, maybe around Christmas. Inexpensive (!Apple) laptops with GPU's like that are hitting the channel as we speak. /jma > - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 13:54 +0200, Jens M Andreasen wrote: > This ain't no lawn-mover you can turn around on a platter. More like this actually: http://www.toytractorshow.com/images/ih_com9.jpg Another picture to "hammer in" what is going on: http://www.thewallanalysis.com/Pictures/MovieShots/FullSizeShots/Worms9.JPG /jma ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, Aug 11, 2009 at 01:54:39PM +0200, Jens M Andreasen wrote: > > It's not ideal, but assembling all the jack buffers into one big one > > is not going to be that much load on the CPU. > OK .. Adrian Knoth showed some interest and says he knows his way around > in jackd as well as a colleague involved with CUDA. If the idea after > evaluation does not appear to be worth the effort, then we'll just drop > it by then. Speaking from the user's point of view, LV2 would be the way to go. It's just convenient to have all the settings saved in an ardour session, nice GUIs and so on. This could boil down to have a collecting thread somewhere and just small control plugins for getting the actual data. But I'm sure we'll find out. ;) > That would have to be a collection of generally useful plugins, at least > 32 channels wide to be worth it. A mega plugin so to say. This ain't no > lawn-mover you can turn around on a platter. Doing little things here > and there /only/ would be very difficult in general. I could imagine a generic all-in-wonder channel strip. (to the channel, it looks like a channel strip, but it's actually 32 or more channels in parallel). Which would mean: dynamics section (compressor, gate, gain), EQ, perhaps some fancy stuff like your rubberband or pitch correction in general, perhaps FFT analysis or at least FFT transformation, so subsequent plugins can operate in the frequency domain. Or whatever. ;) > processor it is running on. Or else you'll end up with 640 identical > channel-strips rather than something like a synth-collection, 64 fully Doesn't sound too bad to me. ;) Though I could perfectly live with 128 identical channel strips plus your synth running, if switching kernels is feasible. > To put things in some economical perspective, I am talking about > upgrading this tiny desktop-machine to having bandwidth and processing > power twice that of a current top-of-the-line Intel Nehalem for less > than $200, maybe around Christmas. Christmas? That's ambitious, but hey, I guess we could "borrow" lots of code from existing plugins and chain them together. Anyway, it's a cool project. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver Gesundheit? - Was nützt einem Gesundheit, wenn man sonst ein Idiot ist? (Theodor W. Adorno) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On 11 Aug 2009, at 12:54, Jens M Andreasen wrote: > Continuing this increasingly inaccurately christened thread .. > > On Tue, 2009-08-11 at 11:26 +0100, Steve Harris wrote: > >> It's not ideal, but assembling all the jack buffers into one big one >> is not going to be that much load on the CPU. >> > > OK .. Adrian Knoth showed some interest and says he knows his way > around > in jackd as well as a colleague involved with CUDA. If the idea after > evaluation does not appear to be worth the effort, then we'll just > drop > it by then. > >> Another tack would be to provide a library that could execute LV2 >> plugins (with CUDA versions of the code in the bundle). It would >> presumably need a daemon or such, but would be more generally useful >> than a hacked jackd. >> > > That would have to be a collection of generally useful plugins, at > least > 32 channels wide to be worth it. A mega plugin so to say. This ain't > no > lawn-mover you can turn around on a platter. Doing little things here > and there /only/ would be very difficult in general. Ah, I see. I'm not really that familiar with how it works. Is it not possible to stitch multiple plugins into a single processing unit, horizontally? ie. can you compose the CUDA objects? Going really hightech, with access to the source you could compile the mega-plugin on demand. That might be a bit adventurous, but it would be a clear win over the kind of things the closed-source people can do. > The thing to notice is that, although several kernels can be launched > the one after the other, at any given time there is only one running > which will have to be aware of which codepath to take depending on > what > processor it is running on. Or else you'll end up with 640 identical > channel-strips rather than something like a synth-collection, 64 fully > equipped channel-strips + a few reverb units as well as an > autocomposer > based on neural networks (Well OK, that last one might be a bit over > the > top... :) > > As long as you only have a single 8 core multiprocessor, the GPU can > be > utilized fully by a single somewhat demanding project. It is when > there > are dozens of cores to feed that the need for cooperation arises, and > this is as far as I can see where things are heading, also over in > Intel/Larrabee land. > >> The whole point of >> jack is that it lets you combine bits of software in different ways, >> this would take that away to some extent. >> > > To some extent, yes. But provided that the host isn't spending much > time on moving buffers around, you'll still have all of your (much > more > flexible) CPU left to use for additional processing. Having this much > processing power available in a way also eliminates /the need/ for > carefully selecting what channels should be processed by what plugin. > Just do everything for all, possibly with all settings turned down to > zero or bypassed on some, even most channels. > > Some effects will still be optional - like say time stretching, which > might not be a natural choice for the basic bread-and-butter setup, no > matter how much icing you put on it. Or maybe it is? Some people will > most likely disagree with me here .. Oh, I see, you plan on injecting this processing into the in/outputs infront of the ALSA device? Kindof makes sense. At the very least you could use a very sophisticated dithering algorithm for little cost :) > To put things in some economical perspective, I am talking about > upgrading this tiny desktop-machine to having bandwidth and processing > power twice that of a current top-of-the-line Intel Nehalem for less > than $200, maybe around Christmas. Inexpensive (!Apple) laptops with > GPU's like that are hitting the channel as we speak. Sure, but it doesn't sound like it's as useful as a GP CPU. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 14:10 +0100, Steve Harris wrote:
> > Doing little things here
> > and there /only/ would be very difficult in general.
>
> Ah, I see. I'm not really that familiar with how it works.
>
> Is it not possible to stitch multiple plugins into a single processing
> unit, horizontally? ie. can you compose the CUDA objects?
>
No, youd have to do your "stiching" ..
> Going really hightech, with access to the source you could compile the
> mega-plugin on demand. That might be a bit adventurous, but it would
> be a clear win over the kind of things the closed-source people can do.
>
.. at compile-time to get wildly diferent thing running simultaniosly on
each processor. At least the code must be present and then you could do
the final choice at kernel launch sending some parameter to the GPU to
ponder on:
switch(someArgument[blockID]) // we know where we are
{
case STRIP: ...; // do the channel strip thingie
case MOOG: ...; // do classic synth
case REVERB ...
case FAIRLIGHT: ...
case ...
Well, almost that simple at least. There is still the 192 thread rule
saying that you need at least 192 threads on each processor to fully
hide pipeline latencies. Each "warp" - which is a group of 32 threads -
can still take diferent codepaths though, as long as the programmer
takes care that all paths will evt arrive at any synchronisation barrier
issued by some other path. You'll get hung otherwise.
Furthermore, all processor configurations will be the same. If one
processor is configured for two blocks each having 128 threads, then
that is how the world looks like for all codepaths on all processors.
Still with me? In that case you are invited to do something wonderful
for one (or more) multiprocessors, each having 256 threads divided
between two blocks (128 threads per block) that will not use more than
the available 16K registers defined by Compute Model 1.2 so that both
blocks will run concurrently, hiding latencies as well as sync barriers.
Figuring out where to read and write shared in/out in an organized way
would in theory be the first minor obstacle, but nobody will notice
before the individual parts of the project is eventually stiched
together. Also, nobody knows yet what kind of processing will be
available either or why anybody would like to read any other data, so ..
Just to get going, say the kernel will be called every 128 samples at a
samplerate suitable for the processor at hand. Assume something like a
rate of 96K @1.2GHz
> Sure, but it doesn't sound like it's as useful as a GP CPU.
>
Bah!
/jma
> - Steve
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On 8/11/09, Adrian Knoth wrote: > On Tue, Aug 11, 2009 at 01:54:39PM +0200, Jens M Andreasen wrote: > >> > It's not ideal, but assembling all the jack buffers into one big one >> > is not going to be that much load on the CPU. >> OK .. Adrian Knoth showed some interest and says he knows his way around >> in jackd as well as a colleague involved with CUDA. If the idea after >> evaluation does not appear to be worth the effort, then we'll just drop >> it by then. > > Speaking from the user's point of view, LV2 would be the way to go. It's > just convenient to have all the settings saved in an ardour session, > nice GUIs and so on. > > This could boil down to have a collecting thread somewhere and just > small control plugins for getting the actual data. > > > But I'm sure we'll find out. ;) > >> That would have to be a collection of generally useful plugins, at least >> 32 channels wide to be worth it. A mega plugin so to say. This ain't no >> lawn-mover you can turn around on a platter. Doing little things here >> and there /only/ would be very difficult in general. > > I could imagine a generic all-in-wonder channel strip. (to the channel, > it looks like a channel strip, but it's actually 32 or more channels in > parallel). > > Which would mean: dynamics section (compressor, gate, gain), EQ, perhaps > some fancy stuff like your rubberband or pitch correction in general, > perhaps FFT analysis or at least FFT transformation, so subsequent > plugins can operate in the frequency domain. > > Or whatever. ;) > > >> processor it is running on. Or else you'll end up with 640 identical >> channel-strips rather than something like a synth-collection, 64 fully > > Doesn't sound too bad to me. ;) Though I could perfectly live with 128 > identical channel strips plus your synth running, if switching kernels > is feasible. > > >> To put things in some economical perspective, I am talking about >> upgrading this tiny desktop-machine to having bandwidth and processing >> power twice that of a current top-of-the-line Intel Nehalem for less >> than $200, maybe around Christmas. > > Christmas? That's ambitious, but hey, I guess we could "borrow" lots of > code from existing plugins and chain them together. > > Anyway, it's a cool project. > > > > -- > mail: a...@thur.dehttp://adi.thur.de PGP/GPG: key via keyserver > > Gesundheit? - Was nützt einem Gesundheit, wenn man sonst ein Idiot ist? > (Theodor W. Adorno) > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > Could you run convolution algo's i.e jconv stuff on the card via cuda? If so the channel emulator series here: http://noisevault.com/nv/index.php?option=com_remository&Itemid=29&func=selectcat&cat=19 Would be fantastically awesome ;) Has anyone used that channel emulator collection with jconv? What do you think? What was performance like? I'd love to test the cuda stuff, i've got a 9600GT 1gb and nvidia drivers... ;) Loki ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Wed, 2009-08-12 at 00:32 +1000, Loki Davison wrote: > Could you run convolution algo's i.e jconv stuff on the card via cuda? > That's a very good question! One user vvolkov from Berkeley has posted some specially designed and optimized code for FFT sizes 256, 512, 1024, 2048, 4096 and 8192 here: http://forums.nvidia.com/index.php?showtopic=69801 He is claiming a throughput of no less than 160 Gflop on a GTX 280 (which is quite a high end card.) How much computational power is needed for jconv, just to get a rough estimate of whether this would be a good idea? Would it be correct to say that the expected number of flops for 8192 samples would be close to 8 × (8192/2) × log(8192) == approx 128000 flops, most of which can be executed as combined multiply-adds? Another user posted sometime ago windows binaries for a convolution reverb using the CUDA FFT library routines. It is a) unlike jconv using large same size segments b) perhaps not the most optimal solution for CUDA But as proof of concept, yes people have said that it works. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
David Robillard wrote: >> using your desktop theme which might be bad, too. >> > > Ick! Using the desktop theme is not bad! The user chose it for a > reason! > > Less atrocious and weird looking "skinned" UI's designed by seemingly > half-blind artistically retarded programmers, please :) > > -dr (half-blind artistically retarded programmer who at least knows it) :D On the other hand neither GNOME nor KDE are usable with dark themes, without causing some trouble, that's why I now use bright seems again. Non-graphic-design-retarded coders maybe want to design a relative neutral GUI, that still fit to most desktop themes. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
Jens M Andreasen wrote: > Really, an Atari ST is more responsive. For me TOS is still the best OS for MIDI usage with external MIDI equipment, but this isn't true, the Atari ST's response is very good when using a Blitter, but very bad when not using a Blitter. For Linux I noticed, that when running into trouble because of resources, ION2 is a very good WM, but sometimes ION2 has got troubles because of some windows behaviour. I can't remember the applicatuions, but if I would be a coder for Linux, I would take care about WMs that are frame based, without any DE. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Wed, 2009-08-12 at 00:32 +1000, Loki Davison wrote: > Could you run convolution algo's i.e jconv stuff on the card via cuda? Forget what I wrote before. Since everything else has a "take no prisoners, just instigate a bloody massacre" aproach, then why not run 32 instances of jconv in parallel? That would be four warps independently working their way through the variously sized sample blocks, each thread execting serial code that looks very much the same as jconv itself, including the threading. How much jconv would something like a 300Mhz Pentium Pro buy me? (Just to get a hunch if this would be a possibility at all) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 11 Aug 2009, Ralf Mardorf wrote: > For me TOS is still the best OS for MIDI usage with external MIDI > equipment, but this isn't true, the Atari ST's response is very good > when using a Blitter, but very bad when not using a Blitter. > > For Linux I noticed, that when running into trouble because of > resources, ION2 is a very good WM, but sometimes ION2 has got troubles > because of some windows behaviour. I can't remember the applicatuions, > but if I would be a coder for Linux, I would take care about WMs that > are frame based, without any DE. Did you try Enlightenment 0.17 ? In addition, it is based on a powerful set of libraries that can be used to create beautiful applications. Here is a program that uses these libraries (media player): http://www.calaos.fr/pub/video/calaos_media_music.ogg regards Vincent Torri ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
Patrick Shirkey wrote: > Isn't this Sergey's Law? > > i.e. The faster the hardware becomes, the slower the software > performs... > > I think he has tried to start a movement against this unwritten law of > computing. I can't recall the name right now though. Software needed less resources in the 80ies, when we programmed in Assembler, but in the 80ies it was easy to keep track of things while programming for Z80, 6502, 6510 and 68000. I guess you Linux guys need to use C, because the CPUs and kernels have become much more complex. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 11:21 +0200, Pedro Lopez-Cabanillas wrote: > On Monday, August 10, 2009, Luis Garrido wrote: > > For what is worth, Qt's documentation is simply superb > > Agreed. > > Another excellent C++ multiplatform toolkit is Juce. It is worth to try it if > you are writting audio/MIDI software. s/toolkit/kitchen sink/ ;) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 09:04 +0200, Jens M Andreasen wrote: > On Tue, 2009-08-11 at 07:45 +0100, Steve Harris wrote: > > O > > If that's what the CUDA interface to the outside world looks like then > > wouldn't it be better to expose it as a JACK App, which loads CUDA- > > specific plugins onto the graphics card? > > > > I don't see why you'd want to embed it in the jack daemon. > > > > It is the scatter/gathering of data that is killing. I need to have one > and only one transfer on the PCIe line for each period to be efficient, > preferably in the 10 - 20KB range or more. The jack model of one > channel, one buffer does not fit very well here. Unless I'm missing something an app could do this just as jack could internally. You receive and send the buffers from/to jack separately, sure, but that's true regardless. Doesn't mean you have to do individual transfers to the card, you get/send all the buffers at the same time with jack. The copy overhead sucks, but can't get away from that if you want it to work with jack at all. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
Vincent Torri wrote: > > > On Tue, 11 Aug 2009, Ralf Mardorf wrote: > >> For me TOS is still the best OS for MIDI usage with external MIDI >> equipment, but this isn't true, the Atari ST's response is very good >> when using a Blitter, but very bad when not using a Blitter. >> >> For Linux I noticed, that when running into trouble because of >> resources, ION2 is a very good WM, but sometimes ION2 has got troubles >> because of some windows behaviour. I can't remember the applicatuions, >> but if I would be a coder for Linux, I would take care about WMs that >> are frame based, without any DE. > > Did you try Enlightenment 0.17 ? In addition, it is based on a > powerful set of libraries that can be used to create beautiful > applications. Here is a program that uses these libraries (media player): > > http://www.calaos.fr/pub/video/calaos_media_music.ogg > > regards > > Vincent Torri E17 looks well, but when I used it a long time ago on another machine it was disgusting experimental ;). I can't play the OGG? Are you sure that it isn't broken? Cheers, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, Aug 11, 2009 at 06:50:50PM +0200, Jens M Andreasen wrote: > That would be four warps > independently working their way through the variously sized sample > blocks, each thread execting serial code that looks very much the same > as jconv itself, including the threading. Note that the algorithm implemented by libzita-convolver (used by jconv) when used in real-time mode relies on regular scheduling (i.e. being called from a Jack process callback) and carefully set thread priorities. How to structure a convolution engine to run on a graphics processor would very much depend on where you want the I/O. If it remains a Jack app then the easiest way would be to offload the work done for the larger partition size(s) to the graphics processor. Timing is absolutely not critical in that case, but if more than one partition size is moved in that way, or if you have more than one instance running you'd still need to respect relative priorities. Now jconv is a general purpose tool designed to efficiently handle any convolution matrix, including sparse ones. If you use it for reverb the matrix size is small (usually 1x2 or 2x2 for stereo). An application that runs e.g. 8 of those can be structured in a completely different way that could avoid the use of multiple priorities. > How much jconv would something like a 300Mhz Pentium Pro buy me? (Just > to get a hunch if this would be a possibility at all) Almost impossible to tell without trying. It also depends in a very complex way of the configuration - the ratios will not be the same on all machines. Jconv's predecessor, jace, worked by trying to distribute the work done on large FFTs and MACs as evenly as possible over callbacks with a shorter period. A condition for doing this is of course that you can estimate the work to be done in the first place. It was the impossibility of doing this for the more general use cases that jconv is supposed to handle that forced me to adopt the multi-threaded/multi- priority solution. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 11 Aug 2009, Ralf Mardorf wrote: > Vincent Torri wrote: >> >> >> On Tue, 11 Aug 2009, Ralf Mardorf wrote: >> >>> For me TOS is still the best OS for MIDI usage with external MIDI >>> equipment, but this isn't true, the Atari ST's response is very good >>> when using a Blitter, but very bad when not using a Blitter. >>> >>> For Linux I noticed, that when running into trouble because of >>> resources, ION2 is a very good WM, but sometimes ION2 has got troubles >>> because of some windows behaviour. I can't remember the applicatuions, >>> but if I would be a coder for Linux, I would take care about WMs that >>> are frame based, without any DE. >> >> Did you try Enlightenment 0.17 ? In addition, it is based on a powerful set >> of libraries that can be used to create beautiful applications. Here is a >> program that uses these libraries (media player): >> >> http://www.calaos.fr/pub/video/calaos_media_music.ogg >> >> regards >> >> Vincent Torri > > E17 looks well, but when I used it a long time ago on another machine it was > disgusting experimental ;). well, we work hard for a release, so a lot of things has been fixed / stabilized. Maybe you can try it again. > I can't play the OGG? Are you sure that it isn't broken? I've just tried it before giving the link. Iirc, it uses theora as video codec, so be sure to have it. You can try that one (the wall paper selector of e17, using these libraries) if you still experience problems with the ogg file: http://www.rasterman.com/files/wp2.avi Or try vlc or mplayer as video player. Vincent Torri ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
Vincent Torri wrote: >> >> E17 looks well, but when I used it a long time ago on another machine >> it was disgusting experimental ;). > > well, we work hard for a release, so a lot of things has been fixed / > stabilized. Maybe you can try it again. I'll try it again. >> I can't play the OGG? Are you sure that it isn't broken? > [snip] I'm short of time now. It shouldn't be a problem because of the codes :S. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 19:54 +0200, Fons Adriaensen wrote: > On Tue, Aug 11, 2009 at 06:50:50PM +0200, Jens M Andreasen wrote: > > > That would be four warps > > independently working their way through the variously sized sample > > blocks, each thread execting serial code that looks very much the same > > as jconv itself, including the threading. > > Note that the algorithm implemented by libzita-convolver (used by > jconv) when used in real-time mode relies on regular scheduling > (i.e. being called from a Jack process callback) and carefully > set thread priorities. > The priorities are always even .. and then again not nescessarily. Say warp A (or "process" A) must do four smaller workloads while warp B is doing one bigger workload? The way to go would then be for warp B to call __syncthreads() when 25% of its work is done, thus assuring that warp A will be given all of GPU untill it has catched up at the end of its first workload and also calls __synthreads(), which gives warp B the green light to continue. This under the assumption that warp A hasn't already done it's part and is waiting for B to catch up. Repeat the procedure at 50% and 75%. > How to structure a convolution engine to run on a graphics > processor would very much depend on where you want the I/O. Locally on the card for use by other parts of the complex, unless by routing directive read or written to those arrays that are transferred back and forth between the GPU and host at each kernel launch. > > How much jconv would something like a 300Mhz Pentium Pro buy me? (Just > > to get a hunch if this would be a possibility at all) > > Almost impossible to tell without trying. It also depends > in a very complex way of the configuration - the ratios > will not be the same on all machines. > I found a measure of ~1 sec for a 128K FFT on a PPro @200 Would that be helpful for a guesstimate? The thing is also that, although the first thing one might come to think of is a nice convolution reverb with a decay of two seconds, having instead 32 shorter impulses - all different - opens up another universe. You could have an increasing delay in front of each of them, giving an illusion that they are all parts of the same (huge) impulse redponse, or you could use keyboard triggers and routing to play them like an instrument. Still, 500ms would be really very useful and 32 convolutions is mmm .. perhaps a little overkill. There might be ways for two or four threads to share one load. IIRC library routines for SSE enabled FFT exists which could be more or less copied verbatim across four adjacent threads. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, Aug 11, 2009 at 08:56:56PM +0200, Jens M Andreasen wrote: > Say warp A (or "process" A) must do four smaller workloads while warp B > is doing one bigger workload? The way to go would then be for warp B to > call __syncthreads() when 25% of its work is done, thus assuring that > warp A will be given all of GPU untill it has catched up at the end of > its first workload and also calls __synthreads(), which gives warp B the > green light to continue. This under the assumption that warp A hasn't > already done it's part and is waiting for B to catch up. > > Repeat the procedure at 50% and 75%. It's not that simple... An example: the santalucia reverb with period size = 256, mininum partition size = 256. There will be 3 partitions of 256 frames, 6 of 512, 6 of 2048 and 24 of 8192 frames. The first will be done in jack's callback and the others at lower priorities, resp. -1,-2,-3 relative to jack's thread (*). Each of these threads is triggered into action with a period equal to its partition size, and the work is expected to be ready at the next trigger. That means that the thread that does the size 512 ones must have priority over all the others. Except in some simple cases it's almost impossible to divide the work done by e.g. the slowest thread into equal parts. If that were possible we wouldn't need multiple threads at all - the evenly divided workload could be done in jack's callback without problem. As things are, pre-emption seems to be the only solution. > I found a measure of ~1 sec for a 128K FFT on a PPro @200 > Would that be helpful for a guesstimate? No. The largest FFT used by jconv is 16k, it doesn't pay to increase that size. Depending on the configuration the FFTs could dominate the workload (many short 1-to-1 convolutions) or the MAC operartions would take most of the time (long IRs and/or a dense matrix). And then there's the cache size that will have all sorts of complicated effects. (*) From the next release that would be -1,-3,-5, i.e. one less for each doubling of the size. This allows multiple jconvs to be scheduled fairly even it they don't use the same set of sizes. Other apps doing similar things should use the same system if they are supposed to work together well. -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Tue, 2009-08-11 at 22:15 +0200, Fons Adriaensen wrote: > .. > > An example: the santalucia reverb with period size = 256, > mininum partition size = 256. > > There will be 3 partitions of 256 frames, 6 of 512, 6 of 2048 > and 24 of 8192 frames. Say periodsize = 128 instead. Then we would have thread A: 6 partitions of 128, B: 6 of 512, C: 6 of 2K and finally D: 24 of 8K > The first will be done in jack's callback and the others at > lower priorities, resp. -1,-2,-3 relative to jack's thread (*). > Each of these threads is triggered into action with a period > equal to its partition size, and the work is expected to be > ready at the next trigger. > Say at time 16K. Thread D would then have just gotten the last 128 samples it needs to start doing the FFT on the data between 8K and 16K This needs not be done untill time 24K when it OTOH /must/ have been completed. The kernel* will be called 64 times between now and then, so if D does 1/64th of its job now it can save its state and go to sleep. Are you saying that it in the specific case is impossible to know how much of an 8K FFT equals 1/64th? [*] Here "kernel" means the CUDA-program running and not the filter kernel nor the Linux kernel. It's confusing ... > That means that the thread that does the size 512 ones must > have priority over all the others. Except in some simple > cases it's almost impossible to divide the work done by e.g. > the slowest thread into equal parts. If that were possible we > wouldn't need multiple threads at all - the evenly divided > workload could be done in jack's callback without problem. > As things are, pre-emption seems to be the only solution. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Wed, Aug 12, 2009 at 09:59:50AM +0200, Jens M Andreasen wrote:
> Say periodsize = 128 instead. Then we would have thread A: 6 partitions
> of 128, B: 6 of 512, C: 6 of 2K and finally D: 24 of 8K
Actually 7,6,6,24.
> Say at time 16K.
>
> Thread D would then have just gotten the last 128 samples it needs to
> start doing the FFT on the data between 8K and 16K
>
> This needs not be done untill time 24K when it OTOH /must/ have been
> completed. The kernel* will be called 64 times between now and then, so
> if D does 1/64th of its job now it can save its state and go to sleep.
>
> Are you saying that it in the specific case is impossible to know how
> much of an 8K FFT equals 1/64th?
It would be 16K FFT, and there would be a lot more than
just that.
This is an outline of the process() function for one
partition size:
proces()
{
for (loop over inputs)
{
if (input not active) continue
FFT
}
for (loop over outputs)
{
if (output not active) continue
for (loop over inputs)
{
if ((input,output) not active) continue
for (loop over partitions)
{
if (partition not empty)
{
MAC
}
}
}
IFFT
}
}
The loops over inputs and outputs and the continue condition
are actually inplemented by linked lists, but the code shown
is equivalent.
You could loop over the data structures, and make a list of
of all steps (FFT, MAC, IFFT) and their parameters. Then if
you know the relative cost of the three basic operations you
try to divide this in 64 equal parts.
There are some problems with this:
- The relative cost of FFT and MAC is not know with any
precision.
- There may be less than 64 steps.
- A single 16k FFT may already be too much, and most FFT
libraries don't allow you to divide it into smaller
pieces.
Again, if you *can* do the division, there is no need
to use multiple threads. you can just merge the lists
of steps for all partition sizes and execute this as
a static schedule using just function calls. This is
how jace worked.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Wed, 2009-08-12 at 12:10 +0200, Fons Adriaensen wrote: > It would be 16K FFT, and there would be a lot more than > just that. > - But starting out with the 16K FFT will do for now > You could loop over the data structures, and make a list of > of all steps (FFT, MAC, IFFT) and their parameters. Then if > you know the relative cost of the three basic operations you > try to divide this in 64 equal parts. > I don't really have to have 64 parts. It's just that I can't have more AND that each part may not exceed the available computational power for a given time quantum which could be defined as: One processor has 8 units @1.2 GHz == 9.6G instructions total 4 warps of 32 threads (=128) share the instructions evenly samplerate is 96K, periodsize 128 == 750 periods 9,6G / (750 * 128) == 10 instructions So each part must not have more than 100K insructions in any of the 64 parts, or else we'll get X-runs I have here an FFT implementation from 1987 by H V Sorensen. In the inermost loop I can count almost 50 instructions There is a 'dowhile' around that and a 'for' loop around the dowhile. I count each time we hit the work in the innermost loop or do the sin() and cos() in the outer loop, and then break out of the outer loop everytime 1000 'work' (5 instuctions) has been completed: 16384=2^13 Did 1030 'work' in 2 iteration(s) Did 1036 'work' in 4 iteration(s) Did 1046 'work' in 7 iteration(s) Did 1056 'work' in 12 iteration(s) Did 1008 'work' in 21 iteration(s) Did 1010 'work' in 32 iteration(s) Did 1008 'work' in 42 iteration(s) Did 1008 'work' in 72 iteration(s) Did 1002 'work' in 84 iteration(s) Did 1008 'work' in 126 iteration(s) Did 1004 'work' in 134 iteration(s) Did 1002 'work' in 167 iteration(s) Did 1002 'work' in 167 iteration(s) Did 1002 'work' in 179 iteration(s) Did 1004 'work' in 251 iteration(s) Did 1004 'work' in 251 iteration(s) Did 1004 'work' in 251 iteration(s) Final 936 'work' in 234 iteration(s) So doing the 16K FFT for a warp of 32 instances can be done in the first 18 parts (out of 64) at an estimate of 50% GPU Similarily a 4K FFT can be split evenly over 4 parts (of 16) 4096=2^11 Did 1024 'work' in 22 iteration(s) Did 1002 'work' in 94 iteration(s) Did 1002 'work' in 183 iteration(s) Final 812 'work' in 203 iteration(s) .. which appears to hit sin() and cos() relatively much more often You had a long laundry list, now what next? > There are some problems with this: > > - The relative cost of FFT and MAC is not know with any > precision. I'll have to use some source and count them. > - There may be less than 64 steps. > - A single 16k FFT may already be too much, and most FFT > libraries don't allow you to divide it into smaller > pieces. But division into smaller pieces is really an imperative here .. Guess I'll have to do some more code editing then. > > Again, if you *can* do the division, there is no need > to use multiple threads. you can just merge the lists > of steps for all partition sizes and execute this as > a static schedule using just function calls. This is > how jace worked. > > Ciao, > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Fri, Nov 06, 2009 at 09:09:39PM +0100, Jens M Andreasen wrote: > Adrian Hi! > I e-mailed you several times ... Am I blacklisted somehow? No, I have two mails from you in my Inbox about CUDA, but things are rather busy over here, and my student is also very short on time. So I guess he hasn't replied, yet? In the meantime, I had a first glance at the new Fermi chips. They support independent kernels, so this would leverage the whole design principle of au...@cuda. The cards are expected for Q1/2010, rumours are that it will take a little longer. However, the cards will have ECC almost everywhere (RAM, Caches, you name it), so the Fermi cards will be better suited for computation. Fermi is also aiming for onchip C++ exceptions, highler lever language support (Python), 64bits pointers and so on. Much closer to CPU programming. I hope to get one of these in April, that's when I hopefully will find some time to jump the band waggon. Until then, I have to rely on Max, but he's also busy as hell. Just a little side note: there are already compilers which generate CUDA code from ordinary for loops, e.g. the PGI compiler. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
