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>
Subject: Re: [Fedora-music-list] Music spin development - are you
ready to get involved ?
To: David Timms <dtimms(a)iinet.net.au>
Cc: music(a)lists.fedoraproject.org
Message-ID: <1279732394.22338.2.camel(a)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(a)ccrma.Stanford.EDU>
Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
To: David Sommerseth <davids(a)redhat.com>
Cc: music(a)lists.fedoraproject.org
Message-ID: <1279732915.22338.11.camel(a)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...
>
>
>
<
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>
Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
To: Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu>
Cc: music(a)lists.fedoraproject.org
Message-ID:
<AANLkTilHaP29jI3NnWHELlcH0rUPxzkbmBADvgq_3EkF(a)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(a)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...
>>
>>
>>
<
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>
Subject: Re: [Fedora-music-list] Music spin development - are you
ready to get involved ?
To: David Timms <dtimms(a)iinet.net.au>
Cc: music(a)lists.fedoraproject.org
Message-ID:
<AANLkTik2UTrKoyXjUv7GPmMkqg1CcCNCZGAFrmFtvt0D(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/7/21 David Timms <dtimms(a)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(a)gmail.com>
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>
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>
Subject: Re: [Fedora-music-list] [PlanetCCRMA] Music Spin
To: Bernardo Barros <bernardobarros2(a)gmail.com>
Cc: music(a)lists.fedoraproject.org
Message-ID: <1279779571.25375.245.camel(a)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(a)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...
> >>
> >>
> >>
<
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
*************************************