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
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...
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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... _______________________________________________
-----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_Reference_Guide/index.html
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html
kind regards,
David Sommerseth
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_Reference_Guide/index.html
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html
kind regards,
David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/ =vj0G -----END PGP SIGNATURE----- _______________________________________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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@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_Reference_Guide/index.html
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html
kind regards,
David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/ =vj0G -----END PGP SIGNATURE----- _______________________________________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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@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_Reference_Guide/index.html
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Tuning_Guide/index.html
kind regards,
David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxHE9YACgkQIIWEatLf4He6ZwCgjaodaHQY0KJue5TfTZiVhE0d mIEAnRksu5hm9bP6oGUu5ufRh2V1ESt/ =vj0G -----END PGP SIGNATURE----- _______________________________________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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
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
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. :)
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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
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
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) ?
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
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
-
Bernardo Barros -
Christopher Antila -
David Sommerseth -
Development discussions related to Fedora -
Fernando Lopez-Lezcano -
Karsten Wade -
Orcan Ogetbil