Re: [LAD] linux audio standards base?
On Mon, 2009-08-10 at 15:22 +1000, Patrick Shirkey wrote: PAE is required for NX support, and furthermore enables larger swapspace support for non-overcommit purposes. It has the cost of more pagetable lookup overhead, and also consumes more pagetable space per process. That suggests to me a similar situation to a win modem or auto resampling. Why? The sentences above do not specify what is compared and only handwavingly suggests a cost of more ... Mind you, 64bit pointers crawling all over the place ain't free either. - Should this be a recommended method coming from LAD? Rather than suggesting something that is defunkt by default, yes. BTW, it would be interesting to get some real world feedback from anyone who has this enabled already on a 32 bit platform. This would most likely be enabled by default for anybody who has installed a 32bit distro on a machine with 8GB memory. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] linux audio standards base?
On 08/10/2009 05:14 PM, Jens M Andreasen wrote: On Mon, 2009-08-10 at 15:22 +1000, Patrick Shirkey wrote: PAE is required for NX support, and furthermore enables larger swapspace support for non-overcommit purposes. It has the cost of more pagetable lookup overhead, and also consumes more pagetable space per process. That suggests to me a similar situation to a win modem or auto resampling. Why? The sentences above do not specify what is compared and only handwavingly suggests a cost of more ... Mind you, 64bit pointers crawling all over the place ain't free either. Simply because they don't specify the real world cost of using the method. - Should this be a recommended method coming from LAD? Rather than suggesting something that is defunkt by default, yes. I Absolutely agree. I will add that as it's coming from LAD it should ideally be the most efficient and future proof option with fallback for situations where it is not possible to implement the complete recommendation. I consider this approach part of the fallback. BTW, it would be interesting to get some real world feedback from anyone who has this enabled already on a 32 bit platform. This would most likely be enabled by default for anybody who has installed a 32bit distro on a machine with 8GB memory. Hmmm, I wonder how many people are in that situation? IIUC the only way to get 8GB or RAM onto a normal mobo is with a quad core 64 bit system. Are you suggesting that there are a lot of people who have one of these beasts who are running 32 bit OS on it? I know I'm not. Just out of interest I wonder if Fons would be willing to run 32 bit on the new system he is looking at purchasing? Can we get a show of hands? Is anyone running 32 bit with 8Gb of memory? How about 64 bit with the same specs? Cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[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] linux audio standards base?
On Sunday 09 August 2009 23:47:17 Fons Adriaensen wrote: On Sun, Aug 09, 2009 at 10:59:29PM +0200, Arnold Krille wrote: If aeolus is small that is good. Because that leaves more memory to cache the samples (outside of aeolus itself). The 120 MB includes all precomputed wavetables, and they are loaded permanently in memory. There is nothing else to be cached. Ah, okay. So aeolus was a bad example... Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] linux audio standards base?
On 08/10/2009 05:44 PM, Arnold Krille wrote: On Sunday 09 August 2009 23:47:17 Fons Adriaensen wrote: On Sun, Aug 09, 2009 at 10:59:29PM +0200, Arnold Krille wrote: If aeolus is small that is good. Because that leaves more memory to cache the samples (outside of aeolus itself). The 120 MB includes all precomputed wavetables, and they are loaded permanently in memory. There is nothing else to be cached. Ah, okay. So aeolus was a bad example... Oooh snap! Here's an updated list of the possible official recommendations for discussion: - A distribution should attempt to run jack as the default audio server and should attempt to make the process pf starting jack easy for a non technical user. - Pulseaudio should attempt to connect to jack by default and fall back to the alsa layer if jack is not running. - Closed source binaries such as those provided by companies like Adobe, Skype and Real Networks should provide flexibility for changing the audio library path and not be hardcoded to /usr/lib/ - For 32 Bit systems with memory of more than 8GB we recommend enabling CONFIG_X86_PAE in the kernel - For a 64 bit desktop system please ensure the 32 bit libraries for alsa, jack and pulseaudio are installed by default. cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] the role of lv2 extensions
David Robillard wrote: Building this logic on top of a set of optional extensions would seem to be a nightmare, and that is and always has been my main objection to this approach. FUD, nothing more. It would be no more of a nightmare than implementing it on top of... well, anything else; presumably you mean something defined in The LV2 Specification(TM). No offense but I doubt you really understand the mechanism judging by this comment. That nightmare (a.k.a. good design) is exactly what will allow all of the above to be solved. Proof is in the pudding, as they say. - Aside: Since this seems to be misunderstood frequently, I'll harp on the point a bit for the list in general (this is an explanation, not an invitation to argument): There is absolutely nothing second class, or (necessarily) optional, about LV2 extensions. A lot of thought has been put in to the extension/feature concept/mechanism, and it has been carefully designed specifically so that it is not a nightmare. Solving the above problems in extensions is not worse than if we were to ram it into the core spec itself. There is nothing inferior about it (wannabe dictator arguments aside, anyway). There are many things superior about it, however. The most important is social: nobody on this list needs to be convinced that having one specification define absolutely everything is a sure-fire way to have any potentially productive discussion devolve into endlessly long threads that end up nowhere because nobody can agree on what's needed and what isn't. Extensions are simply a modularisation of this process: problems can be solved independently by people who care about those particular problems. You can even work on actual implementations of things to test them out without any compatibility problems whatsoever. So, we have nice tidy little tractable problems, that can feasibly be solved well (see: UNIX). The end result is: the problems actually, really, can get solved. i guess part of the irritation around (and possibly delayed endorsement as compared to LADSPA) of lv2 stems from those extensions. from a design standpoint, i totally agree with all your points, and what little i've so far grokked of lv2 looks very nice indeed. *but*: it's a moving target, and few host authors have committed themselves to implement those extensions. the problem i see: the extensions mentioned on the lv2 website are of very different maturity, it's absolutely not clear which of those should be considered canonical and hence a *must-implement* feature, nor has there been any public discussion about any canonical set of core extensions (excuse that weird expression, but i can't think of anything better). crooked analogy alert... as it is now, lv2 resembles XML: you can do anything in principle, but there is almost no common semantics. we should move it to XHTML: define a set of mandatory extensions that everybody can expect to work pretty much everywhere (to the extent that it makes sense - i understand a synth host might have different priorities than, say, ardour). best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] linux audio standards base?
On Mon, 2009-08-10 at 18:01 +1000, Patrick Shirkey wrote: Oooh snap! :-D - Closed source binaries such as those provided by companies like Adobe, Skype and Real Networks should provide flexibility for changing the audio library path and not be hardcoded to /usr/lib/ - For 32 Bit systems with memory of more than 8GB we recommend enabling CONFIG_X86_PAE in the kernel Hey wait a millisec, is the problem really with Mozilla/Firefox being compiled for 64bit and it will go away if it is compiled for 32bit instead so it can use the Adobe, Real etc plugins as supplied by vendors in /usr/lib? And somehow I can't really see the advantage of a 64bit enabled mp3-player either .. or volume-control. Emacs perhaps? [(ducks)] With Gimp - having many huge layers in flight - I can see the advantage of 64bit. With most other applications though, it is not so clear. - For a 64 bit desktop system please ensure the 32 bit libraries for alsa, jack and pulseaudio are installed by default. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] the role of lv2 extensions
On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn Nettingsmeier wrote: from a design standpoint, i totally agree with all your points, and what little i've so far grokked of lv2 looks very nice indeed. *but*: it's a moving target, and few host authors have committed themselves to implement those extensions. the problem i see: the extensions mentioned on the lv2 website are of very different maturity, it's absolutely not clear which of those should be considered canonical and hence a *must-implement* feature, nor has there been any public discussion about any canonical set of core extensions (excuse that weird expression, but i can't think of anything better). crooked analogy alert... as it is now, lv2 resembles XML: you can do anything in principle, but there is almost no common semantics. we should move it to XHTML: define a set of mandatory extensions that everybody can expect to work pretty much everywhere (to the extent that it makes sense - i understand a synth host might have different priorities than, say, ardour). The evolutive process described and advocated by Dave is certainly one that can work - it is the way e.g. natural languages get defined and change over time. It's also why they tend to be inconsistent and why you need to study a lot more grammar than would be required otherwise. This should be compared to the (in most cases) quite consistent syntax of computer programming languages. And in the end, a plugin interface is a language that has to be understood by both the host and the plugin. Regarding the replication problem (How to structure a basic mono plugin, its host and their interaction so the plugin can be used in a variety of multichannel contexts having different requirements), this is something that can be and IMHO should be analysed in a systematic way. I'm just wearing my mathematician's hat of course. It boils down to graph theory, the way an algorithm can be split up and the order in which some steps must be performed. As as simple example the multichannel limiter must see all inputs before it can produce the first output, while an EQ would not require this. Things get mildly more complex if you also consider parallel execution, but this still can be analysed. Given a number of reasonable constraints this leads to a finite number of possible processing graphs, and these can be decribed in a systematic way. Any plugin interface should IMHO reflect this systematic nature, and not be a collection of ad-hoc solutions to partial problems and special cases. 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 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Davis schrieb: On Mon, Aug 10, 2009 at 5:06 AM, Christiankrampenschies...@freenet.de 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] the role of lv2 extensions
On 10 Aug 2009, at 10:41, Fons Adriaensen wrote: On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn Nettingsmeier wrote: from a design standpoint, i totally agree with all your points, and what little i've so far grokked of lv2 looks very nice indeed. *but*: it's a moving target, and few host authors have committed themselves to implement those extensions. the problem i see: the extensions mentioned on the lv2 website are of very different maturity, it's absolutely not clear which of those should be considered canonical and hence a *must-implement* feature, nor has there been any public discussion about any canonical set of core extensions (excuse that weird expression, but i can't think of anything better). crooked analogy alert... as it is now, lv2 resembles XML: you can do anything in principle, but there is almost no common semantics. we should move it to XHTML: define a set of mandatory extensions that everybody can expect to work pretty much everywhere (to the extent that it makes sense - i understand a synth host might have different priorities than, say, ardour). The evolutive process described and advocated by Dave is certainly one that can work - it is the way e.g. natural languages get defined and change over time. It's also why they tend to be inconsistent and why you need to study a lot more grammar than would be required otherwise. Sure. The original intention was that LV2 1.x would bless certain extensions as being required for that version, but that's not been necessary so far. This should be compared to the (in most cases) quite consistent syntax of computer programming languages. And in the end, a plugin interface is a language that has to be understood by both the host and the plugin. Or at least some of it does. There are some (many?) cases where a plugin is still fully usable by the host, even if it doesn't comprehend the extension. Port groups is an example of this. - 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
-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] linux audio standards base?
On 8/10/09, Patrick Shirkey pshir...@boosthardware.com wrote: On 08/10/2009 05:14 PM, Jens M Andreasen wrote: On Mon, 2009-08-10 at 15:22 +1000, Patrick Shirkey wrote: PAE is required for NX support, and furthermore enables larger swapspace support for non-overcommit purposes. It has the cost of more pagetable lookup overhead, and also consumes more pagetable space per process. That suggests to me a similar situation to a win modem or auto resampling. Why? The sentences above do not specify what is compared and only handwavingly suggests a cost of more ... Mind you, 64bit pointers crawling all over the place ain't free either. Simply because they don't specify the real world cost of using the method. - Should this be a recommended method coming from LAD? Rather than suggesting something that is defunkt by default, yes. I Absolutely agree. I will add that as it's coming from LAD it should ideally be the most efficient and future proof option with fallback for situations where it is not possible to implement the complete recommendation. I consider this approach part of the fallback. BTW, it would be interesting to get some real world feedback from anyone who has this enabled already on a 32 bit platform. This would most likely be enabled by default for anybody who has installed a 32bit distro on a machine with 8GB memory. Hmmm, I wonder how many people are in that situation? IIUC the only way to get 8GB or RAM onto a normal mobo is with a quad core 64 bit system. Are you suggesting that there are a lot of people who have one of these beasts who are running 32 bit OS on it? I know I'm not. Just out of interest I wonder if Fons would be willing to run 32 bit on the new system he is looking at purchasing? Can we get a show of hands? Is anyone running 32 bit with 8Gb of memory? How about 64 bit with the same specs? I'm running 64 bit, quad core with 8 gb of ram. Systems like this cost USD600 here now. :) I play a quite a few games as well as doing recording with it ;) Loki ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GPL Violation Alert! - update
On Wed, Aug 5, 2009 at 11:02 AM, Steve Harrisst...@plugin.org.uk wrote: An update. I've been contacted by the company that sells this software, asking for retrospective permission, or something along those lines. I'm not going to grant it - I don't really think I can, the SWH plugins represent the work of far too many people for me to feel comfortable doing that, and it's not necessary anyway, as long as they stick by whatever the conditions of the licence may be. But, I don't actually have a clear idea of what the GPL says should happen. Consensus seems to be that they need to distribute code for the plugins they include, but whether they are allowed to ship the plugins is another question. The crazy thing is that if they shipped their host in one package, and redistributed some LADPSA plugins (with source) in another then they would not be violating the licence as far as I can see - both actions are perfectly legitimate in isolation. However, shipping them in one package might be some sort of violation. That's slightly mad. I also got mail from the president of BeatKangz. I basically replied that they have two possibilities: (1) abide by the GPL; (2) buy a custom commercial license from me (since I believe I am the copyright holder for all my plugins, I can rightfully do this). Re: the madness surrounding the GPL, I think the dividing line (as per the spirit and not necessarily by the letter of the GPL) is whether the incorporated work (the plugins) form an integral part of the whole. I believe that if the host relies on some plugins for some critical operation (eg. think JAMin) then with all due respect, the virality of the GPL applies. However if the user initiates loading a plugin then it should not enforce any restriction on the host (taint it). I believe our case is an example of the former case. Even so since on their website BeanKangz brags about FX features in their product (integral part) without referencing that they are just standard plugins downloadable from the 'net. Tom ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] the role of lv2 extensions
On Mon, 2009-08-10 at 11:41 +0200, Fons Adriaensen wrote: On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn Nettingsmeier wrote: crooked analogy alert... as it is now, lv2 resembles XML: you can do anything in principle, but there is almost no common semantics. we should move it to XHTML: define a set of mandatory extensions that everybody can expect to work pretty much everywhere (to the extent that it makes sense - i understand a synth host might have different priorities than, say, ardour). The evolutive process described and advocated by Dave is certainly one that can work - it is the way e.g. natural languages get defined and change over time. It's also why they tend to be inconsistent and why you need to study a lot more grammar than would be required otherwise. In this domain, it seems pretty clear it's the only one that works... Consistency problems are simple to deal with, e.g. lv2plug.in can provide a nice centralized list of extensions and documentation if they fit certain guidelines. There is a page working towards these here: http://lv2plug.in/docs/index.php?title=Extension_Conventions As with everything else, it's not a problem with the tech, it's just work that somebody needs to do. Welcome to free software. People whining about the decentralized nature are really just whining that someone else hasn't done it for them ;) If you want to be able to point a finger and blame a dictator for something being crap, use VST. This should be compared to the (in most cases) quite consistent syntax of computer programming languages. And in the end, a plugin interface is a language that has to be understood by both the host and the plugin. And the primary design goal of virtually all languages is to allow modular decomposition of functionality. Hmmm... Would a language with no encapsulation (including user defined functions) and only keywords be a good language? You can't define everything that you do with a language in the language itself (for a sufficiently powerful language). Similarly, you can't define everything that you do with a plugin in the plugin spec itself (for a sufficiently powerful plugin spec). A good language defines a simple and consistent framework on which you /can/ build whatever you want. This is precisely what LV2 does. Extensions are analogous to modules/objects/abstract interfaces (depending on language). Any language worth using has a comparable mechanism. LADSPA, for example, doesn't, which is exactly why LADSPA is as weak as it was nearly 10 years ago when it was designed. LV2 currently is a heck of a lot more powerful than it was when it was designed, and gets better all the time. The reason for this is precisely that it was designed to provide a basic framework that can be extended, and not defining absolutely everything up front (which would have failed outright). There's not much sense in arguing about the merits of it at this point, look at reality. Regarding the replication problem (How to structure a basic mono plugin, its host and their interaction so the plugin can be used in a variety of multichannel contexts having different requirements), this is something that can be and IMHO should be analysed in a systematic way. I'm just wearing my mathematician's hat of course. It suits you more :) Of course it should be analysed in a systematic way. If you think this is in conflict with extensions, you are very mistaken. Being able to sit down and tackle this problem on its own is the whole point! It boils down to graph theory, the way an algorithm can be split up and the order in which some steps must be performed. As as simple example the multichannel limiter must see all inputs before it can produce the first output, while an EQ would not require this. Things get mildly more complex if you also consider parallel execution, but this still can be analysed. Given a number of reasonable constraints this leads to a finite number of possible processing graphs, and these can be decribed in a systematic way. Any plugin interface should IMHO reflect this systematic nature, and not be a collection of ad-hoc solutions to partial problems and special cases. Mathematician's don't usually wave their hands quite this much ;) The plugin obviously does know about all its inputs (or is free to ignore some). LV2 does reflect this systematic nature, because all I/O is still based on ports. This is the reason mentioned earlier why using multiple instances for this is wrong. Re: the hand-wavey FUD bit: they are not partial problems or special cases, they are complete, independent problems. Again, this is straight out of good design 101. SOMETIMES functionality is relatively large and intertwined, in which case the extension for it would also be large and encompass a lot (in the other direction, yes, an extension that solves a partial problem or a bunch of special cases is also crap). In these cases, there will
Re: [LAD] rtirq script is broken with 2.6.31
Robin Gareus wrote: Rui Nuno Capela wrote: Robin Gareus wrote: A minor thing: the status regexp in line 291: egrep '(^[[:blank:]]*PID|IRQ|irq)' also matches the rtirq.sh script itself. Thus I proposed to use egrep '(^[[:blank:]]*PID|IRQ|irq\/|sirq\-|softirq)' Also on the 64studio (with 2.6.29 and mawk) there's no additional info shown for the interrupts (due to the [:blank:]) but I can live with that. that's probably something that you weren't seeing anyway before, so you'll surely live with it still ;) yeah, forget about the [:blank:] issue with mawk; but I still consider rtirq itself being listed on `rtirq status` a minor bug ;) hopefully fixed in: http://www.rncbc.org/jack/rtirq-20090810.tar.gz enjoy -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] the role of lv2 extensions
On Mon, 2009-08-10 at 11:48 +0100, Steve Harris wrote: On 10 Aug 2009, at 10:41, Fons Adriaensen wrote: The evolutive process described and advocated by Dave is certainly one that can work - it is the way e.g. natural languages get defined and change over time. It's also why they tend to be inconsistent and why you need to study a lot more grammar than would be required otherwise. Sure. The original intention was that LV2 1.x would bless certain extensions as being required for that version, but that's not been necessary so far. That extensions can be mandatory for both/either the host and the plugin makes this unnecessary IMO. This is mostly a social/documentation problem, that should be solved in social/documentation ways, via the website. The core should stay as simple as possible, anyway. If nothing else it doesn't bump the revision number for no reason and force everyone to scramble to check if anything has broken, deal with packager delay, etc. -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 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: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 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
[LAD] LV2::GUI void port_event() and MIDI in?
Hi there, I'm trying to read midi events in a lv2 gui, but port_event() doesn't get called when new midi events appear. So, how do I get my midi events in the gui? Regards and thanks in advance Uli ___ 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] the role of lv2 extensions
David Robillard - Anyway, ...replication in basic form is pretty straightforward: the host needs a way to pass a 'replication factor' to the plugin. This raises a few obvious questions: - Should changing this at run-time be possible? This is more useful with polyphony than with replication for multi-channel purposes. This raises nasty realtime issues, but since buffer allocation is the host's problem and a clever host could possibly do it, I think the spec should make this possible. Maybe there are problems with internal plugin data that needs to replicate as well but in a non-realtime way though? I have written plugins that support port replication. In my case they *appear* to do so in realtime, but don't actually. The host re-instantiates a replacement (with the extra ports), and the same parameter settings, then inserts the replacement in the graph 'swapping out' the old instance (and destroying it). This happens pretty darn fast - milliseconds. The advantage is a minimal, simple API - when a plugin in created it queries it's 'replication factor' and adjusts itself accordingly. I don't need to support changes 'on the fly' while the plugin is processing audio (which could be difficult to perform within the constraints of realtime operation (without memory allocation etc). So you can avoid the nasty realtime issues, yet easily support run-time flexibility. Jeff McClintock ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LV2::GUI void port_event() and MIDI in?
On Mon, 2009-08-10 at 23:42 +0200, Ulrich Lorenz Schlüter wrote: On 08/10/2009 11:29 PM, David Robillard wrote: On Mon, 2009-08-10 at 23:15 +0200, Ulrich Lorenz Schlüter wrote: Hi there, I'm trying to read midi events in a lv2 gui, but port_event() doesn't get called when new midi events appear. So, how do I get my midi events in the gui? Does the plugin request notifications for that port? I think so, I'm trying to build a simple midi monitor. What host? lv2_jack_host (just because ingen has midi problems with me.) Erm. I don't recall adding GUI support to lv2_jack_host whatsoever, let alone notifications :) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] the role of lv2 extensions
On Tue, 2009-08-11 at 09:57 +1200, Jeff McClintock wrote: David Robillard - Anyway, ...replication in basic form is pretty straightforward: the host needs a way to pass a 'replication factor' to the plugin. This raises a few obvious questions: - Should changing this at run-time be possible? This is more useful with polyphony than with replication for multi-channel purposes. This raises nasty realtime issues, but since buffer allocation is the host's problem and a clever host could possibly do it, I think the spec should make this possible. Maybe there are problems with internal plugin data that needs to replicate as well but in a non-realtime way though? I have written plugins that support port replication. In my case they *appear* to do so in realtime, but don't actually. The host re-instantiates a replacement (with the extra ports), and the same parameter settings, then inserts the replacement in the graph 'swapping out' the old instance (and destroying it). This happens pretty darn fast - milliseconds. This is generally how stuff like this has to happen. Allocate and set up in some other thread, then replace in the process thread (usually just some pointer swapping). However, instantiation of a plugin isn't necessary a fast operation here. In some cases it could take much, much longer than a few milliseconds (plugins are free to do I/O or whatever they please at instantiation time). It is probably best to keep replication separate from instantiation for this reason. The advantage is a minimal, simple API - when a plugin in created it queries it's 'replication factor' and adjusts itself accordingly. I don't need to support changes 'on the fly' while the plugin is processing audio (which could be difficult to perform within the constraints of realtime operation (without memory allocation etc). So you can avoid the nasty realtime issues, yet easily support run-time flexibility. Sure, I don't think having new voices allocated in hard realtime is really necessary or feasible. Having the number of voices easy to increase while the plugin rolls without dropouts would be very useful though (e.g. the user increasing the maximum polyphony). Cheers, -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LV2::GUI void port_event() and MIDI in?
On 08/11/2009 12:03 AM, David Robillard wrote: On Mon, 2009-08-10 at 23:42 +0200, Ulrich Lorenz Schlüter wrote: On 08/10/2009 11:29 PM, David Robillard wrote: On Mon, 2009-08-10 at 23:15 +0200, Ulrich Lorenz Schlüter wrote: Hi there, I'm trying to read midi events in a lv2 gui, but port_event() doesn't get called when new midi events appear. So, how do I get my midi events in the gui? Does the plugin request notifications for that port? I think so, I'm trying to build a simple midi monitor. What host? lv2_jack_host (just because ingen has midi problems with me.) Erm. I don't recall adding GUI support to lv2_jack_host whatsoever, let alone notifications :) I'm testing the gui with ingen and the plugin with lv2_jack_host for now, as midi in doesn't seem to work in ingen. U. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] remembering rt-sched attributes - was: rtirq script is broken with 2.6.31
Robin Gareus wrote: Hello rt-users and -devs, I have a question about per-device-IRQ-threads in 2.6.31-rc5-rt1.1: After a suspend/resume cycle some IRQ-threads come up with a new PID. The scheduling policy of those threads is reset to default values instead of retaining the previously set values. Is this an issue that is being worked on? Or must userspace from now on re-init rtprio settings after each suspend/resume cycle? As you can see from the information below (from linux-audio-dev @ linuxaudio.org) not all IRQ-threads are re-started, but for example the HDA-Intel is. It may just as well be a specific issue with snd_hda_intel (and sdhci, e1000e, i810/intelfb,..). Robin Gareus wrote: Rui Nuno Capela wrote: [..] Yes, I'm also baffled at the high PIDs for IRQs. I hazard a guess that those are a result of a suspend/resume cycle; and I'll check later if the chrt settings do persist after a suspend/resume. It looks like the guess was correct. The PIDs change after suspend/resume and the chrt settings are retained here. Sorry I was too quick, there. After some more suspend/resumes cycles and a closer look: the previous statement is not correct. RTPRIO is reset when the IRQ handler process restarts under new PID. However not all IRQ threads are re-launched: [from /proc/interrupts] 17: 78393056 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel, ohci1394 18: 4519272099364 IO-APIC-fasteoi uhci_hcd:usb4, mmc0 before suspend: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1418 FF 90 - 130 0.0 S irq/8-rtc0 1450 FF 89 - 129 0.0 S irq/18-uhci_hcd 32506 FF 88 - 128 0.1 S irq/17-HDA Inte 32507 FF 87 - 127 0.0 S irq/17-ohci1394 1447 FF 50 - 90 0.2 S irq/17-uhci_hcd 32508 FF 50 - 90 0.0 S irq/18-mmc0 ... after resume: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1418 FF 90 - 130 0.0 S irq/8-rtc0 1450 FF 89 - 129 0.0 S irq/18-uhci_hcd 388 FF 50 - 90 0.0 S irq/17-HDA Inte 389 FF 50 - 90 0.0 S irq/17-ohci1394 390 FF 50 - 90 0.0 S irq/18-mmc0 1447 FF 50 - 90 0.2 S irq/17-uhci_hcd ... As you can see all IRQ17 threads get reset completely; on IRQ18 only mmc0 gets a new PID but the usb retains it's PID and rtprio. My first assumption - that it could correlate with the device being in use while suspending - did also proove wrong: I tried suspending with JACKd using an USB audio device on IRQ18 (instead of HDA-Intel on IRQ17) and after resume IRQ18 has still high rtprio, while IRQ17 has been reset whether in use or not. However, after unloading the HDA-Intel module, the other IRQ-threads on IRQ17 (ohci1394 and uhci_hcd:usb3) retain their PID and rtprio. So it seems there's something with the HDA driver and/or hardware that causes the kernel to re-initialize IRQ process. OT I usually unload the sd-card mmc0 driver and connect a USB-UA25 on uhci_hcd:usb4; It then is the sole device on IRQ18 and works without x-runs even at 64 spp * 3p / 48000sps = 4ms audio latency with JACKd. With 2.6.29.6-rt23 I get x-runs at these low latencies when not unloading the mmc0 driver. With 2.6.31-rc5-rt1.1 I don't. So the per-driver IRQ priority does work.. YAY. /OT picking on old subject, why not doing a plain `/etc/init.d/rtirq restart` on resume? byee -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ 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] linux audio standards base?
The following is all opinion which I think is what was requested: Here's an updated list of the possible official recommendations for discussion: We should not really be recommending anything and 'official' makes it sound rather orchestrated. We should be selling the benefits of the solution. If any attempt is made to mandate then we are going to run into reasonable resistance from both the apps and platform to any change as what is being proposed here increases compexity and abstraction of the audio interface which in anybodies book is a bad thing. - A distribution should attempt to run jack as the default audio server and should attempt to make the process pf starting jack easy for a non technical user. Why should a distribution do this? There are lots of reasons why they shouldn't. - Pulseaudio should attempt to connect to jack by default and fall back to the alsa layer if jack is not running. Why should pulse audio do this? There are lots of reasons why it shouldn't. - Closed source binaries such as those provided by companies like Adobe, Skype and Real Networks should provide flexibility for changing the audio library path and not be hardcoded to /usr/lib/ Why should they do this? Skype has 400M users, Adobe at least double that. Why should they make consideration for perhaps a small number of hundreds of users: those that want Linux, and Audio, and 64bit? You are welcome to change the figure of 'hundreds' into 'thousands' but nowhere on earth does it reach anything like the number of Skype users on 'another' platform. What are we offering Skype by way of a carrot to make them even consider this? You have to put the request into the perspective of it just being yet another request made of them and all of the other requests leading to potential financial benefits to their organisation. All Linux can offer Skype is a number of paying subscribers, and those that fit this specific demand are very small. - For 32 Bit systems with memory of more than 8GB we recommend enabling CONFIG_X86_PAE in the kerneld The limit is theoretically 4G. Its a lot lower on pretty much all motherboards. If we put in any demands like this one it will sound like we have no idea about what we are talking about. - For a 64 bit desktop system please ensure the 32 bit libraries for alsa, jack and pulseaudio are installed by default. Is this relevant? Are you asking for just the 32 bit libraries? Both of them? If somebody put this proposal in front of me, personally, I would not give it the time of day. There is no justification, no benefit being offered, and no real necessity to do it. There is nothing compelling. Nick. Again, this was all opinion. The goal is a good one, the means don't quite seem to rise up to it. _ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] linux audio standards base?
On 08/11/2009 08:59 AM, Nick Copeland wrote: The following is all opinion which I think is what was requested: Here's an updated list of the possible official recommendations for discussion: We should not really be recommending anything and 'official' makes it sound rather orchestrated. We should be selling the benefits of the solution. If any attempt is made to mandate then we are going to run into reasonable resistance from both the apps and platform to any change as what is being proposed here increases compexity and abstraction of the audio interface which in anybodies book is a bad thing. Ok, so from what you are saying there is nothing particularly wrong that the recommendations below would solve for a large enough number of people as to make it worth suggesting any of them at all? I don't think that I need to justify why the recommendations are offered but if they are really not to be considered necessary then that is a different story. The list below is simply attempting to solve as elegantly as possible the real usability issues that currently crop up for a normal user experience on 64 bit with the additional suggestion for the kernel config as people were wondering how to get extended memory on a 32 bit platform. I'm not sure if that last one is relevant myself but it was suggested so it's on the list of suggestions to be considered. Here's an additional possible recommendation that occurred to me last night. - If using skype consider purchasing a usb phone and using that as the audio interface instead of relying on the onboard sound device as it will probably make your life easier. Patrick Shirkey Boost Hardware Ltd - A distribution should attempt to run jack as the default audio server and should attempt to make the process pf starting jack easy for a non technical user. Why should a distribution do this? There are lots of reasons why they shouldn't. - Pulseaudio should attempt to connect to jack by default and fall back to the alsa layer if jack is not running. Why should pulse audio do this? There are lots of reasons why it shouldn't. - Closed source binaries such as those provided by companies like Adobe, Skype and Real Networks should provide flexibility for changing the audio library path and not be hardcoded to /usr/lib/ Why should they do this? Skype has 400M users, Adobe at least double that. Why should they make consideration for perhaps a small number of hundreds of users: those that want Linux, and Audio, and 64bit? You are welcome to change the figure of 'hundreds' into 'thousands' but nowhere on earth does it reach anything like the number of Skype users on 'another' platform. What are we offering Skype by way of a carrot to make them even consider this? You have to put the request into the perspective of it just being yet another request made of them and all of the other requests leading to potential financial benefits to their organisation. All Linux can offer Skype is a number of paying subscribers, and those that fit this specific demand are very small. - For 32 Bit systems with memory of more than 8GB we recommend enabling CONFIG_X86_PAE in the kerneld The limit is theoretically 4G. Its a lot lower on pretty much all motherboards. If we put in any demands like this one it will sound like we have no idea about what we are talking about. - For a 64 bit desktop system please ensure the 32 bit libraries for alsa, jack and pulseaudio are installed by default. Is this relevant? Are you asking for just the 32 bit libraries? Both of them? If somebody put this proposal in front of me, personally, I would not give it the time of day. There is no justification, no benefit being offered, and no real necessity to do it. There is nothing compelling. Nick. Again, this was all opinion. The goal is a good one, the means don't quite seem to rise up to it. Share your memories online with anyone you want anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LV2::GUI void port_event() and MIDI in?
On Tue, 2009-08-11 at 00:12 +0200, Ulrich Lorenz Schlüter wrote: On 08/11/2009 12:03 AM, David Robillard wrote: On Mon, 2009-08-10 at 23:42 +0200, Ulrich Lorenz Schlüter wrote: On 08/10/2009 11:29 PM, David Robillard wrote: On Mon, 2009-08-10 at 23:15 +0200, Ulrich Lorenz Schlüter wrote: Hi there, I'm trying to read midi events in a lv2 gui, but port_event() doesn't get called when new midi events appear. So, how do I get my midi events in the gui? Does the plugin request notifications for that port? I think so, I'm trying to build a simple midi monitor. What host? lv2_jack_host (just because ingen has midi problems with me.) Erm. I don't recall adding GUI support to lv2_jack_host whatsoever, let alone notifications :) I'm testing the gui with ingen and the plugin with lv2_jack_host for now, as midi in doesn't seem to work in ingen. Er, if MIDI doesn't work, notifications about MIDI are pretty unlikely to work ;) -dr P.S. Ticket, please, I'll try to look into it some time this week... ___ 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
