9:03 p.m.
New subject: [PlanetCCRMA] Music Spin
On Sat, Jul 17, 2010 at 9:41 PM, Bernardo Barros wrote:
When the Music Spin is comming? Next Fedora release?
Hmm. Speaking from the Fedora side, I wish I could give a date. With
the current resources, I would say, whenever we have the manpower.
Maybe 3-4 more dedicated packagers later. Anybody feel free to join :)
PlanetCCRMA side is another story.
Orcan
11:01 p.m.
New subject: [PlanetCCRMA] Music Spin
On 18/07/10 12:03, Orcan Ogetbil wrote:
On Sat, Jul 17, 2010 at 9:41 PM, Bernardo Barros wrote:
> When the Music Spin is comming? Next Fedora release?
Hmm. Speaking from the Fedora side, I wish I could give a date. With
the current resources, I would say, whenever we have the manpower.
Maybe 3-4 more dedicated packagers later. Anybody feel free to join :)
And remember
that if you have ever downloaded an application's source
code, then managed to build and run it locally, you are already some way
toward being a packager ;-)
rpm basically solidifies that knowledge into a .spec file to allow
repeatable builds, in a way that integrates with the system as a whole.
What time frames need to be met for Fedora to be able to have a hosted
spin ?
Remember that a Music Spin from Fedora can only contain packages already
in Fedora, so...
- what packages would you like to see on the spin ?
- don't forget that we can't package in Fedora non-free, nor patent
encumbered code...
PlanetCCRMA side is another story.
At the moment, needed for
special kernel (although with a quad core 3GHz
machine I'm not sure that I really require it ?).
Would CCRMA have enough resources for hosting a spin (maybe torrent)?
I'm keen to assist in the Fedora side; do we already have some wiki
information on what already exists, work done, goals and so forth ?
Cheers, David.
ps. On most fedora lists, when I hit reply, thunderbird automatically
sets me to be replying to the list. But the music list seems to be
different: a reply fills in only the person who wrote the original
message. Do other people have this problem ?
If so, I'd like to hassle the list master to fix it up...
12:19 p.m.
New subject: [PlanetCCRMA] Music Spin
On Sat, 2010-07-17 at 22:03 -0400, Orcan Ogetbil wrote:
On Sat, Jul 17, 2010 at 9:41 PM, Bernardo Barros wrote:
> When the Music Spin is comming? Next Fedora release?
>
Hmm. Speaking from the Fedora side, I wish I could give a date. With
the current resources, I would say, whenever we have the manpower.
Maybe 3-4 more dedicated packagers later. Anybody feel free to join :)
PlanetCCRMA side is another story.
I had a Planet CCRMA "distro" for Fedora 3 and 4 (ie: a customized dvd
that included Planet CCRMA - even kernels and all that - and that would
install everything from scratch). After a while I dropped it and nobody
missed it :-)
Same here as in the Fedora side, not enough manpower (and not enough
demand, it is easy to install Fedora and then add a repo for any
additional packages).
-- Fernando
2:01 p.m.
New subject: [PlanetCCRMA] Music Spin
David:
When I reply to lists in Thunderbird, I press the "reply list" button,
which is automatically placed beside the "reply" button. It might have
been put there in my Thunderbird by some add-on... who knows.
All:
Fedora's six-month release schedules mean that, in my opinion, the
community should start planning for a "Music Spin" release with Fedora
16 - yes, 16.
The spin would logically be prepared by the Audio Creation SIG, which is
both very small and already overwhelmed. The SIG's page is located on
the Fedora Wiki here:
https://fedoraproject.org/wiki/Audio_Creation
The first thing to decide is what a "Music Spin" means, and I'd like to
suggest that it means more than simply pre-installing music software
that's available for regular Fedora. In that case, the SIG would be
spending a lot of time and effort on something that does little more
than save ten Fedora users ten minutes each.
Here's what I think are the "minimum requirements" for a Music Spin:
1.) jack2 running as the default sound server, with PulseAudio connected
to JACK.
2.) PlanetCCRMA's real-time kernel and associated optimizations
installed by default.
3.) An easy and obvious way to install MP3 support - like the way
openSUSE installs the Flash player automatically, but avoids
distributing it with the distribution.
These aren't easy things, and the community isn't really robust enough
to really push out a Music Spin. Targeting a release with Fedora 16
would give just over a year to get an alpha release ready.
Maybe I'm way off-base here, and certainly I'm still very new to Fedora
and the Audio Creation SIG, but a dedicated spin seems like something
that you can't just sort of do. We'd have to be at the level of these:
http://spins.fedoraproject.org/
Christopher.
On 07/18/2010 12:01 AM, David Timms wrote:
On 18/07/10 12:03, Orcan Ogetbil wrote:
> On Sat, Jul 17, 2010 at 9:41 PM, Bernardo Barros wrote:
>> When the Music Spin is comming? Next Fedora release?
>
> Hmm. Speaking from the Fedora side, I wish I could give a date. With
> the current resources, I would say, whenever we have the manpower.
> Maybe 3-4 more dedicated packagers later. Anybody feel free to join :)
And remember that if you have ever downloaded an application's source
code, then managed to build and run it locally, you are already some way
toward being a packager ;-)
rpm basically solidifies that knowledge into a .spec file to allow
repeatable builds, in a way that integrates with the system as a whole.
What time frames need to be met for Fedora to be able to have a hosted
spin ?
Remember that a Music Spin from Fedora can only contain packages already
in Fedora, so...
- what packages would you like to see on the spin ?
- don't forget that we can't package in Fedora non-free, nor patent
encumbered code...
> PlanetCCRMA side is another story.
At the moment, needed for special kernel (although with a quad core 3GHz
machine I'm not sure that I really require it ?).
Would CCRMA have enough resources for hosting a spin (maybe torrent)?
I'm keen to assist in the Fedora side; do we already have some wiki
information on what already exists, work done, goals and so forth ?
Cheers, David.
ps. On most fedora lists, when I hit reply, thunderbird automatically
sets me to be replying to the list. But the music list seems to be
different: a reply fills in only the person who wrote the original
message. Do other people have this problem ?
If so, I'd like to hassle the list master to fix it up...
_______________________________________________
music mailing list
music(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/music
11:46 a.m.
New subject: [PlanetCCRMA] Music Spin
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. I don't know much
about this or what would be the best fine adjustments to get the best
of the OS for audio.
Planet-CCRMA did most of the work already very nicely :-) Yes, the
first step would be getting all important packages into Fedora. The
idea would be an OS oriented towards audio and score editing, so the
entire OS including kernel and fine adjustments should be optimized to
audio/low-latencies tasks.
Important things:
- ALL applications should send audio to JACK
- The main sound synthesis/processing software: SuperCollider and Pd-extended
- Audio plugsin LADSPA, DSSI, LV2 (would be possible to include VST support?)
- some kind of audio plugins packaging / modules ?
- Ardour, Jost and QTractor
2010/7/18 Christopher Antila <crantila(a)gmail.com>:
David:
When I reply to lists in Thunderbird, I press the "reply list" button,
which is automatically placed beside the "reply" button. It might have
been put there in my Thunderbird by some add-on... who knows.
All:
Fedora's six-month release schedules mean that, in my opinion, the
community should start planning for a "Music Spin" release with Fedora
16 - yes, 16.
The spin would logically be prepared by the Audio Creation SIG, which is
both very small and already overwhelmed. The SIG's page is located on
the Fedora Wiki here:
https://fedoraproject.org/wiki/Audio_Creation
The first thing to decide is what a "Music Spin" means, and I'd like to
suggest that it means more than simply pre-installing music software
that's available for regular Fedora. In that case, the SIG would be
spending a lot of time and effort on something that does little more
than save ten Fedora users ten minutes each.
Here's what I think are the "minimum requirements" for a Music Spin:
1.) jack2 running as the default sound server, with PulseAudio connected
to JACK.
2.) PlanetCCRMA's real-time kernel and associated optimizations
installed by default.
3.) An easy and obvious way to install MP3 support - like the way
openSUSE installs the Flash player automatically, but avoids
distributing it with the distribution.
These aren't easy things, and the community isn't really robust enough
to really push out a Music Spin. Targeting a release with Fedora 16
would give just over a year to get an alpha release ready.
Maybe I'm way off-base here, and certainly I'm still very new to Fedora
and the Audio Creation SIG, but a dedicated spin seems like something
that you can't just sort of do. We'd have to be at the level of these:
http://spins.fedoraproject.org/
Christopher.
On 07/18/2010 12:01 AM, David Timms wrote:
> On 18/07/10 12:03, Orcan Ogetbil wrote:
>> On Sat, Jul 17, 2010 at 9:41 PM, Bernardo Barros wrote:
>>> When the Music Spin is comming? Next Fedora release?
>>
>> Hmm. Speaking from the Fedora side, I wish I could give a date. With
>> the current resources, I would say, whenever we have the manpower.
>> Maybe 3-4 more dedicated packagers later. Anybody feel free to join :)
> And remember that if you have ever downloaded an application's source
> code, then managed to build and run it locally, you are already some way
> toward being a packager ;-)
>
> rpm basically solidifies that knowledge into a .spec file to allow
> repeatable builds, in a way that integrates with the system as a whole.
>
> What time frames need to be met for Fedora to be able to have a hosted
> spin ?
>
> Remember that a Music Spin from Fedora can only contain packages already
> in Fedora, so...
> - what packages would you like to see on the spin ?
> - don't forget that we can't package in Fedora non-free, nor patent
> encumbered code...
>
>> PlanetCCRMA side is another story.
> At the moment, needed for special kernel (although with a quad core 3GHz
> machine I'm not sure that I really require it ?).
>
> Would CCRMA have enough resources for hosting a spin (maybe torrent)?
>
> I'm keen to assist in the Fedora side; do we already have some wiki
> information on what already exists, work done, goals and so forth ?
>
> Cheers, David.
>
> ps. On most fedora lists, when I hit reply, thunderbird automatically
> sets me to be replying to the list. But the music list seems to be
> different: a reply fills in only the person who wrote the original
> message. Do other people have this problem ?
>
> If so, I'd like to hassle the list master to fix it up...
> _______________________________________________
> 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
11:57 a.m.
New subject: [PlanetCCRMA] Music Spin
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.
But of course, if you do audio work that would benefit from small buffer
sizes and low latency, the improvement you will get from the rt patches
will offset any impact in overall performance of the workstation (if
there is any).
-- Fernando
I don't know much
about this or what would be the best fine adjustments to get the best
of the OS for audio.
Planet-CCRMA did most of the work already very nicely :-) Yes, the
first step would be getting all important packages into Fedora. The
idea would be an OS oriented towards audio and score editing, so the
entire OS including kernel and fine adjustments should be optimized to
audio/low-latencies tasks.
Important things:
- ALL applications should send audio to JACK
- The main sound synthesis/processing software: SuperCollider and Pd-extended
- Audio plugsin LADSPA, DSSI, LV2 (would be possible to include VST support?)
- some kind of audio plugins packaging / modules ?
- Ardour, Jost and QTractor
2010/7/18 Christopher Antila <crantila@gmail.com>:panels?
> David:
>
> When I reply to lists in Thunderbird, I press the "reply list" button,
> which is automatically placed beside the "reply" button. It might have
> been put there in my Thunderbird by some add-on... who knows.
>
> All:
>
> Fedora's six-month release schedules mean that, in my opinion, the
> community should start planning for a "Music Spin" release with Fedora
> 16 - yes, 16.
>
> The spin would logically be prepared by the Audio Creation SIG, which is
> both very small and already overwhelmed. The SIG's page is located on
> the Fedora Wiki here:
> https://fedoraproject.org/wiki/Audio_Creation
>
> The first thing to decide is what a "Music Spin" means, and I'd like
to
> suggest that it means more than simply pre-installing music software
> that's available for regular Fedora. In that case, the SIG would be
> spending a lot of time and effort on something that does little more
> than save ten Fedora users ten minutes each.
>
> Here's what I think are the "minimum requirements" for a Music Spin:
> 1.) jack2 running as the default sound server, with PulseAudio connected
> to JACK.
> 2.) PlanetCCRMA's real-time kernel and associated optimizations
> installed by default.
> 3.) An easy and obvious way to install MP3 support - like the way
> openSUSE installs the Flash player automatically, but avoids
> distributing it with the distribution.
>
> These aren't easy things, and the community isn't really robust enough
> to really push out a Music Spin. Targeting a release with Fedora 16
> would give just over a year to get an alpha release ready.
>
> Maybe I'm way off-base here, and certainly I'm still very new to Fedora
> and the Audio Creation SIG, but a dedicated spin seems like something
> that you can't just sort of do. We'd have to be at the level of these:
> http://spins.fedoraproject.org/
>
>
> Christopher.
>
> On 07/18/2010 12:01 AM, David Timms wrote:
>> On 18/07/10 12:03, Orcan Ogetbil wrote:
>>> On Sat, Jul 17, 2010 at 9:41 PM, Bernardo Barros wrote:
>>>> When the Music Spin is comming? Next Fedora release?
>>>
>>> Hmm. Speaking from the Fedora side, I wish I could give a date. With
>>> the current resources, I would say, whenever we have the manpower.
>>> Maybe 3-4 more dedicated packagers later. Anybody feel free to join :)
>> And remember that if you have ever downloaded an application's source
>> code, then managed to build and run it locally, you are already some way
>> toward being a packager ;-)
>>
>> rpm basically solidifies that knowledge into a .spec file to allow
>> repeatable builds, in a way that integrates with the system as a whole.
>>
>> What time frames need to be met for Fedora to be able to have a hosted
>> spin ?
>>
>> Remember that a Music Spin from Fedora can only contain packages already
>> in Fedora, so...
>> - what packages would you like to see on the spin ?
>> - don't forget that we can't package in Fedora non-free, nor patent
>> encumbered code...
>>
>>> PlanetCCRMA side is another story.
>> At the moment, needed for special kernel (although with a quad core 3GHz
>> machine I'm not sure that I really require it ?).
>>
>> Would CCRMA have enough resources for hosting a spin (maybe torrent)?
>>
>> I'm keen to assist in the Fedora side; do we already have some wiki
>> information on what already exists, work done, goals and so forth ?
>>
>> Cheers, David.
>>
>> ps. On most fedora lists, when I hit reply, thunderbird automatically
>> sets me to be replying to the list. But the music list seems to be
>> different: a reply fills in only the person who wrote the original
>> message. Do other people have this problem ?
>>
>> If so, I'd like to hassle the list master to fix it up...
>> _______________________________________________
10:35 a.m.
New subject: [PlanetCCRMA] Music Spin
-----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.
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.
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-----
12:21 p.m.
New subject: [PlanetCCRMA] Music Spin
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
1:18 p.m.
New subject: [PlanetCCRMA] Music Spin
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
1:19 a.m.
New subject: [PlanetCCRMA] Music Spin
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
>
>
> 
4:20 p.m.
New subject: [PlanetCCRMA] Music Spin
On Sun, Jul 18, 2010 at 03:01:20PM -0400, Christopher Antila wrote:
Maybe I'm way off-base here, and certainly I'm still very new to Fedora
and the Audio Creation SIG, but a dedicated spin seems like something
that you can't just sort of do. We'd have to be at the level of these:
http://spins.fedoraproject.org/
I will point out that a Fedora Remix is a great way to get an alpha of
what would become a formal spin:
http://fedoraproject.org/wiki/Remix
"Fedora Remix" is something you can call a product regardless of
what's in it, essentially. There is a remix of Fedora called 'Omega
Linux' that is essentially Fedora+patent encumbered bits.
So, one or a few people could put together e.g. "Planet CCRMA Live, a
Fedora Remix" by this weekend that does exactly what you say right now
- JACK as default, realtime kernel, patent encumbered bits easy to
access (such as a how to in the installation guide for it that says
what rpmfusion.org packages to install.) Heck, you could use the
Fedora Installation Guide (or the quickstart version), rebrand it, and
add in all the parts that you need for this remix.
Aside from having a cool remix of Fedora, what would you have?
* A proof point. People could see right now what you are talking
about, and start talking about how things can be done in Fedora to
get equivalent functionality. For example, people may need
convincing that you have the chops as a SIG to maintain an alternate
kernel; prove it by supporting a remix for a few releases.
* A short-term solution to get the best FOSS audio software out in
people's hands.
* Training grounds. There is some heavy lifting to be done for a
spin, as you point out, and a remix is a legitimate way for people
to learn the same sets of skills needed for a formal spin. In
particular I suspect getting more packagers trained and committed
will benefit from real people holding a real CD and thinking, "Wow,
how can I help make this better?"
* Something we can give out to start growing the interest. I'll
commit to burning a spool of a Fedora audio remix to carry around
and hand out. Maybe someone will design a cool CD sleeve I can print
and glue. All of this interest requires an actual ISO to burn, and
I know I'm not doing it myself.
* Makes a nice addition to an original "Fedora Musician's Guide" (or a
rebranded version of that to include all the how-to-get-MP3-support
bits.) ;-)
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
4:35 p.m.
New subject: [PlanetCCRMA] Music Spin
On Sun, Jul 18, 2010 at 10:19:32AM -0700, Fernando Lopez-Lezcano wrote:
Same here as in the Fedora side, not enough manpower (and not enough
demand, it is easy to install Fedora and then add a repo for any
additional packages).
I tend to agree, just wanted to reiterate my offer from another place
in this thread. If there were enough interest to do 'Planet CCRMA
Audio Workstation, a Fedora Remix'[1], I and people like me would burn
and carry around copies. Especially if it were able to run as a live
Linux from a CD, DVD, or USB thumb drive, I would give copies to all
my musician and audio friends to boot to and try out.
It's the difference between, "Already-committed so I am going to install
and enable a repo," and "I don't know that Linux can work for me as a
musician/producer/podcaster/etc." I talk with far more of the latter
at FOSS events, etc.
I can't guarantee numbers, but I'm sure if you had an audio remix
available that people knew about, the Fedora Ambassadors around the
globe would start handing them out for the same reasons I said above.
- Karsten
[1] Don't turn to me for naming, clearly. :)
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
5:11 p.m.
New subject: [PlanetCCRMA] Music Spin
Why not make the Fedora Musician's Guide a wiki like project that
people with some free time could contribute with they know best? There
is already the FLOSS manual for Ardour and PureData that has already
done some work in this direction. And it is nice because you can make
a snapshot of the wiki and print a PDF from the website.
2010/7/30 Karsten Wade <kwade(a)redhat.com>:
On Sun, Jul 18, 2010 at 10:19:32AM -0700, Fernando Lopez-Lezcano
wrote:
>
> Same here as in the Fedora side, not enough manpower (and not enough
> demand, it is easy to install Fedora and then add a repo for any
> additional packages).
I tend to agree, just wanted to reiterate my offer from another place
in this thread. If there were enough interest to do 'Planet CCRMA
Audio Workstation, a Fedora Remix'[1], I and people like me would burn
and carry around copies. Especially if it were able to run as a live
Linux from a CD, DVD, or USB thumb drive, I would give copies to all
my musician and audio friends to boot to and try out.
It's the difference between, "Already-committed so I am going to install
and enable a repo," and "I don't know that Linux can work for me as a
musician/producer/podcaster/etc." I talk with far more of the latter
at FOSS events, etc.
I can't guarantee numbers, but I'm sure if you had an audio remix
available that people knew about, the Fedora Ambassadors around the
globe would start handing them out for the same reasons I said above.
- Karsten
[1] Don't turn to me for naming, clearly. :)
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
_______________________________________________
music mailing list
music(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/music
7:40 p.m.
New subject: [PlanetCCRMA] Music Spin
Hi:
The Fedora Musicians' Guide is an official document being prepared by the
Documentation Project. This carries much more weight than a wiki.
That said, increased participation would be great, and the Musicians' Guide
is already on the Fedora wiki in my User: pages. These could easily be
transferred into the real wiki, and maintained in sync or independently of
the official documentation, but I don't know if that sort of duplication is
a good idea. What we certainly could do is write complementary chapters
with programs that aren't (yet) in the official guide. Besides, as an
open-source project, the official guide itself is already like a wiki in
that people with free time can contribute with what they know best.
As for the current state of the Guide, the (terrible) first draft has been
finished for a week, and is available on the wiki. It's now been converted
to DocBook (the format used by the Fedora Docs website), and is stored in a
git repository on a fedorahosted.org account. The plan is to post a draft
to the Fedora Docs website this Tuesday, incorporating many improvements.
I'll post a notice to this list when the draft is ready - the more people
who can read it and find errors, the better!
The wiki version of the Musicians' Guide, from this point, is not the most
recent version. Notices will be posted soon to indicate this.
Christopher.
On 30 July 2010 18:11, Bernardo Barros <bernardobarros2(a)gmail.com> wrote:
Why not make the Fedora Musician's Guide a wiki like project
that
people with some free time could contribute with they know best? There
is already the FLOSS manual for Ardour and PureData that has already
done some work in this direction. And it is nice because you can make
a snapshot of the wiki and print a PDF from the website.
2010/7/30 Karsten Wade <kwade(a)redhat.com>:
> On Sun, Jul 18, 2010 at 10:19:32AM -0700, Fernando Lopez-Lezcano wrote:
>>
>> Same here as in the Fedora side, not enough manpower (and not enough
>> demand, it is easy to install Fedora and then add a repo for any
>> additional packages).
>
> I tend to agree, just wanted to reiterate my offer from another place
> in this thread. If there were enough interest to do 'Planet CCRMA
> Audio Workstation, a Fedora Remix'[1], I and people like me would burn
> and carry around copies. Especially if it were able to run as a live
> Linux from a CD, DVD, or USB thumb drive, I would give copies to all
> my musician and audio friends to boot to and try out.
>
> It's the difference between, "Already-committed so I am going to install
> and enable a repo," and "I don't know that Linux can work for me as a
> musician/producer/podcaster/etc." I talk with far more of the latter
> at FOSS events, etc.
>
> I can't guarantee numbers, but I'm sure if you had an audio remix
> available that people knew about, the Fedora Ambassadors around the
> globe would start handing them out for the same reasons I said above.
>
> - Karsten
>
> [1] Don't turn to me for naming, clearly. :)
> --
> name: Karsten 'quaid' Wade, Sr. Community Gardener
> team: Red Hat Community Architecture
> uri: http://TheOpenSourceWay.org/wiki
> gpg: AD0E0C41
>
> _______________________________________________
> 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
6:07 p.m.
New subject: [PlanetCCRMA] Music Spin
On Fri, Jul 30, 2010 at 08:40:44PM -0400, Christopher R. Antila wrote:
Hi:
The Fedora Musicians' Guide is an official document being prepared by the
Documentation Project. This carries much more weight than a wiki.
That said, increased participation would be great, and the Musicians' Guide
is already on the Fedora wiki in my User: pages. These could easily be
transferred into the real wiki, and maintained in sync or independently of
the official documentation, but I don't know if that sort of duplication is
a good idea. What we certainly could do is write complementary chapters
with programs that aren't (yet) in the official guide. Besides, as an
open-source project, the official guide itself is already like a wiki in
that people with free time can contribute with what they know best.
This is the hard fence we have to straddle with documentation in
Fedora. The wiki is a significantly lower barrier to entry, so 10x to
100x more people may work on a document, but it is a significantly
high barrier to working with the rest of Fedora in terms of
internationalization (i18n), localization (l10n), and document
management.
The release notes are rewritten each release on the wiki since most of
the material changes so much that it's OK to throw away 70% of the
writing and l10n of the previous release. People add content to
various pages, and the writing team massages it, then converts it to
XML.
A book such as the Fedora Installation Guide changes relatively little
for each release and so is kept in DocBook XML under the Publican
toolchain, with a smaller team of writers doing the updates. People
file bugs to get fixes done instead of editing the wiki.
So, it would not be trivial to reconvert from the wiki all the changes
and updates that an active community can keep there. Instead I would
propose a complementary scheme such as:
* Fedora Musician's Guide remains a stand-alone guide that focuses on
getting started using one or a few specific applications from each
area of audio tooling needs (recording, mixing, scoring, etc.)
* On the wiki are a number of stand-alone pages such as [[Scoring
music with Foo Bar]]. People who like to use that tool can help
write those pages and not worry about the other pages. They are all
part of a set of categories so they can be easily found together.
* A single wiki page e.g. [[Using audio tools with Fedora]] has a
table of contents that lists all of the stand-alone
application-specifi wiki pages. It also has some introductory
material, reference material, and any other new page ideas that
people have.
* The Musician's Guide regularly points the reader to that wiki-based
guide and set of pages for updated information. For example, the
guide can cover Audacity, and there can be a matching [[Using
Audacity in Fedora]] wiki page. The wiki page can cover 10x the
number of items that you want to cover in the guide, and be kept up
to date for the latest software in the repository. So, the
Musician's Guide is the starting point, and it does a hand-off to
the wiki at the end of its lessons.
* Every iteration of Fedora, the writers working on the Musician's
Guide look over the content changes done on the wiki (using history
pages, their own experience, etc.) Think of the wiki pages as an
upstream source repository that is full of baked and half-baked
code. The Musician's Guide picks from the best and most useful, or
new and interesting, or whatever, and updates or includes that
content in the next release of the guide.
This scheme gives two types of documentation: a fixed release guide
that can be printed and referenced; a more flowing set of wiki pages
with various quantities and qualities of information.
All of the above basically presumes an active audio SIG, but it also
is fault-tolerant. If a group of enthusiasts about a particular tool
stop writing about it, it doesn't stop the whole train. The
Musician's Guide can continue being updated, or not, without
interfering with the work on the wiki. The wiki work can draw more
instant gratification collaboration and help make the Fedora pages a
great reference for using all these tools under Fedora.
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
5:50 a.m.
New subject: [PlanetCCRMA] Music Spin
On 02/08/10 09:07, Karsten Wade wrote:
On Fri, Jul 30, 2010 at 08:40:44PM -0400, Christopher R. Antila
wrote:
...
This scheme gives two types of documentation: a fixed release guide
that can be printed and referenced; a more flowing set of wiki pages
with various quantities and qualities of information.
Is this scheme already used
in other fields of Fedora ?
Anyway, makes a lot of sense: developer (writers) just commit
fixes/changes to the wiki whenever they can and the (print) manual gets
updated with information as needed.
I do find that long wiki pages can be overwhelming to use. You see it
load, and the web browser vertical scroll bar pointer ends up tiny. You
scroll a few pages down, and realize that you simply don't have the time
to read that much, and try finding alternate material.
For a music spin, is there an easy process to extract the contents of
the wiki pages so that they can be added as ?html? to a spin. (eg assume
user doesn't have internet where they are using the spin) ?
5:47 p.m.
New subject: [PlanetCCRMA] Music Spin
On Mon, Aug 02, 2010 at 08:50:41PM +1000, David Timms wrote:
On 02/08/10 09:07, Karsten Wade wrote:
> On Fri, Jul 30, 2010 at 08:40:44PM -0400, Christopher R. Antila wrote:
...
> This scheme gives two types of documentation: a fixed release guide
> that can be printed and referenced; a more flowing set of wiki pages
> with various quantities and qualities of information.
Is this scheme already used in other fields of Fedora ?
Anyway, makes a lot of sense: developer (writers) just commit
fixes/changes to the wiki whenever they can and the (print) manual gets
updated with information as needed.
With the exception of back-end tooling that mostly hurts the Big Guide
writers, it's a pretty nice balance.
I do find that long wiki pages can be overwhelming to use. You see
it
load, and the web browser vertical scroll bar pointer ends up tiny. You
scroll a few pages down, and realize that you simply don't have the time
to read that much, and try finding alternate material.
Agreed, and MediaWiki has guidelines about keeping pages short that we
an use. We can also use transclusion, which lets us included multiple
individual pages in to one page, where desired. For example, if the
topic were Audacity, you create:
* A series of stand-alone topic-specific pages about Audacity (topics
can be reused across tools): [[Recording with Audacity]], [[Editing
with Audacity]], etc.
* Each topic-specific page can be further broken down to sub-topics to
keep the pages light and focused.
* Each page is in one or more categories, so the category pages become
a lightweight table-of-contents approach, e.g.:
http://fedoraproject.org/wiki/Fonts redirects to
http://fedoraproject.org/wiki/Category:Fonts
If you drill down in to those subcategories, you'll find dozens of
pages in the subcategories.
Anyway, I think we can make a set of reasonable nestings of categories
and a template page to follow, then highlight the main steps to start
and maintain an audio tool wiki page.
For a music spin, is there an easy process to extract the contents
of
the wiki pages so that they can be added as ?html? to a spin. (eg assume
user doesn't have internet where they are using the spin) ?
There is a package 'python-mwlibs' that includes tools for extracting
things from a MediaWiki instance. We use it for converting out an XML
that is about 80% useable as-is, it could probably make XHTML easily.
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
1:37 p.m.
New subject: [PlanetCCRMA] Music Spin
What we need is a proper comps setup, so that users can see Audio
Production packages in anaconda when they are installing Fedora. This
could be similar to the multimedia-menus project that I made, in terms
of grouping the applications.
I am not sure what is the best strategy here to extend comps. Making a
new Audio Production group and put everything in there? Or making a
similar tree structure as in the multimedia-menus package?
Orcan
4996
days inactive
5024
days old
18 comments
7 participants
participants (7)
-
Bernardo Barros -
Christopher Antila -
David Sommerseth -
Development discussions related to Fedora -
Fernando Lopez-Lezcano -
Karsten Wade -
Orcan Ogetbil