When the Music Spin is comming? Next Fedora release?

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

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>: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... <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 _______________________________________________ music mailing list music(a)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(a)ccrma.stanford.edu&gt;: > On Wed, 2010-07-21 at 17:35 +0200, David Sommerseth wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 19/07/10 18:57, Fernando Lopez-Lezcano wrote: >> > On Mon, 2010-07-19 at 13:46 -0300, Bernardo Barros wrote: >> >> > For this low-level task some engineering would be required? I'm not >> >> > this kind of guy who know much about tasks scheduling and priorities >> >> > (kernel level) but some people told me that real-time kernels patches >> >> > could slow down Fedora and I should not use it. >> > >> > Did those people by any chance provide you with _numbers_ that tell you >> > exactly what part of the kernel is impacted and by how much? (and, who >> > are they?) My guess is probably not. >> > >> > Yes, perhaps the rt patches could affect performance. Maybe. In some >> > subsystems (disk i/o, network come to mind). Maybe by a few %, in some >> > specific situations. I don't think the impact will be something you will >> > notice unless you measure it. >> >> To put things a bit straight. Yes, RT kernel will affect performance. >> Point. > > Agreed (for the reasons you explain below). > > I'd like to add that in the context of real-time performance for audio, > the lack of an RT kernel will also affect performance for the worse. So, > it depends on your goals. In the context of this list (music) Bernardo > comments he got the recommendation to not run RT kernels for performance > reasons ("some people told me that real-time kernels patches could slow > down Fedora and I should not use it"). > > If you are running a server, don't (unless, of course, you print money > by running thousands of trades a minute and you need millisecond > scheduling for that - that is why we have the rt patches after all :-). > If you are running a music oriented workstation that should handle > real-time interaction, then I'd say yes, run it. > > There are no black and white rules here. If you try the Fedora kernel > and it works for you in your particular music oriented situation then > run that. > > -- Fernando > > >> Will you notice it effectively on "normal desktop tasks"? Probably not >> much, but it depends on how your system is saturated, tuned and what >> kind of loads you have running. Real Time is not Real Fast and never >> will be. A real time kernel will not give any fair scheduling to your >> system, basically. > > (depends on your definition of "fair", for the purposes of an RT kernel > it schedules processes fairly, giving the rt tasks priority as is > intended by design). > >> All tasks (processes) which is set to use the SCHED_FIFO or SCHED_RR >> scheduling, even on the lowest priority will preempt and run it first >> over, ignoring all other SCHED_OTHER (normal) processes. SCHED_FIFO and >> SCHED_RR tasks with the highest priority will be processed before all >> other tasks, whenever they receive signals which requires these >> processes to run. This is the core nature of a real time system. >> >> So if you don't have many SCHED_FIFO or SCHED_RR tasks, and that they >> are light - you most probably will not notice anything at all. But in >> the moment you begin with heavy I/O dependent operations or other >> operations which requires processing time and the kernel have given them >> SCHED_FIFO scheduling and a rather high priority (which is not >> uncommon), it will slow down all the other running tasks. But this >> behaviour is possible to tune! >> >> So why would you want to run a real time kernel instead of a so called >> "real fast" kernel (normal kernels)? Latency determination. A real >> time kernel will strive to give you a predictable system latency, no >> matter how loaded your computer is. Which is a key-point for audio and >> video - you don't want the sound or video stream to be delayed because >> cron and updatedb wants to run. >> >> Some relevant information can be found here: >> >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime... >> >> >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime... >> >> >> <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime... >> >> >> kind regards, >> >> David Sommerseth >> _______________________________________________ >> music mailing list >> music(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/music > > >

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.

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

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.

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) ?