Re: [Fedora-music-list] music Digest, Vol 44, Issue 13

[William Blackburn]

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(a)lists.fedoraproject.org
>  Subject: music Digest, Vol 44, Issue 13
>  To: music(a)lists.fedoraproject.org
>  Date: Thu, 22 Jul 2010 06:20:00 +0000
>  
>  Send music mailing list submissions to
>  	music(a)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(a)lists.fedoraproject.org
>  
>  You can reach the person managing the list at
>  	music-owner(a)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(a)ccrma.Stanford.EDU&gt;
>  Subject: Re: [Fedora-music-list] Music spin development - are you
>  	ready to get involved ?
>  To: David Timms <dtimms(a)iinet.net.au&gt;
>  Cc: music(a)lists.fedoraproject.org
>  Message-ID: <1279732394.22338.2.camel(a)localhost.localdomain&gt;
>  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(a)ccrma.Stanford.EDU&gt;
>  Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
>  To: David Sommerseth <davids(a)redhat.com&gt;
>  Cc: music(a)lists.fedoraproject.org
>  Message-ID: <1279732915.22338.11.camel(a)localhost.localdomain&gt;
>  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...
>  > 
>  > 
>  >
> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime...
>  > 
>  > 
>  >
> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime...
>  > 
>  > 
>  > 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(a)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(a)gmail.com&gt;
>  Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
>  To: Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu&gt;
>  Cc: music(a)lists.fedoraproject.org
>  Message-ID:
>  	<AANLkTilHaP29jI3NnWHELlcH0rUPxzkbmBADvgq_3EkF(a)mail.gmail.com&gt;
>  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(a)ccrma.stanford.edu&gt;:
>  > 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...
>  >>
>  >>
>  >>
> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime...
>  >>
>  >>
>  >>
> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime...
>  >>
>  >>
>  >> 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(a)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(a)gmail.com&gt;
>  Subject: Re: [Fedora-music-list] Music spin development - are you
>  	ready to	get involved ?
>  To: David Timms <dtimms(a)iinet.net.au&gt;
>  Cc: music(a)lists.fedoraproject.org
>  Message-ID:
>  	<AANLkTik2UTrKoyXjUv7GPmMkqg1CcCNCZGAFrmFtvt0D(a)mail.gmail.com&gt;
>  Content-Type: text/plain; charset=UTF-8
>  
>  2010/7/21 David Timms <dtimms(a)iinet.net.au&gt;:
>  > 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(a)gmail.com&gt;
>  Subject: Re: [Fedora-music-list] Music spin development - are you
>  	ready to get involved ?
>  To: music(a)lists.fedoraproject.org
>  Message-ID: <4C478DD4.9010509(a)fedoraproject.org&gt;
>  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(a)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(a)ccrma.Stanford.EDU&gt;
>  Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
>  To: Bernardo Barros <bernardobarros2(a)gmail.com&gt;
>  Cc: music(a)lists.fedoraproject.org
>  Message-ID: <1279779571.25375.245.camel(a)localhost.localdomain&gt;
>  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(a)ccrma.stanford.edu&gt;:
>  > > 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...
>  > >>
>  > >>
>  > >>
> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime...
>  > >>
>  > >>
>  > >>
> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime...
>  > >>
>  > >>
>  > >> 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(a)lists.fedoraproject.org
>  > >> https://admin.fedoraproject.org/mailman/listinfo/music
>  > >
>  > >
>  > >
>  
>  
>  
>  
>  ------------------------------
>  
>  _______________________________________________
>  music mailing list
>  music(a)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