[Fedora-music-list] music spin development. I am ready to test/help with the audio spin.
William Blackburn
bill_- at hotmail.com
Fri Jul 23 21:41:35 UTC 2010
hello everyone,
I apologize for my ramblings this morning about the decision on whether or not to use the real time pre-emption patch. If there is anything I can do to help move the spin forward, just let me know. I am more than willing to help. I think one important aspect may be to put the new version of rakarrack on the spin because the version in the repos is a bit outdated and that particular package is moving very fast. There are instructions on how to build the package on the rakarrack website but I am not experienced enough to know how to incorporate that into the spin. Maybe I can talk to one of the devs and ask him his thoughts on the idea.
That's all I have for now. Until next time, ciao!
(tertl3)
> From: music-request at lists.fedoraproject.org
> Subject: music Digest, Vol 44, Issue 14
> To: music at lists.fedoraproject.org
> Date: Fri, 23 Jul 2010 14:57:06 +0000
>
> Send music mailing list submissions to
> music at lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/music
> or, via email, send a message with subject or body 'help' to
> music-request at lists.fedoraproject.org
>
> You can reach the person managing the list at
> music-owner at lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of music digest..."
>
>
> Today's Topics:
>
> 1. Re: music Digest, Vol 44, Issue 13 (William Blackburn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Jul 2010 15:57:03 +0100
> From: William Blackburn <bill_- at hotmail.com>
> Subject: Re: [Fedora-music-list] music Digest, Vol 44, Issue 13
> To: <music at lists.fedoraproject.org>
> Message-ID: <SNT133-w47CF783E49056989D7B0EAB6A30 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> I would like to second the notion that a real time kernel would be the best option for this distro. I hate to be a pessimist, but I don't see the point of making a music spin if it is going to have the same kernel as the the standard fedora distro. Anyone can add packages, but a working rt kernel is special. Also, if the real time kernel gets added, I think it may receive more attention and maybe get some nice improvements. If we have to call it a remix and not spin, that is not important to me. What is important is how useful it is to musicians and musicians do not like latency. I understand that the kernel patch can be installed quite easily and this is just my opinion. Please feel free to object to me or to correct me. :)
>
> > From: music-request at lists.fedoraproject.org
> > Subject: music Digest, Vol 44, Issue 13
> > To: music at lists.fedoraproject.org
> > Date: Thu, 22 Jul 2010 06:20:00 +0000
> >
> > Send music mailing list submissions to
> > music at lists.fedoraproject.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://admin.fedoraproject.org/mailman/listinfo/music
> > or, via email, send a message with subject or body 'help' to
> > music-request at lists.fedoraproject.org
> >
> > You can reach the person managing the list at
> > music-owner at lists.fedoraproject.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of music digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Music spin development - are you ready to get involved ?
> > (Fernando Lopez-Lezcano)
> > 2. Re: [PlanetCCRMA] Music Spin (Fernando Lopez-Lezcano)
> > 3. Re: [PlanetCCRMA] Music Spin (Bernardo Barros)
> > 4. Re: Music spin development - are you ready to get involved ?
> > (Bernardo Barros)
> > 5. Re: Music spin development - are you ready to get involved ?
> > (Christopher Antila)
> > 6. Re: [PlanetCCRMA] Music Spin (Fernando Lopez-Lezcano)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 21 Jul 2010 10:13:14 -0700
> > From: Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU>
> > Subject: Re: [Fedora-music-list] Music spin development - are you
> > ready to get involved ?
> > To: David Timms <dtimms at iinet.net.au>
> > Cc: music at lists.fedoraproject.org
> > Message-ID: <1279732394.22338.2.camel at localhost.localdomain>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Thu, 2010-07-22 at 01:19 +1000, David Timms wrote:
> > > Hi all,
> > >
> > > I have begun a wiki page to help track our goals for an audio creation
> > > Fedora spin:
> > > https://fedoraproject.org/wiki/AudioCreationSpinDevelopment
> > > , also available from the links at the bottom of the SIG page:
> > > https://fedoraproject.org/wiki/Audio_Creation
> > >
> > > If you want to be involved, please make sure you have a Fedora wiki
> > > account (fas), and list yourself in the collaborators section.
> > >
> > > You'll probably find many areas of the page need flashing out or fixing
> > > up; please do so, but also consider the limited time frame before the
> > > next Fedora release.
> > >
> > > A name like "Open Music Workstation" ... or "Fedora Jam", but you can
> > > think of better, I'm sure...
> > >
> > > Meanwhile, as we are trying to show off collaboration, is there any
> > > software that allows distant users to jam / create music over the
> > > internet ? This would be something really quite unique, compared to
> > > other spins.
> >
> > Jacktrip, already part of Planet CCRMA, see:
> > https://ccrma.stanford.edu/groups/soundwire/
> >
> > and in particular:
> > http://code.google.com/p/jacktrip/
> >
> > -- Fernando
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 21 Jul 2010 10:21:55 -0700
> > From: Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU>
> > Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
> > To: David Sommerseth <davids at redhat.com>
> > Cc: music at lists.fedoraproject.org
> > Message-ID: <1279732915.22338.11.camel at localhost.localdomain>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On 19/07/10 18:57, Fernando Lopez-Lezcano wrote:
> > > > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote:
> > > >> > For this low-level task some engineering would be required? I'm not
> > > >> > this kind of guy who know much about tasks scheduling and priorities
> > > >> > (kernel level) but some people told me that real-time kernels patches
> > > >> > could slow down Fedora and I should not use it.
> > > >
> > > > Did those people by any chance provide you with _numbers_ that tell you
> > > > exactly what part of the kernel is impacted and by how much? (and, who
> > > > are they?) My guess is probably not.
> > > >
> > > > Yes, perhaps the rt patches could affect performance. Maybe. In some
> > > > subsystems (disk i/o, network come to mind). Maybe by a few %, in some
> > > > specific situations. I don't think the impact will be something you will
> > > > notice unless you measure it.
> > >
> > > To put things a bit straight. Yes, RT kernel will affect performance.
> > > Point.
> >
> > Agreed (for the reasons you explain below).
> >
> > I'd like to add that in the context of real-time performance for audio,
> > the lack of an RT kernel will also affect performance for the worse. So,
> > it depends on your goals. In the context of this list (music) Bernardo
> > comments he got the recommendation to not run RT kernels for performance
> > reasons ("some people told me that real-time kernels patches could slow
> > down Fedora and I should not use it").
> >
> > If you are running a server, don't (unless, of course, you print money
> > by running thousands of trades a minute and you need millisecond
> > scheduling for that - that is why we have the rt patches after all :-).
> > If you are running a music oriented workstation that should handle
> > real-time interaction, then I'd say yes, run it.
> >
> > There are no black and white rules here. If you try the Fedora kernel
> > and it works for you in your particular music oriented situation then
> > run that.
> >
> > -- Fernando
> >
> >
> > > Will you notice it effectively on "normal desktop tasks"? Probably not
> > > much, but it depends on how your system is saturated, tuned and what
> > > kind of loads you have running. Real Time is not Real Fast and never
> > > will be. A real time kernel will not give any fair scheduling to your
> > > system, basically.
> >
> > (depends on your definition of "fair", for the purposes of an RT kernel
> > it schedules processes fairly, giving the rt tasks priority as is
> > intended by design).
> >
> > > All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR
> > > scheduling, even on the lowest priority will preempt and run it first
> > > over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and
> > > SCHED_RR tasks with the highest priority will be processed before all
> > > other tasks, whenever they receive signals which requires these
> > > processes to run. This is the core nature of a real time system.
> > >
> > > So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they
> > > are light - you most probably will not notice anything at all. But in
> > > the moment you begin with heavy I/O dependent operations or other
> > > operations which requires processing time and the kernel have given them
> > > SCHED_FIFO scheduling and a rather high priority (which is not
> > > uncommon), it will slow down all the other running tasks. But this
> > > behaviour is possible to tune!
> > >
> > > So why would you want to run a real time kernel instead of a so called
> > > "real fast" kernel (normal kernels)? Latency determination. A real
> > > time kernel will strive to give you a predictable system latency, no
> > > matter how loaded your computer is. Which is a key-point for audio and
> > > video - you don't want the sound or video stream to be delayed because
> > > cron and updatedb wants to run.
> > >
> > > Some relevant information can be found here:
> > >
> > > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html>
> > >
> > >
> > > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html>
> > >
> > >
> > > <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html>
> > >
> > >
> > > kind regards,
> > >
> > > David Sommerseth
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.10 (GNU/Linux)
> > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> > >
> > > iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d
> > > mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/
> > > =vj0G
> > > -----END PGP SIGNATURE-----
> > > _______________________________________________
> > > music mailing list
> > > music at lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/music
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 21 Jul 2010 15:18:16 -0300
> > From: Bernardo Barros <bernardobarros2 at gmail.com>
> > Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
> > To: Fernando Lopez-Lezcano <nando at ccrma.stanford.edu>
> > Cc: music at lists.fedoraproject.org
> > Message-ID:
> > <AANLkTilHaP29jI3NnWHELlcH0rUPxzkbmBADvgq_3EkF at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Thank you Fernando and David,
> >
> > Yes, the person that gave me advise was not an audio oriented guy.
> > That?s more clear now.
> >
> > Just a newbie question here: do you have to determine what programs
> > will have privileges? How the system knows how to handle taks of audio
> > and non-audio programs at the same time?
> >
> > 2010/7/21 Fernando Lopez-Lezcano <nando at ccrma.stanford.edu>:
> > > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote:
> > >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote:
> > >> >> > For this low-level task some engineering would be required? I'm not
> > >> >> > this kind of guy who know much about tasks scheduling and priorities
> > >> >> > (kernel level) but some people told me that real-time kernels patches
> > >> >> > could slow down Fedora and I should not use it.
> > >> >
> > >> > Did those people by any chance provide you with _numbers_ that tell you
> > >> > exactly what part of the kernel is impacted and by how much? (and, who
> > >> > are they?) My guess is probably not.
> > >> >
> > >> > Yes, perhaps the rt patches could affect performance. Maybe. In some
> > >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some
> > >> > specific situations. I don't think the impact will be something you will
> > >> > notice unless you measure it.
> > >>
> > >> To put things a bit straight. ?Yes, RT kernel will affect performance.
> > >> Point.
> > >
> > > Agreed (for the reasons you explain below).
> > >
> > > I'd like to add that in the context of real-time performance for audio,
> > > the lack of an RT kernel will also affect performance for the worse. So,
> > > it depends on your goals. In the context of this list (music) Bernardo
> > > comments he got the recommendation to not run RT kernels for performance
> > > reasons ("some people told me that real-time kernels patches could slow
> > > down Fedora and I should not use it").
> > >
> > > If you are running a server, don't (unless, of course, you print money
> > > by running thousands of trades a minute and you need millisecond
> > > scheduling for that - that is why we have the rt patches after all :-).
> > > If you are running a music oriented workstation that should handle
> > > real-time interaction, then I'd say yes, run it.
> > >
> > > There are no black and white rules here. If you try the Fedora kernel
> > > and it works for you in your particular music oriented situation then
> > > run that.
> > >
> > > -- Fernando
> > >
> > >
> > >> Will you notice it effectively on "normal desktop tasks"? ?Probably not
> > >> much, but it depends on how your system is saturated, tuned and what
> > >> kind of loads you have running. ?Real Time is not Real Fast and never
> > >> will be. ?A real time kernel will not give any fair scheduling to your
> > >> system, basically.
> > >
> > > (depends on your definition of "fair", for the purposes of an RT kernel
> > > it schedules processes fairly, giving the rt tasks priority as is
> > > intended by design).
> > >
> > >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR
> > >> scheduling, even on the lowest priority will preempt and run it first
> > >> over, ignoring all other SCHED_OTHER (normal) processes. ?SCHED_FIFO and
> > >> SCHED_RR tasks with the highest priority will be processed before all
> > >> other tasks, whenever they receive signals which requires these
> > >> processes to run. ?This is the core nature of a real time system.
> > >>
> > >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they
> > >> are light - you most probably will not notice anything at all. ?But in
> > >> the moment you begin with heavy I/O dependent operations or other
> > >> operations which requires processing time and the kernel have given them
> > >> SCHED_FIFO scheduling and a rather high priority (which is not
> > >> uncommon), it will slow down all the other running tasks. ?But this
> > >> behaviour is possible to tune!
> > >>
> > >> So why would you want to run a real time kernel instead of a so called
> > >> "real fast" kernel (normal kernels)? ?Latency determination. ?A real
> > >> time kernel will strive to give you a predictable system latency, no
> > >> matter how loaded your computer is. ?Which is a key-point for audio and
> > >> video - you don't want the sound or video stream to be delayed because
> > >> cron and updatedb wants to run.
> > >>
> > >> Some relevant information can be found here:
> > >>
> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html>
> > >>
> > >>
> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html>
> > >>
> > >>
> > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html>
> > >>
> > >>
> > >> kind regards,
> > >>
> > >> David Sommerseth
> > >> -----BEGIN PGP SIGNATURE-----
> > >> Version: GnuPG v1.4.10 (GNU/Linux)
> > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> > >>
> > >> iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d
> > >> mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/
> > >> =vj0G
> > >> -----END PGP SIGNATURE-----
> > >> _______________________________________________
> > >> music mailing list
> > >> music at lists.fedoraproject.org
> > >> https://admin.fedoraproject.org/mailman/listinfo/music
> > >
> > >
> > >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 21 Jul 2010 15:20:50 -0300
> > From: Bernardo Barros <bernardobarros2 at gmail.com>
> > Subject: Re: [Fedora-music-list] Music spin development - are you
> > ready to get involved ?
> > To: David Timms <dtimms at iinet.net.au>
> > Cc: music at lists.fedoraproject.org
> > Message-ID:
> > <AANLkTik2UTrKoyXjUv7GPmMkqg1CcCNCZGAFrmFtvt0D at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > 2010/7/21 David Timms <dtimms at iinet.net.au>:
> > > A name like "Open Music Workstation" ... or "Fedora Jam", but you can
> > > think of better, I'm sure...
> >
> > My suggestion is "Planet Music" Spin as an hommenage to the work of
> > Fernando to the Linux Audio community.
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 21 Jul 2010 20:16:20 -0400
> > From: Christopher Antila <crantila at gmail.com>
> > Subject: Re: [Fedora-music-list] Music spin development - are you
> > ready to get involved ?
> > To: music at lists.fedoraproject.org
> > Message-ID: <4C478DD4.9010509 at fedoraproject.org>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hello:
> >
> > Thanks to David for getting this started for us. I was going to post a
> > (nearly empty) wiki page for this purpose today, but it's better that a
> > more experienced user does it.
> >
> > I'll be adding my comments to the wiki pages as appropriate, and I
> > everybody else joins in, too.
> >
> > Also, I don't want to be beating people over the head with this, but the
> > Docs SIG is publishing a Guide for music and audio software with Fedora
> > 14. We'll have to see exactly how these fit together, but remember that
> > the Guide will be there.
> >
> > Finally, since I'm in fairly regular contact with Docs, I'll take
> > responsibility for maintaining the Audio Creation <-> Docs link, if the
> > Spin goes ahead. First step is to ask if we can add a "beat" in the
> > Release Notes ("What's new in Fedora 14 for Musicians?" or something
> > like that). If you don't know what this is, check out the Fedora 13
> > release notes... it would probably fall under chapter 7:
> >
> > http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html
> >
> >
> > Let's get this thing rolling!
> >
> > Christopher.
> >
> >
> > On 07/21/2010 11:19 AM, David Timms wrote:
> > > Hi all,
> > >
> > > I have begun a wiki page to help track our goals for an audio creation
> > > Fedora spin:
> > > https://fedoraproject.org/wiki/AudioCreationSpinDevelopment
> > > , also available from the links at the bottom of the SIG page:
> > > https://fedoraproject.org/wiki/Audio_Creation
> > >
> > > If you want to be involved, please make sure you have a Fedora wiki
> > > account (fas), and list yourself in the collaborators section.
> > >
> > > You'll probably find many areas of the page need flashing out or fixing
> > > up; please do so, but also consider the limited time frame before the
> > > next Fedora release.
> > >
> > > A name like "Open Music Workstation" ... or "Fedora Jam", but you can
> > > think of better, I'm sure...
> > >
> > > Meanwhile, as we are trying to show off collaboration, is there any
> > > software that allows distant users to jam / create music over the
> > > internet ? This would be something really quite unique, compared to
> > > other spins.
> > >
> > > Cheers, David.
> > > _______________________________________________
> > > music mailing list
> > > music at lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/music
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 21 Jul 2010 23:19:31 -0700
> > From: Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU>
> > Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
> > To: Bernardo Barros <bernardobarros2 at gmail.com>
> > Cc: music at lists.fedoraproject.org
> > Message-ID: <1279779571.25375.245.camel at localhost.localdomain>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Wed, 2010-07-21 at 15:18 -0300, Bernardo Barros wrote:
> > > Thank you Fernando and David,
> > >
> > > Yes, the person that gave me advise was not an audio oriented guy.
> > > That?s more clear now.
> > >
> > > Just a newbie question here: do you have to determine what programs
> > > will have privileges? How the system knows how to handle taks of audio
> > > and non-audio programs at the same time?
> >
> > You don't have to worry about determining which programs will have
> > privileges (at least directly).
> >
> > If you run Jack with real-time scheduling (if you use Qjackctl you have
> > to set the "Realtime" parameter in "Setup" and the user that is running
> > Jack has to be allowed to use real-time scheduling), then the audio
> > threads within any Jack client will run with real-time scheduling
> > automatically.
> >
> > All other threads in all your programs will run with "normal" scheduling
> > and will have less priority (that includes, for example, graphic i/o
> > threads or file i/o threads in the Jack audio programs - those don't
> > have elevated priority).
> >
> > It is all designed to make sure the chances of an audio glitch happening
> > are as small as possible.
> >
> > -- Fernando
> >
> >
> > > 2010/7/21 Fernando Lopez-Lezcano <nando at ccrma.stanford.edu>:
> > > > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote:
> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> > > >> Hash: SHA1
> > > >>
> > > >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote:
> > > >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote:
> > > >> >> > For this low-level task some engineering would be required? I'm not
> > > >> >> > this kind of guy who know much about tasks scheduling and priorities
> > > >> >> > (kernel level) but some people told me that real-time kernels patches
> > > >> >> > could slow down Fedora and I should not use it.
> > > >> >
> > > >> > Did those people by any chance provide you with _numbers_ that tell you
> > > >> > exactly what part of the kernel is impacted and by how much? (and, who
> > > >> > are they?) My guess is probably not.
> > > >> >
> > > >> > Yes, perhaps the rt patches could affect performance. Maybe. In some
> > > >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some
> > > >> > specific situations. I don't think the impact will be something you will
> > > >> > notice unless you measure it.
> > > >>
> > > >> To put things a bit straight. Yes, RT kernel will affect performance.
> > > >> Point.
> > > >
> > > > Agreed (for the reasons you explain below).
> > > >
> > > > I'd like to add that in the context of real-time performance for audio,
> > > > the lack of an RT kernel will also affect performance for the worse. So,
> > > > it depends on your goals. In the context of this list (music) Bernardo
> > > > comments he got the recommendation to not run RT kernels for performance
> > > > reasons ("some people told me that real-time kernels patches could slow
> > > > down Fedora and I should not use it").
> > > >
> > > > If you are running a server, don't (unless, of course, you print money
> > > > by running thousands of trades a minute and you need millisecond
> > > > scheduling for that - that is why we have the rt patches after all :-).
> > > > If you are running a music oriented workstation that should handle
> > > > real-time interaction, then I'd say yes, run it.
> > > >
> > > > There are no black and white rules here. If you try the Fedora kernel
> > > > and it works for you in your particular music oriented situation then
> > > > run that.
> > > >
> > > > -- Fernando
> > > >
> > > >
> > > >> Will you notice it effectively on "normal desktop tasks"? Probably not
> > > >> much, but it depends on how your system is saturated, tuned and what
> > > >> kind of loads you have running. Real Time is not Real Fast and never
> > > >> will be. A real time kernel will not give any fair scheduling to your
> > > >> system, basically.
> > > >
> > > > (depends on your definition of "fair", for the purposes of an RT kernel
> > > > it schedules processes fairly, giving the rt tasks priority as is
> > > > intended by design).
> > > >
> > > >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR
> > > >> scheduling, even on the lowest priority will preempt and run it first
> > > >> over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and
> > > >> SCHED_RR tasks with the highest priority will be processed before all
> > > >> other tasks, whenever they receive signals which requires these
> > > >> processes to run. This is the core nature of a real time system.
> > > >>
> > > >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they
> > > >> are light - you most probably will not notice anything at all. But in
> > > >> the moment you begin with heavy I/O dependent operations or other
> > > >> operations which requires processing time and the kernel have given them
> > > >> SCHED_FIFO scheduling and a rather high priority (which is not
> > > >> uncommon), it will slow down all the other running tasks. But this
> > > >> behaviour is possible to tune!
> > > >>
> > > >> So why would you want to run a real time kernel instead of a so called
> > > >> "real fast" kernel (normal kernels)? Latency determination. A real
> > > >> time kernel will strive to give you a predictable system latency, no
> > > >> matter how loaded your computer is. Which is a key-point for audio and
> > > >> video - you don't want the sound or video stream to be delayed because
> > > >> cron and updatedb wants to run.
> > > >>
> > > >> Some relevant information can be found here:
> > > >>
> > > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Installation_Guide/chap-Realtime_Installation_Guide-Why_Use_RT_to_Optimize_Latency.html>
> > > >>
> > > >>
> > > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/index.html>
> > > >>
> > > >>
> > > >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html>
> > > >>
> > > >>
> > > >> kind regards,
> > > >>
> > > >> David Sommerseth
> > > >> -----BEGIN PGP SIGNATURE-----
> > > >> Version: GnuPG v1.4.10 (GNU/Linux)
> > > >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> > > >>
> > > >> iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d
> > > >> mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/
> > > >> =vj0G
> > > >> -----END PGP SIGNATURE-----
> > > >> _______________________________________________
> > > >> music mailing list
> > > >> music at lists.fedoraproject.org
> > > >> https://admin.fedoraproject.org/mailman/listinfo/music
> > > >
> > > >
> > > >
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > music mailing list
> > music at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/music
> >
> > End of music Digest, Vol 44, Issue 13
> > *************************************
>
> _________________________________________________________________
> http://clk.atdmt.com/UKM/go/197222280/direct/01/
> Do you have a story that started on Hotmail? Tell us now
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.fedoraproject.org/pipermail/music/attachments/20100723/497e4f99/attachment.html
>
> ------------------------------
>
> _______________________________________________
> music mailing list
> music at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/music
>
> End of music Digest, Vol 44, Issue 14
> *************************************
_________________________________________________________________
http://clk.atdmt.com/UKM/go/195013117/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/music/attachments/20100723/b151f4d3/attachment-0001.html
More information about the music
mailing list