Linux-audio-dev June 2009

linux-audio-dev@lists.linuxaudio.org

65 participants
40 discussions

by Patrick Stinson

I wrote a scripting engine for a pro audio plugin by embedding a CPython interpreter. Since audio sequencing hosts use separate threads for each audio track, loading more than one instance of my plugin while running scripting code causes contention on Python's GIl and results in CPU spikes at low latencies. While CPython is more than capable of running fast enough in the audio thread for control-rate (MIDI) work, the GIL is killing us. Using process migration to move calls to CPython to daemon processes would take less code than forking python itself, but the scripting engine includes a python extension module that exposes pointers to the C++ classes in the audio engine. This complicates things quite a bit. The calls look like this: size = engine.getAudioBufferSize() engine.loadPatchFile(SOME_PATH) instrument.loadAudioFile(SOME_PATH_2) instrument.setVolume(.5) ...where 'engine' and 'instrument' are C++ classes in the audio engine that I wrapped in a python extension. I think that the biggest problem for me is tackling the complexity of managing new real time daemon processes for each audio track, finding an IPC method, and also implementing a middle-ware layer that would allow those synchronous calls to the engine be made back to the host. This is the sort of overhead that one can expect when trying to use process migration to work around the GIL. I consider myself an experienced coder, but just thinking about finding a clean, rock-solid daemon management and IPC mechanism that works on Mac and Windows freaks me out. Does anyone have any comments on this topic? cheers, -P

14 years, 9 months

Saving plugin presets

by Sebastian Moors

Hi, i would like to know if somebody has already thought about a (unified) way to save or export the settings of ladspa plugins (or vst,lv2..) I'm familiar with the idea of LASH, but i want to share plugin settings between different sessions. A typical use case: After recording songs with my drumset, the gate-plugin applied to basedrum and snare has most times (nearly) the same setting. At the moment this is a quite painful task: Ardour is able to save the settings, but you can't export these or exchange them between other applications. In addition, ardour's ladspa plugin dialog can just save the settings, changing an already saved settings is not possible. This results in a heap of saved settings and old revisions.. It would be great to export these settings, it could be implemented as a feature in applications like ardour2 ,jackrack or hydrogen. After exporting the setting to a plain text file (or xml), sharing the file with other people or between your computer would be no problem. What are your thoughts on this? What are the disadvantages? Thanks, Sebastian

14 years, 11 months

RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

by Stefano D'Angelo

Hello LADSPA, LV2 and DSSI specifications do not reccomend default discovery paths where hosts may look for plugins, which IMO is bad for the end user because: * end users shouldn't be asked to know about path environment variables by reading documentation in header files or looking for it on the web; * when their environment path variables are not set, some hosts choose to scan some hard-coded directories, but this changes among hosts and gets a lot worse on non UNIX-like operating systems (read Windows) - for example some might look inside some subdirectory of the current user's home, others might only look in /usr/lib/<api>, etc. Hereby I propose some default paths which could be used, in the hope that API authors lurking around here might want to recommend them and host authors might want to use them: LADSPA Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA Mac OS X: /Library/Audio/Plug-Ins/LADSPA, ~/Library/Audio/Plug-Ins/LADSPA DSSI Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi, /usr/local/lib/dssi, ~/.dssi Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI Mac OS X: /Library/Audio/Plug-Ins/DSSI, ~/Library/Audio/Plug-Ins/DSSI LV2 Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2, /usr/local/lib/lv2, ~/.lv2 Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2 Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2 Plus, we could do the same for LRDF data: Unix-like OSes with FHS/Unix-like filesystem layout: /usr/share/ladspa/rdf, /usr/local/share/ladspa/rdf, ~/.ladspa/rdf Windows: %PROGRAMFILES%\LADSPA\rdf, %APPDATA%\LADSPA\rdf Mac OS X: /Library/Audio/Plug-Ins/LADSPA/rdf, ~/Library/Audio/Plug-Ins/LADSPA/rdf What do you think about it? Stefano

15 years, 2 months

Re: [LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

by Jeff McClintock

> From: Chris Cannam > On Thu, Jun 25, 2009 at 9:13 PM, Jeff McClintock<jef(a)synthedit.com> > wrote: > > Windows has official rules for this. ?Users are no longer allowed to > add > > random files to an application's directory in "/Program > Files/Appname". > > Oh! This is news to me -- interesting news too, given that I > distribute Windows versions of SV without an installer and just expect > the user to copy it to %ProgramFiles% if they want it to go there, and > that it only looks in immediate subdirectories of %ProgramFiles% for > plugins of any sort. > > I don't recall anyone complaining to me that they couldn't install > plugins for it -- maybe this just means nobody is using it?! On Windows XP, many people run as administrator, so they won't notice anything. On Vista and Windows 7, they will get a 'UAC' Warning that they are doing something restricted. > Can you point to any documentation for this? I'd like to know what > other rules I might be falling afoul of. http://msdn.microsoft.com/en-us/library/ms995843.aspx (most of that is about system dlls and versioning). The relevant part for plugins is... " 3.4 Install any non side-by-side shared files to the correct locations The proper location for shared components depends on whether these components are shared across companies or by a single company. Shared components that are private to a single software vendor must be installed in one of two places. Do not store these files in the system directory common files directory\<company name> %ProgramFiles%\<company name>\Shared Files The common files directory can be accessed by passing CSIDL_PROGRAM_FILES_COMMON to the SHGetFolderPath API." > typically > > "C:\Program Files\Common Files\LADSPA Plugins..." > > I don't suppose you happen to know whether any Windows-based LADSPA > hosts are actually using this path? I don't know about LADSPA..but the latest Cubase uses "C:\Program Files\Common Files\Steinberg\VST2" for 3rd party plugins. Personally I think the company name could be omitted because many other individuals and companies need to put plugins in there too. Jeff M

15 years, 2 months

[ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

by Lennart Poettering

Heya, Just a quick announcement: I just moved into Fedora Rawhide a little daemon called "RealtimeKit" which will be enabled by default, and since it is now a dependency of PulseAudio and things work how they work this will then not only be available in Fedora 12 but also sooner or later in the other distributions as well, installed by default. So what does this do? It's a simple policy daemon that hands out SCHED_RR scheduling to normal user processes/threads that ask for it. So what's so fancy about it? Nothing. Except that is hopefully a good solution for handing out RT scheduling and is also actually secure. What's wrong with using RLIMIT_RPRIO? The simple fact that we cannot enable that by default since it basically empowers the user to freeze the machine. Also, asking the user to edit /etc/security/limits.conf is certainly not user-friendly. We want to enable RT scheduling for media aplications out-of-the-box. But what's wrong with relying on RLIMIT_RTTIME? Being a process limit it can very easily be circumvented for freezing the machine by combining an RT busy loop with a fork bomb. But what's wrong with relying on on a canary watchdog to avoid freezing systems? It's racy: an evildoer could fork more quickly than the canary watchdog daemon could demote its children. So a canary is not really a protection against a frozen system. Why not use cgroups for this? Because it's simply a horrible API, and using this for media applications has non-obvious consequences on using cgroups for their originally intended purpose -- which are containers. So what does RealtimeKit do that previous solutions didn't do? rtkit relies on a new kernel feature SCHED_RESET_ON_FORK that got recently merged into Ingo's tree and will hence shortly appear in 2.6.31. You can set that flag when entering SCHED_RR scheduling and this will then make sure that after forking a child will be reset to SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand out RT to a process we can be sure it won't "leak", and if we decide to take it away again we can be sure we can do that without having to be afraid of races around forking. rtkit enforces limits on the the number of threads/processes/users that get RT sched. It also does rate limiting, and calls into PolicyKit before handing out RT. Finally, as extra a-posteriori protection it also includes a canary watchdog. So what does that mean for you? If you don't do RT development or doing RT development only for embedded cases, or if you are a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy then it doesn't mean anything for you. However, if you are a desktop developer interested to get your stuff working out-of-the-box on modern distributions then you should think about calling into RealtimeKit for acquiring RT scheduling. RealtimeKit has a trivial API, to make a thread SCHED_RR it's just one D-Bus method you need to call. You can either code that call yourself or alternatively just copy the reference client implementation rtkit includes into your sources: http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.h http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.c For more information see this: http://git.0pointer.de/?p=rtkit.git;a=blob;f=README So yepp, it would be great if folks would adopt this in their apps, so that a user doesn't need to know about all those Unix intricacies such as resource limits and so on, but still get good perfomance in his media applications by default. This is now in Fedora Rawhide which will still take a few months to be released as F12. The other distros probably need a bit more time for this. This means this is not a burning issue yet, so this is mostly intended as a heads-up right now. Unless of course you are one of those cool dudes who are living on the bleeding edge. Packagers, you might want to steal this .spec file for you work: http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?revision=1.1&vie… Questions? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

15 years, 2 months

SynthForge - new modular synth builder

by Damon Chaplin

Hi, I've been working on a modular synth builder for a while and I've just put the first release up on SourceForge: http://sourceforge.net/project/showfiles.php?group_id=262459&package_id=322… (It requires slv2, GooCanvas 0.14, and the ladspa-swh-plugins if you want to build it.) There are also some screenshots here (the second one shows the created synth in use): https://sourceforge.net/project/screenshots.php?group_id=262459 This is all pre-alpha stuff so don't expect it to work that well yet (or even compile easily!). It can only create fairly basic synths at present. I could do with some help checking over the basic architecture and prioritising future work, so join the mailing list on sourceforge if you want to get involved. Damon

15 years, 2 months

Re: [LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

by Jeff McClintock

> > Windows (i.e. "%ProgramFiles%\LADSPA Plugins\rdf"). ?Not that I > > generally build with LRDF support on Windows anyway. > > This makes sense to me, if only it could be made "official"... > (windows paths too) Windows has official rules for this. Users are no longer allowed to add random files to an application's directory in "/Program Files/Appname". Permissions are set to prevent it and that directory is virtualized to prevent it. The exception is - Applications can install their own bundled plugins in "/Program Files/Appname" at install time only (because the installer has elevated privilege). User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically "C:\Program Files\Common Files\LADSPA Plugins..." Best Regards, Jeff McClintock

15 years, 2 months

[LAA] [ANN] guitarix-0.04.6-1 release

by hermann meyer

guitarix is a simple Linux Rock Guitar amplifier and is designed to achieve nice thrash/metal/rock/blues guitar sounds. Guitarix uses the Jack Audio Connection Kit as its audio backend and brings in one input and two output ports to the jack graph. Release 0.04.6-1 comes with some major changes: * Build environment and source code changes: - use of the python based waf build system. - use of the boost library for command line options. - various code cleanups and source tree restructuring All this has been done by our new project member James Warden. * Audio effect and modeling: - new tube model - fuzz Please read the README for more details regarding the new build process and the command line options. have fun ________________________________________________________________________ The standalone version of guitarix is based on GTK2+. But guitarix is also released as a suite of LADSPA plugins and can be used in e.g. ardour. guitarix is licensed under the GPL. Project page with screenshots: http://guitarix.sourceforge.net/ download: http://sourceforge.net/projects/guitarix/ For capture, guitarix uses the external application 'jack_capture' (version >= 0.9.30) written by Kjetil S. Matheussen. If you don't have it installed, you can look here: http://old.notam02.no/arkiv/src/?M=D For extra Impulse Responses, guitarix uses the convolution application 'jconv' created by Fons Adriaensen. If you don't have it installed, you can look here: http://www.kokkinizita.net/linuxaudio/index.html I(hermann) use faust to build the prototype and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html : Yann Orlary http://faust.grame.fr/ regards hermann & James

15 years, 2 months

Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!]

by James Warden

oops, yeah, wrong discussion thread :) I'm a coder too but not at all in linux-audio, although I started designing a few applications (nothing around DSP or linux core system, kernel, etc, this is way beyond my understanding at the moment. FYI, the closest thing to kernel stuff I did lately was patching oss2jack and kfusd so that this rather obsolete tool could run against kernel 2.6.29). But yes, I wanted to bring a user's point of view to the LAD discussion. About the dual boot, I don't know if it's the best solution but it is certainly a compromise. And one that I would not do myself. I tend to build my own PCs from various components for specific tasks. I find this process cheaper and feel I have a better control over its functioning / etc. About KDE, I am not particularly fond of it, it's just an old habit. I could never get used to gnome although it looks like a fine WM as well. I tried other stuff as well but in the end, I always come back to the shell :) OK, I'll stop the OT blabla. J. --- On Wed, 6/24/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: > From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!] > To: "James Warden" <warjamy(a)yahoo.com> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Wednesday, June 24, 2009, 8:05 AM > I dunno if you're a coder too, but > those words you wrote are the words of a user :). > > By the way I'm a fan of extremes, I like KDE (only with > KWin) ex 3.5.9 and Ion2, but actually I'm running GNOME and > this also has is advantages and disadvantages. > > Do you agree that a dual or multi boot might be the best > solution to fit to all needs? > > I would interpret your mail this way. You didn't blame any > sound server, but you make out for which usage you are fine > with which sound server. Am I wrong? > > The 'palm pre' thread is uncoupled from the origin thread, > that's why I guess it's okay to speak about user needs here, > nobody will disturb any technical expert knowledge > discussion at the original thread. > > By the way, an rt-audio distro like 64 Studio often works > OOB for rt-audio too, not for my hardware, but it is made to > fit to many hardware combinations. > > Thank you for reporting your experiences. > > Cheers, > Ralf > > James Warden wrote: > > Just a small comment, and then I shut up: > > > > the great thing about linux is its flexibility. I have > a few boxes at home doing different things: > > - a multimedia server based on mythtv, NFS and samba > > - a powerful DAW running an RT patched kernel > > - a couple of laptops for AOB (any other business) > > > > For the AOB laptops, it was nice not to do anything > once I installed the distro. Things worked OOB, and that was > it. > > > > For the DAW or multimedia server, that was another > story ... but simply because customized systems require, > well, customization. The all-in-one distro is and I think > will remain a utopia. > > This said, I recently upgraded my DAW to KDE 4.2 (was > 3.5.9 before upgrade) and that automatically installed > pulseaudio. I had already fiddled around with pulseaudio > about a year ago due to my using VirtualBox (another story). > I found pulse's features kinda cool and I quickly understood > it was not meant as a replacement or alternative to > Jack. > > As of today, my DAW has pulseaudio installed. But all > I had to do was: > > - open the KDE system settings - disable ALL sound > stuff I could find > > > > So basically, KDE offered me the possibility to not > interact at all with the sound layer. It was obviously not a > default setting but it was just a few clicks away. > > > > So let me be straight: it should remain like that. > > On average, a user installing e.g. KDE will expect > desktop sounds to work (sound notifications, mp3 players, > DVD playback, what-not). That's not what I want in my DAW at > all but being myself an old linux "power user", I knew that > it would do that (experience with artsd). I mean, how > could the KDE installation possibly know that it was to be > running on a DAW ?! :D I am glad the desktop config > interface allowed me to configure it the way I wanted (no > extra special services in the background, no sound system > other than what I want for my DAW). > > Now, if things were to change (no longer the > possibility to configure e.g. KDE the way I want), I would > definitely feel pissed-off and complain on some mailing > lists. But let's be also clear: pulseaudio is definitely NOT > the worst things that could happen. It works fine on my > laptops, I don't need to do anything about it and that's > what it was intended for: a generic and multifeatured > desktop sound system. But desktops are also used in other > contexts (e.g. DAW) and it would really be wise to keep > desktop components _optional_ (not only sound system but > also visual effects, etc). That's just simple wisdom and i > suggest we keep it that way. The same applies to jack. It is > a highly specialized tool and should remain so. > > > > > > OK, time to disappear from this discussion. > > > > Cheers, > > J. > > > > > > --- On Wed, 6/24/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > wrote: > > > > > >> From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > >> Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] > Safe real-time on thedesktop by default; Desktop/audio RT > developers, read this!] > >> To: "james morris" <james(a)jwm-art.net> > >> Cc: linux-audio-dev(a)lists.linuxaudio.org > >> Date: Wednesday, June 24, 2009, 6:45 AM > >> james morris wrote: > >> > >>> On 24/6/2009, "Patrick Shirkey" <pshirkey(a)boosthardware.com> > >>> > >> wrote: > >> > >>> > >>>> It would be helpful if things that could > make a > >>>> > >> big impact will > >> > >>>> continued to be discussed within the LAD > >>>> > >> community. However this is a > >> > >>>> difficult situation. No matter if the > discussions > >>>> > >> are starting prior to > >> > >>>> implementation or post implementation the > general > >>>> > >> direction of the > >> > >>>> arguments tend to be quite emotional. > >>>> > >>>> Is it just because audio guys have a bit > more > >>>> > >> artistic temperament than > >> > >>>> most other developers? > >>>> > > >>> I don't think this adds much to what has been > stated > >>> > >> by Fons and others, > >> > >>> but perhaps it explains a little? > >>> > >>> I'm not a hardcore audio developer like most > of the > >>> > >> guys here, but I've > >> > >>> been making audio/music/noise, and coding, > since the > >>> > >> days of 486sx25s > >> > >>> and windows 3.1. Back then, and for many years > after, > >>> > >> it was a real > >> > >>> concern to be able to disable as many > irrelevant (to > >>> > >> audio) processes in > >> > >>> the system as possible (as I'm sure you're > aware). > >>> > >>> Now I have a pretty capable system, but when I > want to > >>> > >> run RT audio apps > >> > >>> I still want to disable as many irrelevant > processes > >>> > >> on the system as I > >> > >>> can. > >>> > >>> For this reason I really dislike the big > monolithic > >>> > >> desktop environments. > >> > >>> There are several applications tied into them > (some > >>> > >> serious, plain > >> > >>> useful, or just fun) which I'd love to have > working > >>> > >> but which force me > >> > >>> to install all sorts of software I really > don't want > >>> > >> or need - along > >> > >>> with all sorts of processes running in the > >>> > >> background. > >> > >>> So it feels a bit freedom eroding. The choice > seems to > >>> > >> be between a > >> > >>> system which 'just works' but which wastes > system > >>> > >> resources on things > >> > >>> I don't want, or a system which I have to > spend hours > >>> > >> setting up, > >> > >>> constantly have to deal with the > idiosyncrasies of, > >>> > >> but which is as fast > >> > >>> and powerful as it could be. > >>> > >>> The notions of old, to raise the potential for > system > >>> > >> resources to be > >> > >>> only used for the job at hand (ie audio) are > still > >>> > >> strongly rooted and > >> > >>> people don't like it when they feel their > freedom to > >>> > >> use systems in > >> > >>> this way is threatened by forcing them to > install > >>> > >> software and have > >> > >>> running processes they don't want. > >>> > >>> James. > >>> > >> I guess (if needed) separating rt and > bread-and-butter > >> Linux by having a dual-boot is an acceptable > solution. A user with nearly no > >> knowledge could install a comfortable distro for > the everyday desktop > >> environment and another for real-time usage. Even > if somebody don't > >> have any trouble with his Linux install, he might > wish to have a safe Linux > >> for productions and another Linux to have fun and > fun sometimes > >> means to risk things, you won't risk for a > installation that needs > >> to be stable all the time, that's why a dual-boot > has also an advantage, > >> if there will be a joint venture for distro/ > desktop developers and > >> rt hardliners. I have a bad mobo and for rt e.g. I > need to set > >> irq priority for especially the one port where the > MIDI is connected to. > >> I don't think things like that should be done by > the desktop > >> environment. This seems to be impossible. > >> _______________________________________________ > >> Linux-audio-dev mailing list > >> Linux-audio-dev(a)lists.linuxaudio.org > >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > >> > >> > > > > > > > _______________________________________________ > > Linux-audio-dev mailing list > > Linux-audio-dev(a)lists.linuxaudio.org > > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > > > > > -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j… > "Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg > >

15 years, 2 months

Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!]

by James Warden

Just a small comment, and then I shut up: the great thing about linux is its flexibility. I have a few boxes at home doing different things: - a multimedia server based on mythtv, NFS and samba - a powerful DAW running an RT patched kernel - a couple of laptops for AOB (any other business) For the AOB laptops, it was nice not to do anything once I installed the distro. Things worked OOB, and that was it. For the DAW or multimedia server, that was another story ... but simply because customized systems require, well, customization. The all-in-one distro is and I think will remain a utopia. This said, I recently upgraded my DAW to KDE 4.2 (was 3.5.9 before upgrade) and that automatically installed pulseaudio. I had already fiddled around with pulseaudio about a year ago due to my using VirtualBox (another story). I found pulse's features kinda cool and I quickly understood it was not meant as a replacement or alternative to Jack. As of today, my DAW has pulseaudio installed. But all I had to do was: - open the KDE system settings - disable ALL sound stuff I could find So basically, KDE offered me the possibility to not interact at all with the sound layer. It was obviously not a default setting but it was just a few clicks away. So let me be straight: it should remain like that. On average, a user installing e.g. KDE will expect desktop sounds to work (sound notifications, mp3 players, DVD playback, what-not). That's not what I want in my DAW at all but being myself an old linux "power user", I knew that it would do that (experience with artsd). I mean, how could the KDE installation possibly know that it was to be running on a DAW ?! :D I am glad the desktop config interface allowed me to configure it the way I wanted (no extra special services in the background, no sound system other than what I want for my DAW). Now, if things were to change (no longer the possibility to configure e.g. KDE the way I want), I would definitely feel pissed-off and complain on some mailing lists. But let's be also clear: pulseaudio is definitely NOT the worst things that could happen. It works fine on my laptops, I don't need to do anything about it and that's what it was intended for: a generic and multifeatured desktop sound system. But desktops are also used in other contexts (e.g. DAW) and it would really be wise to keep desktop components _optional_ (not only sound system but also visual effects, etc). That's just simple wisdom and i suggest we keep it that way. The same applies to jack. It is a highly specialized tool and should remain so. OK, time to disappear from this discussion. Cheers, J. --- On Wed, 6/24/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: > From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!] > To: "james morris" <james(a)jwm-art.net> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Wednesday, June 24, 2009, 6:45 AM > james morris wrote: > > On 24/6/2009, "Patrick Shirkey" <pshirkey(a)boosthardware.com> > wrote: > > > > > >> It would be helpful if things that could make a > big impact will > >> continued to be discussed within the LAD > community. However this is a > >> difficult situation. No matter if the discussions > are starting prior to > >> implementation or post implementation the general > direction of the > >> arguments tend to be quite emotional. > >> > >> Is it just because audio guys have a bit more > artistic temperament than > >> most other developers? > >> > > > > I don't think this adds much to what has been stated > by Fons and others, > > but perhaps it explains a little? > > > > I'm not a hardcore audio developer like most of the > guys here, but I've > > been making audio/music/noise, and coding, since the > days of 486sx25s > > and windows 3.1. Back then, and for many years after, > it was a real > > concern to be able to disable as many irrelevant (to > audio) processes in > > the system as possible (as I'm sure you're aware). > > > > Now I have a pretty capable system, but when I want to > run RT audio apps > > I still want to disable as many irrelevant processes > on the system as I > > can. > > > > For this reason I really dislike the big monolithic > desktop environments. > > There are several applications tied into them (some > serious, plain > > useful, or just fun) which I'd love to have working > but which force me > > to install all sorts of software I really don't want > or need - along > > with all sorts of processes running in the > background. > > > > So it feels a bit freedom eroding. The choice seems to > be between a > > system which 'just works' but which wastes system > resources on things > > I don't want, or a system which I have to spend hours > setting up, > > constantly have to deal with the idiosyncrasies of, > but which is as fast > > and powerful as it could be. > > > > The notions of old, to raise the potential for system > resources to be > > only used for the job at hand (ie audio) are still > strongly rooted and > > people don't like it when they feel their freedom to > use systems in > > this way is threatened by forcing them to install > software and have > > running processes they don't want. > > > > James. > > I guess (if needed) separating rt and bread-and-butter > Linux by having a > dual-boot is an acceptable solution. A user with nearly no > knowledge > could install a comfortable distro for the everyday desktop > environment > and another for real-time usage. Even if somebody don't > have any trouble > with his Linux install, he might wish to have a safe Linux > for > productions and another Linux to have fun and fun sometimes > means to > risk things, you won't risk for a installation that needs > to be stable > all the time, that's why a dual-boot has also an advantage, > if there > will be a joint venture for distro/ desktop developers and > rt > hardliners. I have a bad mobo and for rt e.g. I need to set > irq priority > for especially the one port where the MIDI is connected to. > I don't > think things like that should be done by the desktop > environment. This > seems to be impossible. > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

15 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev June 2009