[LAD] Any package builders here?
Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? The following issue is wide spread: Forwarded Message Be sure you are able to run audio apps with the right privileges, eg. add your user to the audio group in /etc/groups and check out /etc/security/limits.conf for these lines @audio - rtprio 100 @audio - nice-10 Thank you :) I'm experienced in setting up audio/MIDI DAWs on Linux. Btw. setting up nice is nonsense, since it's for rt ;), but memlock is needed. http://www.jackaudio.org/linux_rt_config Cheers! Ralf I can't see any reason not do add such a dependency. Or is there a good reason not to do? Thanks, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, Jun 1, 2011 at 5:50 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? The following issue is wide spread: Forwarded Message Be sure you are able to run audio apps with the right privileges, eg. add your user to the audio group in /etc/groups and check out /etc/security/limits.conf for these lines @audio - rtprio 100 @audio - nice -10 for the n-hundreth time: nice has no role to play in improving the performance of pro-audio/music creation software. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
I might get flamed for this however GUI should not really be run with rt priority, that is an honour for the DSP engines. There are some reasonable arguments however for leaning on the scheduler with renice for the user interfaces to give them a bit of a bias over other system operations. Admittedly a big topic since the GUI probably sits on top of the windowing system anyway. So I have not used renice on graphics/GUI processes but I have worked on systems where the RT DSP code is happily chewing up 75% of CPU to churn out 32 unified synth voices and the GUI response can then give a bad impression of an application. Renice will help the sometime intensive graphics manipulation code (which is surprisingly close to DSP anyway if you are doing subpixel image transforms with shadow rendering) to get a little more of the now starved system resources. I don't see any point to advise not giving the audio group access to this option since you can argue that, whilst it does not do anything very spectacular, it is not going to damage system integrity any further than the already active RT priority rights. Low latency audio systems are all about tuning and this remains one of the tools available to you. Regards, cnik. we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer Date: Wed, 1 Jun 2011 07:27:39 -0400 From: p...@linuxaudiosystems.com To: ralf.mard...@alice-dsl.net CC: linux-audio-dev@lists.linuxaudio.org Subject: Re: [LAD] Any package builders here? On Wed, Jun 1, 2011 at 5:50 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? The following issue is wide spread: Forwarded Message Be sure you are able to run audio apps with the right privileges, eg. add your user to the audio group in /etc/groups and check out /etc/security/limits.conf for these lines @audio - rtprio 100 @audio - nice-10 for the n-hundreth time: nice has no role to play in improving the performance of pro-audio/music creation software. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, Jun 1, 2011 at 7:49 AM, Nick Copeland nickycopel...@hotmail.com wrote: I might get flamed for this however GUI should not really be run with rt priority, anyone who would do such a thing is a fool, indeed. that is an honour for the DSP engines. There are some reasonable arguments however for leaning on the scheduler with renice for the user interfaces to give them a bit of a bias over other system operations. what are those arguments? keep in mind that the algorithms inherent in SCHED_OTHER are targetting console-driven applications that do varying balances of disk i/o, computation and user input/output. they really don't address the situation of an app that needs to redraw with a relatively fixed interval on screen, nor do they provide any actual scheduling guarantees, which means that any disk i/o issues cannot be solved with nice - you still have to plan for and deal with the worst case scenario (which is why ardour's default disk i/o buffers are *FIVE SECONDS* long (we really have seen delays of this length when reading from disk!). nice becomes even less relevant in an era of separate i/o scheduling algorithms that are not designed to pay much (sometimes no) attention to nice values. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On 06/01/2011 11:50 AM, Ralf Mardorf wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? [..incorrect code snippet..] On Debian, both jack1 and jack2 packages do already include that. /etc/security/limits.d/audio.conf # Provided by the jackd package. # # Changes to this file will be preserved. # # If you want to enable/disable realtime permissions, run # #dpkg-reconfigure -p high jackd @audio - rtprio 95 @audio - memlockunlimited #@audio - nice -19 ---8- Maybe it's time to notify the debian-mm-team to remove the 'nice' line instead of commenting it out. OTOH it shows that they are aware that it's not strictly needed but may come in handy. I can't see any reason not do add such a dependency. Or is there a good reason not to do? I suppose it's simply pragmatic. Pulling this config out into a dedicated package might be a good idea. However I don't think there's any real-world use-case: How many audio apps support 'rtprio' directly (without JACK)? ..and how many pro-audio users do use this software but do not have JACK installed. I bet the number is zero. robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
Paul Davis wrote: what are those arguments? The argument is that rendering images, a part of the GUI, also requires chewing up a lot of CPU. These processes aren't involved in lots of disk IO, they can be manipulating images with either 2D or 3D transforms - as I said, it is pretty similar processes to DSP, it is intensive. The time slicing scheduler gives preference to runnable processes that are not using all of the CPU that is given to them and since the image manipulation code is doing exactly that when elements of the image are being moved then its priority pushes it down the list of runnable process - it may have to wait longer to carry on the rendering code. There are many aspects to a responsive system: you seem to be arguing that the only relevant one is the audio processing (which includes the disk subsystem). All I am saying is that when you use the mouse to pick up an element in the GUI and you move it that you then also want to see it move. RT scheduling and big buffers are the tools you use to maintain the audible components and renice is almost the only sad little thing available for all else. which is why ardour's default disk i/o buffers are *FIVE SECONDS* long (we really have seen delays of this length when reading from disk!). Ardours disk thread is sched_other. When you wait seconds for IO which finally arrives then your process is pretty much guaranteed, by the scheduler, to be the next process to take the free CPU as your priority improves as your waiting time goes up. A number crunching GUI does not have this benefit since it has not sat around waiting for the system to do something. Applying a renice will move it up the queue (although even at renice -20 it would not pre-empt the typical priority of this disk process). SCHED_OTHER are targetting console-driven applications that do varying balances of disk i/o, computation and user input/output. they really don't address the situation of an app that needs to redraw with a relatively fixed interval on screen, nor do they provide any actual scheduling guarantees, I was not even considering the effects of time scheduled actions in a GUI, simply tracking the interactions of the user with their interface when the system is under stress. I think we may have mixed the conversation. Ralf asked if this option should even be in the limits configuration. My answer, offlist, was that there were some potential uses and that since you can already hose an otherwise perfect system by giving a user permission to access to RT limits that there is no adverse effect of keeping this one. If there are good arguments not to have this as a limit for the audio group then have the distributions remove it, by all means. I don't see the negative side it being provided, it remains a tuning tool. Robin Gareus wrote: How many audio apps support 'rtprio' directly (without JACK)? I would have expected most of them to implement but that is just an opinion, I am not big on having to rely on other libraries for features that I consider crucial. As stated above, user experience is defined by system response, that includes the audio and the video. Bristol has these as separated processes and this is one of very few ways to control the its GUI CPU profile. ..and how many pro-audio users do use this software [...] I bet the number is zero. I would not contest that. I am not sure how rtprio and having renice in the limits config is really related to jack though. Regards, nick ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, 2011-06-01 at 08:06 -0400, Paul Davis wrote: On Wed, Jun 1, 2011 at 7:49 AM, Nick Copeland nickycopel...@hotmail.com wrote: I might get flamed for this however GUI should not really be run with rt priority, anyone who would do such a thing is a fool, indeed. that is an honour for the DSP engines. There are some reasonable arguments however for leaning on the scheduler with renice for the user interfaces to give them a bit of a bias over other system operations. what are those arguments? keep in mind that the algorithms inherent in SCHED_OTHER are targetting console-driven applications that do varying balances of disk i/o, computation and user input/output. they really don't address the situation of an app that needs to redraw with a relatively fixed interval on screen, nor do they provide any actual scheduling guarantees, which means that any disk i/o issues cannot be solved with nice - you still have to plan for and deal with the worst case scenario (which is why ardour's default disk i/o buffers are *FIVE SECONDS* long (we really have seen delays of this length when reading from disk!). nice becomes even less relevant in an era of separate i/o scheduling algorithms that are not designed to pay much (sometimes no) attention to nice values. This brings up I/O scheduling, which is nowadays just as configurable, but little discussed 'round these parts... I would think delays that crazy should definitely be avoidable, particularly in combination with pre-allocating contiguous disk chunks (fallocate w/ ext4 extents) Do we (Ardour) have users hitting the limit of their system's disk I/O abilities? I'd bet that tinkering with this stuff would yield a considerable improvement... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, 2011-06-01 at 14:40 +0200, Robin Gareus wrote: On 06/01/2011 11:50 AM, Ralf Mardorf wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? [..incorrect code snippet..] On Debian, both jack1 and jack2 packages do already include that. /etc/security/limits.d/audio.conf # Provided by the jackd package. # # Changes to this file will be preserved. # # If you want to enable/disable realtime permissions, run # #dpkg-reconfigure -p high jackd @audio - rtprio 95 @audio - memlockunlimited #@audio - nice -19 ---8- Maybe it's time to notify the debian-mm-team to remove the 'nice' line instead of commenting it out. OTOH it shows that they are aware that it's not strictly needed but may come in handy. I can't see any reason not do add such a dependency. Or is there a good reason not to do? I suppose it's simply pragmatic. Pulling this config out into a dedicated package might be a good idea. However I don't think there's any real-world use-case: How many audio apps support 'rtprio' directly (without JACK)? ..and how many pro-audio users do use this software but do not have JACK installed. I bet the number is zero. robin Hi Robin :) somebody on the Debian users list send this to me and he seems to use Jack by a package ;). -- Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, 2011-06-01 at 07:27 -0400, Paul Davis wrote: On Wed, Jun 1, 2011 at 5:50 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? The following issue is wide spread: Forwarded Message Be sure you are able to run audio apps with the right privileges, eg. add your user to the audio group in /etc/groups and check out /etc/security/limits.conf for these lines @audio - rtprio 100 @audio - nice-10 for the n-hundreth time: nice has no role to play in improving the performance of pro-audio/music creation software. You'll read such 'help' thousands of times when you're subscribed to regular distro users mailing lists or on non-audio Linux forums. I always post http://www.jackaudio.org/linux_rt_config when I read such recommendations. Since people usually are using Jack by a package, when thy use real-time audio apps IMO it's ok to include it to a Jack package, anyway, IMO there should be a dependency setting without nice and with memlock. I just want to inform about this issue. Coders and package builder might not be informed about what happens on non-audio users lists and forums. FWIW very often there are recommendations to _avoid_ a kernel-rt, since a distros 'default', 'desktop', 'generic' kernel should have the same capabilities and the kernel-rt should have disadvantages. The resume then could be, that people wonder, that they can't use Linux for complex audio sessions. IMO it doesn't make sense to package audio and MIDI applications without packaging the environment to use those apps. Users launch their package management GUI and install audio apps, they do not read FAQs, manuals. Then they make some tests recording two tracks. Later, when they do a real session, the issues start. -- Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
Le Wed, 1 Jun 2011 13:49:06 +0200, Nick Copeland nickycopel...@hotmail.com a écrit : I might get flamed for this however GUI should not really be run with rt priority, that is an honour for the DSP engines. There are some reasonable arguments however for leaning on the scheduler with renice for the user interfaces to give them a bit of a bias over other system operations. Admittedly a big topic since the GUI probably sits on top of the windowing system anyway. So I have not used renice on graphics/GUI processes but I have worked on systems where the RT DSP code is happily chewing up 75% of CPU to churn out 32 unified synth voices and the GUI response can then give a bad impression of an application. Renice will help the sometime intensive graphics manipulation code (which is surprisingly close to DSP anyway if you are doing subpixel image transforms with shadow rendering) to get a little more of the now starved system resources. I think than the wm in use can maybe have an impact on the graphical responsiveness. When running a single mono processor, I get up with jack at more than 95% CPU, this with gentoo running a rt kernel, fvwm and the fvwm-crystal theme. Sometime, the graphical response was a little bit slow. A few times, the wm was frozen during one or 2 seconds, even the cursor. But the audio process in JACK was just fine and without any xrun. I was very surprised, this was amazing, like in window$, but without the crash -:) I cannot imagine to do the same with kde or another wm, in fact I don't know if it can be possible. Now, on a multi-processor, I never experimented such a slow down of fvwm, but I didn't use jack with such a high load than before. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, 2011-06-01 at 18:16 +0200, Dominique Michel wrote: Le Wed, 1 Jun 2011 13:49:06 +0200, Nick Copeland nickycopel...@hotmail.com a écrit : I might get flamed for this however GUI should not really be run with rt priority, that is an honour for the DSP engines. There are some reasonable arguments however for leaning on the scheduler with renice for the user interfaces to give them a bit of a bias over other system operations. Admittedly a big topic since the GUI probably sits on top of the windowing system anyway. So I have not used renice on graphics/GUI processes but I have worked on systems where the RT DSP code is happily chewing up 75% of CPU to churn out 32 unified synth voices and the GUI response can then give a bad impression of an application. Renice will help the sometime intensive graphics manipulation code (which is surprisingly close to DSP anyway if you are doing subpixel image transforms with shadow rendering) to get a little more of the now starved system resources. I think than the wm in use can maybe have an impact on the graphical responsiveness. When running a single mono processor, I get up with jack at more than 95% CPU, this with gentoo running a rt kernel, fvwm and the fvwm-crystal theme. Sometime, the graphical response was a little bit slow. A few times, the wm was frozen during one or 2 seconds, even the cursor. But the audio process in JACK was just fine and without any xrun. I was very surprised, this was amazing, like in window$, but without the crash -:) I cannot imagine to do the same with kde or another wm, in fact I don't know if it can be possible. Now, on a multi-processor, I never experimented such a slow down of fvwm, but I didn't use jack with such a high load than before. Dominique On a weak computer the usage of a frame based environment, e.g. Ion2 does help, switching between a 'usual' DE and a 'lightweight' DE IMO doesn't make a big difference. On a fast computer IMO we should use the WM that is best for our work flows. But that's OT ... pardon. I'm queit now, just wanted to inform about, what I call a 'big problem', the strange settings for limits.conf. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
Since people usually are using Jack by a package, when thy use real-time audio apps IMO it's ok to include it to a Jack package, anyway, IMO there should be a dependency setting without nice and with memlock. Neither jack, ardour or any other app actually uses the 'nice' option simply because it is in the limits file. The file just says that if applications/users want to use a value this is what they are allowed to configure themselves without having to have root permissions and thereby invalidate a otherwise reasonable security policy. That is why having a 'nice' value in the file is useful: users can tune the system without needing the recourse of having the root password. FWIW very often there are recommendations to _avoid_ a kernel-rt, since a distros 'default', 'desktop', 'generic' kernel should have the same capabilities and the kernel-rt should have disadvantages. The resume then could be, that people wonder, that they can't use Linux for complex audio sessions. The issue is bigger than Linux. I was talking to Stings pianist, Kipper, on this subject a while ago now. He had just bought the biggest FO Mac for his studio. After a few days he pretty much took it back to the store and dumped it on them as it did not do what was written on the tin, demanding that they make it work. They had to tune it. OK, it finally did what he needs but the only difference is that either you have to do the work or somebody else does. Linux in itself is not the issue. IMO it doesn't make sense to package audio and MIDI applications without packaging the environment to use those apps. Again, this is not limited to Linux and the PAM limits file is not in itself the solution. The limits file only enables the possibility that applications can ask for what devos think is optimal for their function and that somebody can configure an optimised system without having to be root. That means the limits.conf should give that user or group sufficient access to all the resources that they might need. That includes negative 'nice' values for the cases where it might be useful. Regards, ninck. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On Wed, 2011-06-01 at 18:10 +0200, Ralf Mardorf wrote: On Wed, 2011-06-01 at 07:27 -0400, Paul Davis wrote: On Wed, Jun 1, 2011 at 5:50 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? The following issue is wide spread: Forwarded Message Be sure you are able to run audio apps with the right privileges, eg. add your user to the audio group in /etc/groups and check out /etc/security/limits.conf for these lines @audio - rtprio 100 @audio - nice-10 for the n-hundreth time: nice has no role to play in improving the performance of pro-audio/music creation software. You'll read such 'help' thousands of times when you're subscribed to regular distro users mailing lists or on non-audio Linux forums. I always post http://www.jackaudio.org/linux_rt_config when I read such recommendations. Since people usually are using Jack by a package, when thy use real-time audio apps IMO it's ok to include it to a Jack package, anyway, IMO there should be a dependency setting without nice and with memlock. I just want to inform about this issue. Coders and package builder might not be informed about what happens on non-audio users lists and forums. FWIW very often there are recommendations to _avoid_ a kernel-rt, since a distros 'default', 'desktop', 'generic' kernel should have the same capabilities and the kernel-rt should have disadvantages. The resume then could be, that people wonder, that they can't use Linux for complex audio sessions. Alas, the stock Debian kernel these days does *not* use Low Latency Desktop :( I don't know if derivatives have followed suit or not... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
On 06/01/2011 02:50 AM, Ralf Mardorf wrote: Hi :) could you please add a dependency to audio/MIDI app packages for your distros, that will set up real-time usage? The following issue is wide spread: Forwarded Message Be sure you are able to run audio apps with the right privileges, eg. add your user to the audio group in /etc/groups and check out /etc/security/limits.conf for these lines @audio - rtprio 100 First Planet CCRMA (when jack was in the Planet CCRMA repository) and now Fedora (which includes jack2 out of the box) have had such configuration set up for many years - including memory locking. I can't see any reason not do add such a dependency. Or is there a good reason not to do? To applications? Nope, not many if any would use SCHED_FIFO or SCHED_RR scheduling directly, pro audio apps rely on jack, and jack already has a proper configuration in most (all?) audio oriented distros. -- Fernando ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
