Call to arms - Fedora Audio Spin

[Brendan Jones]

Hi all,

Traditionally Fedora has been known to walk the bleeding edge in free 
and open source software development but for some reason this has never 
been realised in the realms of pro-audio/music creation.

Fedora has never really attracted the support of the audio development 
community, and as a direct result has only flagging support from audio 
users, enthusiasts and professionals alike.

I think there are a number of reasons for this:
   1) Strict packaging and licensing guidelines,
   2) relatively short release support cycles
   3) the absence of an stock RT kernel
   4) the effort required to tailor an installation for audio use

Distributions like Debian/Ubuntu/Arch (and others like AVLinux) have 
garnered strong support because they in some way address all of these 
issues. Fedora however...

1) and 2) we can't change. In fact at the end of the day these 
strengthen the distribution by making the packages we ship more robust 
and closer to upstream. It also demands a certain amount of love to 
ensure that updates/ABI bumps/breakages are dealt with decisively and 
swiftly. It also means that audio developers are more unlikely to 
maintain their own packages in Fedora (we need more maintainers)

3) I can't see happening any time soon. The kernel team maintain so many 
out of tree patches already that I don't think they really have the time 
nor desire to maintain the realtime kernel as well. I don't see this as 
a problem - recent kernels have incorporated much of the the rt kernel 
patches of old and should satisfy most users. For those with more 
stringent requirements can rely on the CCRMA patched kernels

4) is where I think an audio spin comes into play. If we can 
collate/automate all of the steps involved in setting up Fedora for 
audio production we will attract both users and maintainers alike 
alleviating the problems caused by 1 and 2.

I'm proposing to formally revive the past Fedora Audio Spin / Music 
Creation efforts of a couple of years ago in time for an F18 Audio spin 
release. This means we have one whole release cycle to get all of the 
packages we require into stable so they can be available for Live 
composes for the F18 release cycle.

Apart from packaging efforts, the last few weeks for me has been an 
information gathering exercise. More on this soon, but briefly, the 
current to do list is:
  - pulling in all of the must have packages from CCRMA
  - determining the package list
  - packaging the Fedora Musician's guide
  - repackaging/patching rpmfusion packages for Fedora (qtractor and
    others if required)
  - developing sane RT priorities for the stock kernels (threadirqs)
  - consensus on distribution media, default desktop/supported desktops
  - default systemd enabled services
  - themes and artwork
  - resubmit the Spin proposal for F18

If you want to contribute, here's how:
  - become a contributor/get a FAS account [1] and join the
    music-creation group
  - help maintain the audio creation wiki's  (formalize the to do
    list)[2][3] - this is really out of date. Many packages have been
    orphaned or are already in Fedora. Needs to be brought in line
    with the package database [5]. I'm not convinced that this page
    really needs to be so detailed. Wish lsit is probably the most
    important
  - register your interest in the contributor section of the audio
    spin wiki [3]
  - help test new packages - I will be listing all upcoming changes on
    this list and I encourage other package maintainers to do the same
    [3]
  - become a tester or packager of audio packages [4][5]
  - help test the new spins as we make them available.
  - join Chris in his documentation efforts [7]
  - volunteer desktop artwork
  - and most importantly, voice your opinion on how this project
    should be realized! Choice of media/desktop/applications
    /configuration etc. More proposals on this coming soon.

Packaging the software and building the media constitutes less than a 
quarter of the effort required here. What we need most is strong 
community support so please respond to this email if you are interested!

Lets do it

Brendan

[1] https://admin.fedoraproject.org/accounts/
[2] http://fedoraproject.org/wiki/Audio_Creation
[3] http://fedoraproject.org/wiki/AudioCreationSpinDevelopment
[4] http://fedoraproject.org/wiki/QA
[5] http://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[6] https://admin.fedoraproject.org/pkgdb/
[7] 
http://docs.fedoraproject.org/en-US/Fedora/15/html/Musicians_Guide/index....

[Manuel Ospina]

Hello Brendan,

I'd like to help. I went through the list of to do and I think I can help with
"packaging the Fedora Musician's guide". is it written using publican? I
would need some guidance though.

Regards,
Manuel

----- Original Message -----
From: "Brendan Jones" <brendan.jones.it(a)gmail.com&gt;
To: music(a)lists.fedoraproject.org
Sent: Monday, February 20, 2012 1:24:59 AM
Subject: [Fedora-music-list] Call to arms - Fedora Audio Spin

Hi all,

Traditionally Fedora has been known to walk the bleeding edge in free 
and open source software development but for some reason this has never 
been realised in the realms of pro-audio/music creation.

Fedora has never really attracted the support of the audio development 
community, and as a direct result has only flagging support from audio 
users, enthusiasts and professionals alike.

I think there are a number of reasons for this:
   1) Strict packaging and licensing guidelines,
   2) relatively short release support cycles
   3) the absence of an stock RT kernel
   4) the effort required to tailor an installation for audio use

Distributions like Debian/Ubuntu/Arch (and others like AVLinux) have 
garnered strong support because they in some way address all of these 
issues. Fedora however...

1) and 2) we can't change. In fact at the end of the day these 
strengthen the distribution by making the packages we ship more robust 
and closer to upstream. It also demands a certain amount of love to 
ensure that updates/ABI bumps/breakages are dealt with decisively and 
swiftly. It also means that audio developers are more unlikely to 
maintain their own packages in Fedora (we need more maintainers)

3) I can't see happening any time soon. The kernel team maintain so many 
out of tree patches already that I don't think they really have the time 
nor desire to maintain the realtime kernel as well. I don't see this as 
a problem - recent kernels have incorporated much of the the rt kernel 
patches of old and should satisfy most users. For those with more 
stringent requirements can rely on the CCRMA patched kernels

4) is where I think an audio spin comes into play. If we can 
collate/automate all of the steps involved in setting up Fedora for 
audio production we will attract both users and maintainers alike 
alleviating the problems caused by 1 and 2.

I'm proposing to formally revive the past Fedora Audio Spin / Music 
Creation efforts of a couple of years ago in time for an F18 Audio spin 
release. This means we have one whole release cycle to get all of the 
packages we require into stable so they can be available for Live 
composes for the F18 release cycle.

Apart from packaging efforts, the last few weeks for me has been an 
information gathering exercise. More on this soon, but briefly, the 
current to do list is:
  - pulling in all of the must have packages from CCRMA
  - determining the package list
  - packaging the Fedora Musician's guide
  - repackaging/patching rpmfusion packages for Fedora (qtractor and
    others if required)
  - developing sane RT priorities for the stock kernels (threadirqs)
  - consensus on distribution media, default desktop/supported desktops
  - default systemd enabled services
  - themes and artwork
  - resubmit the Spin proposal for F18

If you want to contribute, here's how:
  - become a contributor/get a FAS account [1] and join the
    music-creation group
  - help maintain the audio creation wiki's  (formalize the to do
    list)[2][3] - this is really out of date. Many packages have been
    orphaned or are already in Fedora. Needs to be brought in line
    with the package database [5]. I'm not convinced that this page
    really needs to be so detailed. Wish lsit is probably the most
    important
  - register your interest in the contributor section of the audio
    spin wiki [3]
  - help test new packages - I will be listing all upcoming changes on
    this list and I encourage other package maintainers to do the same
    [3]
  - become a tester or packager of audio packages [4][5]
  - help test the new spins as we make them available.
  - join Chris in his documentation efforts [7]
  - volunteer desktop artwork
  - and most importantly, voice your opinion on how this project
    should be realized! Choice of media/desktop/applications
    /configuration etc. More proposals on this coming soon.

Packaging the software and building the media constitutes less than a 
quarter of the effort required here. What we need most is strong 
community support so please respond to this email if you are interested!

Lets do it

Brendan

[1] https://admin.fedoraproject.org/accounts/
[2] http://fedoraproject.org/wiki/Audio_Creation
[3] http://fedoraproject.org/wiki/AudioCreationSpinDevelopment
[4] http://fedoraproject.org/wiki/QA
[5] http://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[6] https://admin.fedoraproject.org/pkgdb/
[7] 
http://docs.fedoraproject.org/en-US/Fedora/15/html/Musicians_Guide/index....
_______________________________________________
music mailing list
music(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/music

[Brendan Jones]

On 02/20/2012 12:48 AM, Manuel Ospina wrote:
>  Hello Brendan,
>
>  I'd like to help. I went through the list of to do and I think I can help with
> "packaging the Fedora Musician's guide". is it written using publican? I
> would need some guidance though.
>
>  Regards,
>  Manuel
>  
Thanks Manuel,

I was referring to putting the musicans guide in a package such that we 
can use it in the fedora multimiedia menu. I believe Chris is 
maintaining the Musician's guide and perhaps you can help him with the 
content, working out a possible format, desktop entry file etc.

regards,

Brendan

[Karsten Wade]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/19/2012 03:48 PM, Manuel Ospina wrote:
>  Hello Brendan,
>  
>  I'd like to help. I went through the list of to do and I think I
>  can help with "packaging the Fedora Musician's guide". is it
>  written using publican? I would need some guidance though. 
Manuel:

Yes, Chris worked with Fedora Docs to use Publican and adopted other
processes that should make it easier to package. However, it might be
packaged already? I thought that was how Publican deployed to the webUI:

https://docs.fedoraproject.org/en-US/Fedora/16/html/Musicians_Guide/index...

Regardless, I'm sure Chris will welcome your expert help. :)

- - Karsten

>  Regards, Manuel
>  
>  ----- Original Message ----- From: "Brendan Jones" 
>  <brendan.jones.it(a)gmail.com&gt; To: music(a)lists.fedoraproject.org
>  Sent: Monday, February 20, 2012 1:24:59 AM Subject:
>  [Fedora-music-list] Call to arms - Fedora Audio Spin
>  
>  Hi all,
>  
>  Traditionally Fedora has been known to walk the bleeding edge in
>  free and open source software development but for some reason this
>  has never been realised in the realms of pro-audio/music creation.
>  
>  Fedora has never really attracted the support of the audio 
>  development community, and as a direct result has only flagging 
>  support from audio users, enthusiasts and professionals alike.
>  
>  I think there are a number of reasons for this: 1) Strict
>  packaging and licensing guidelines, 2) relatively short release
>  support cycles 3) the absence of an stock RT kernel 4) the effort
>  required to tailor an installation for audio use
>  
>  Distributions like Debian/Ubuntu/Arch (and others like AVLinux)
>  have garnered strong support because they in some way address all
>  of these issues. Fedora however...
>  
>  1) and 2) we can't change. In fact at the end of the day these 
>  strengthen the distribution by making the packages we ship more 
>  robust and closer to upstream. It also demands a certain amount of 
>  love to ensure that updates/ABI bumps/breakages are dealt with 
>  decisively and swiftly. It also means that audio developers are
>  more unlikely to maintain their own packages in Fedora (we need
>  more maintainers)
>  
>  3) I can't see happening any time soon. The kernel team maintain
>  so many out of tree patches already that I don't think they really
>  have the time nor desire to maintain the realtime kernel as well. I
>  don't see this as a problem - recent kernels have incorporated much
>  of the the rt kernel patches of old and should satisfy most users.
>  For those with more stringent requirements can rely on the CCRMA
>  patched kernels
>  
>  4) is where I think an audio spin comes into play. If we can 
>  collate/automate all of the steps involved in setting up Fedora for
>   audio production we will attract both users and maintainers alike
>   alleviating the problems caused by 1 and 2.
>  
>  I'm proposing to formally revive the past Fedora Audio Spin / Music
>   Creation efforts of a couple of years ago in time for an F18
>  Audio spin release. This means we have one whole release cycle to
>  get all of the packages we require into stable so they can be
>  available for Live composes for the F18 release cycle.
>  
>  Apart from packaging efforts, the last few weeks for me has been an
>   information gathering exercise. More on this soon, but briefly,
>  the current to do list is: - pulling in all of the must have
>  packages from CCRMA - determining the package list - packaging the
>  Fedora Musician's guide - repackaging/patching rpmfusion packages
>  for Fedora (qtractor and others if required) - developing sane RT
>  priorities for the stock kernels (threadirqs) - consensus on
>  distribution media, default desktop/supported desktops - default
>  systemd enabled services - themes and artwork - resubmit the Spin
>  proposal for F18
>  
>  If you want to contribute, here's how: - become a contributor/get
>  a FAS account [1] and join the music-creation group - help maintain
>  the audio creation wiki's  (formalize the to do list)[2][3] - this
>  is really out of date. Many packages have been orphaned or are
>  already in Fedora. Needs to be brought in line with the package
>  database [5]. I'm not convinced that this page really needs to be
>  so detailed. Wish lsit is probably the most important - register
>  your interest in the contributor section of the audio spin wiki [3]
>  - help test new packages - I will be listing all upcoming changes
>  on this list and I encourage other package maintainers to do the
>  same [3] - become a tester or packager of audio packages [4][5] -
>  help test the new spins as we make them available. - join Chris in
>  his documentation efforts [7] - volunteer desktop artwork - and
>  most importantly, voice your opinion on how this project should be
>  realized! Choice of media/desktop/applications /configuration etc.
>  More proposals on this coming soon.
>  
>  Packaging the software and building the media constitutes less than
>  a quarter of the effort required here. What we need most is strong
>   community support so please respond to this email if you are 
>  interested!
>  
>  Lets do it
>  
>  Brendan
>  
>  [1] https://admin.fedoraproject.org/accounts/ [2] 
>  http://fedoraproject.org/wiki/Audio_Creation [3] 
>  http://fedoraproject.org/wiki/AudioCreationSpinDevelopment [4] 
>  http://fedoraproject.org/wiki/QA [5] 
>  http://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
>
>   
[6] https://admin.fedoraproject.org/pkgdb/
>  [7] 
>  http://docs.fedoraproject.org/en-US/Fedora/15/html/Musicians_Guide/index....
>
>
>   
_______________________________________________
>  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 

- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPQorw2ZIOBq0ODEERAlWeAJ4wNvx2cJiEL90M5BYPp5hz++golACbBhRB
> V6GPeVf3zDcVchnx8eCxPLc=
> =2e+O
> -----END PGP SIGNATURE-----

[Fernando Lopez-Lezcano]

On 02/19/2012 07:24 AM, Brendan Jones wrote:
>  Hi all,
>
>  Traditionally Fedora has been known to walk the bleeding edge in free
>  and open source software development but for some reason this has never
>  been realised in the realms of pro-audio/music creation.
>
>  Fedora has never really attracted the support of the audio development
>  community, and as a direct result has only flagging support from audio
>  users, enthusiasts and professionals alike.
>
>  I think there are a number of reasons for this:
>  1) Strict packaging and licensing guidelines,
>  2) relatively short release support cycles
>  3) the absence of an stock RT kernel
>  4) the effort required to tailor an installation for audio use 
If I may add:
5) in the past, a few decisions that broke audio related stuff in the 
name of progress. That drove users away (in the RedHat times and early 
Fedora releases, those distros plus Planet CCRMA were a very popular 
option that "just worked").

>  Distributions like Debian/Ubuntu/Arch (and others like AVLinux) have
>  garnered strong support because they in some way address all of these
>  issues. Fedora however...
>
>  1) and 2) we can't change. In fact at the end of the day these
>  strengthen the distribution by making the packages we ship more robust
>  and closer to upstream. It also demands a certain amount of love to
>  ensure that updates/ABI bumps/breakages are dealt with decisively and
>  swiftly. It also means that audio developers are more unlikely to
>  maintain their own packages in Fedora (we need more maintainers)
>
>  3) I can't see happening any time soon. The kernel team maintain so many
>  out of tree patches already that I don't think they really have the time
>  nor desire to maintain the realtime kernel as well. I don't see this as
>  a problem - recent kernels have incorporated much of the the rt kernel
>  patches of old and should satisfy most users. For those with more
>  stringent requirements can rely on the CCRMA patched kernels
>
>  4) is where I think an audio spin comes into play. If we can
>  collate/automate all of the steps involved in setting up Fedora for
>  audio production we will attract both users and maintainers alike
>  alleviating the problems caused by 1 and 2. 
5) we need a community that, in those cases, complains loudly so that 
changes that break things are reverted.

...

>  Apart from packaging efforts, the last few weeks for me has been an
>  information gathering exercise. More on this soon, but briefly, the
>  current to do list is:
>  - pulling in all of the must have packages from CCRMA
>  - determining the package list
>  - packaging the Fedora Musician's guide
>  - repackaging/patching rpmfusion packages for Fedora (qtractor and
>  others if required)
>  - developing sane RT priorities for the stock kernels (threadirqs)
>  - consensus on distribution media, default desktop/supported desktops
>  - default systemd enabled services
>  - themes and artwork
>  - resubmit the Spin proposal for F18 
I'll be happy to help in any way I can.

Minor points when compared to the above list, but here they go anyway.

I believe it would be important to have a way to do the spin so that 
users need to do zero configuration after installation to get a working 
and tuned system. Most of this is possible but there are a few things 
that would come in handy and that I have found no solutions for (yet!):

- a better way to optimize rt priorities of relevant processes (better 
than rtirq)[1]
- a better way to grant SCHED_FIFO/RR scheduling classes to normal users[2]
- a way to have qjackctl/jack point to the "right" card the first time 
jack is run[3]
- an easy way to divert PA streams to jack and back to /dev/null

The first two are not easy, I think.
More details below, for the curious.
-- Fernando


[1] rtirq is something that runs at boot time. When using threaded irqs 
it reorders the priority of the irq processes so that audio performance 
is optimized (ie: simplifying a bit, the irq of the soundcard has the 
highest scheduling priority, followed by jack and its clients, followed 
by everything else).

That does not work in a world in which soundcards come and go 
dynamically. The optimal solution would be to have a udev driven process 
that does the tuning dynamically when cards appear and disappear, and 
not only at boot time. I tried to do this a while back but there is a 
road block I was not able to overcome (something to do with finding the 
right irq that corresponds to a sound card).

[2] it would be best to not need to add users to a group so they are 
able to use rt scheduling. The Planet CCRMA solution was to let everyone 
use rt scheduling and has worked for me well for a very long time. It 
has been criticized recently for opening the workstation to potential 
denial of service attacks through rogue rt processes (something which 
is, I think, no longer even possible but, oh well).

It would be nice to be able to give rt scheduling access to the current 
logged in session. Granting that privilege would work for any real user 
of the system with no configuration and only for the time they are 
logged in. No more security problems, no more extra configuration steps. 
"Session" and "seat" experts would be needed (I tried, did not
succeed).

[3] pointing to the "right card" is impossible, of course. It depends on 
what the user wants. But the defaults that jack and qjackctl use 
currently pretty much make sure the wrong choice happens if the user 
does nothing. Jack uses the "default" soundcard which, ahem, points to 
Pulse Audio if I'm not mistaken. Enough said.

[Brendan Jones]

On 02/20/2012 02:00 AM, Fernando Lopez-Lezcano wrote:
>  On 02/19/2012 07:24 AM, Brendan Jones wrote: 
[snip]
>  5) we need a community that, in those cases, complains loudly so that
>  changes that break things are reverted.
>
>  ... 
Absolutely, I fear that the community here is really small. There is 
probably a bigger community surrounding CCRMA than there is for Fedora 
audio in general. We need to encourage people to speak up more, safety 
in numbers in numbers and all that.

> > Apart from packaging efforts, the last few weeks for me has been an
> > information gathering exercise. More on this soon, but briefly, the
> > current to do list is:
> > - pulling in all of the must have packages from CCRMA
> > - determining the package list
> > - packaging the Fedora Musician's guide
> > - repackaging/patching rpmfusion packages for Fedora (qtractor and
> > others if required)
> > - developing sane RT priorities for the stock kernels (threadirqs)
> > - consensus on distribution media, default desktop/supported desktops
> > - default systemd enabled services
> > - themes and artwork
> > - resubmit the Spin proposal for F18
>
>  I'll be happy to help in any way I can. 
We're counting on it - your experience is invaluable.

>  Minor points when compared to the above list, but here they go anyway.
>
>  I believe it would be important to have a way to do the spin so that
>  users need to do zero configuration after installation to get a working
>  and tuned system. Most of this is possible but there are a few things
>  that would come in handy and that I have found no solutions for (yet!):
>
>  - a better way to optimize rt priorities of relevant processes (better
>  than rtirq)[1]
>  - a better way to grant SCHED_FIFO/RR scheduling classes to normal users[2]
>  - a way to have qjackctl/jack point to the "right" card the first time
>  jack is run[3]
>  - an easy way to divert PA streams to jack and back to /dev/null
>
>  The first two are not easy, I think.
>  More details below, for the curious. 
If rtirq does not give us what we need I could throw some development 
time at it. I will have to look real close at it anyway - it currently 
exists only as an initd script, and one of the tasks I need to cover is 
to encapsulate it as a systemd service. If you were to start from 
scratch what would you do differently? Are you suggesting some kind of 
userspace daemon that allocates priorities based on a config file or 
some such?

I think one thing we definitely need is a simpler user interface to set 
system parameters relating to linux audio in general. In a perfect world 
this would also involve some kind of context switching and be able to 
handle pulseaudio if it is around and the like. Dynamically detecting 
hardware and the like is always going to be hard - I would really like 
to see what you've tried already

>  -- Fernando
>
>
>  [1] rtirq is something that runs at boot time. When using threaded irqs
>  it reorders the priority of the irq processes so that audio performance
>  is optimized (ie: simplifying a bit, the irq of the soundcard has the
>  highest scheduling priority, followed by jack and its clients, followed
>  by everything else).
>
>  That does not work in a world in which soundcards come and go
>  dynamically. The optimal solution would be to have a udev driven process
>  that does the tuning dynamically when cards appear and disappear, and
>  not only at boot time. I tried to do this a while back but there is a
>  road block I was not able to overcome (something to do with finding the
>  right irq that corresponds to a sound card).
>
>  [2] it would be best to not need to add users to a group so they are
>  able to use rt scheduling. The Planet CCRMA solution was to let everyone
>  use rt scheduling and has worked for me well for a very long time. It
>  has been criticized recently for opening the workstation to potential
>  denial of service attacks through rogue rt processes (something which
>  is, I think, no longer even possible but, oh well).
>
>  It would be nice to be able to give rt scheduling access to the current
>  logged in session. Granting that privilege would work for any real user
>  of the system with no configuration and only for the time they are
>  logged in. No more security problems, no more extra configuration steps.
>  "Session" and "seat" experts would be needed (I tried, did not
> succeed). 

>  [3] pointing to the "right card" is impossible, of course. It depends on
>  what the user wants. But the defaults that jack and qjackctl use
>  currently pretty much make sure the wrong choice happens if the user
>  does nothing. Jack uses the "default" soundcard which, ahem, points to
>  Pulse Audio if I'm not mistaken. Enough said.

[Karsten Wade]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/20/2012 09:26 AM, Brendan Jones wrote:
>  On 02/20/2012 02:00 AM, Fernando Lopez-Lezcano wrote:
> > On 02/19/2012 07:24 AM, Brendan Jones wrote:
>  [snip]
> > 
> > 5) we need a community that, in those cases, complains loudly so
> > that changes that break things are reverted.
> > 
> > ...
>  
>  Absolutely, I fear that the community here is really small. There
>  is probably a bigger community surrounding CCRMA than there is for
>  Fedora audio in general. We need to encourage people to speak up
>  more, safety in numbers in numbers and all that. 
While I'm hoping the rt kernel needs get resolved in upstream, one of
the things an active and vocal community can do is get packaging
changes made. A strong Audio SIG for Fedora means more influence on
the future direction of the distro overall.

- - Karsten
- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPQou92ZIOBq0ODEERAo+VAKCyMCbmzSwre5bJhkZ6juL6vKE+RwCgz1T9
> DyF/Qe4a6waah7mCWntmS5g=
> =CYto
> -----END PGP SIGNATURE-----

[Karsten Wade]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just a top-post to say, Brendan, thank you for making the call and
taking the lead in making this happen. As I get more musicians in the
house (my daughters keep getting older and more skilled), it's
important to me that I can have a top-notch FLOSS audio workstation.
I'll do whatever I can to help with the Audio Spin.

On 02/19/2012 07:24 AM, Brendan Jones wrote:
>  Hi all,
>  
>  Traditionally Fedora has been known to walk the bleeding edge in
>  free and open source software development but for some reason this
>  has never been realised in the realms of pro-audio/music creation.
>  
>  Fedora has never really attracted the support of the audio
>  development community, and as a direct result has only flagging
>  support from audio users, enthusiasts and professionals alike.
>  
>  I think there are a number of reasons for this: 1) Strict packaging
>  and licensing guidelines, 2) relatively short release support
>  cycles 3) the absence of an stock RT kernel 4) the effort required
>  to tailor an installation for audio use
>  
>  Distributions like Debian/Ubuntu/Arch (and others like AVLinux)
>  have garnered strong support because they in some way address all
>  of these issues. Fedora however...
>  
>  1) and 2) we can't change. In fact at the end of the day these 
>  strengthen the distribution by making the packages we ship more
>  robust and closer to upstream. It also demands a certain amount of
>  love to ensure that updates/ABI bumps/breakages are dealt with
>  decisively and swiftly. It also means that audio developers are
>  more unlikely to maintain their own packages in Fedora (we need
>  more maintainers)
>  
>  3) I can't see happening any time soon. The kernel team maintain so
>  many out of tree patches already that I don't think they really
>  have the time nor desire to maintain the realtime kernel as well. I
>  don't see this as a problem - recent kernels have incorporated much
>  of the the rt kernel patches of old and should satisfy most users.
>  For those with more stringent requirements can rely on the CCRMA
>  patched kernels
>  
>  4) is where I think an audio spin comes into play. If we can 
>  collate/automate all of the steps involved in setting up Fedora
>  for audio production we will attract both users and maintainers
>  alike alleviating the problems caused by 1 and 2.
>  
>  I'm proposing to formally revive the past Fedora Audio Spin /
>  Music Creation efforts of a couple of years ago in time for an F18
>  Audio spin release. This means we have one whole release cycle to
>  get all of the packages we require into stable so they can be
>  available for Live composes for the F18 release cycle.
>  
>  Apart from packaging efforts, the last few weeks for me has been
>  an information gathering exercise. More on this soon, but briefly,
>  the current to do list is: - pulling in all of the must have
>  packages from CCRMA - determining the package list - packaging the
>  Fedora Musician's guide - repackaging/patching rpmfusion packages
>  for Fedora (qtractor and others if required) - developing sane RT
>  priorities for the stock kernels (threadirqs) - consensus on
>  distribution media, default desktop/supported desktops - default
>  systemd enabled services - themes and artwork - resubmit the Spin
>  proposal for F18
>  
>  If you want to contribute, here's how: - become a contributor/get a
>  FAS account [1] and join the music-creation group - help maintain
>  the audio creation wiki's  (formalize the to do list)[2][3] - this
>  is really out of date. Many packages have been orphaned or are
>  already in Fedora. Needs to be brought in line with the package
>  database [5]. I'm not convinced that this page really needs to be
>  so detailed. Wish lsit is probably the most important - register
>  your interest in the contributor section of the audio spin wiki
>  [3] - help test new packages - I will be listing all upcoming
>  changes on this list and I encourage other package maintainers to
>  do the same [3] - become a tester or packager of audio packages
>  [4][5] - help test the new spins as we make them available. - join
>  Chris in his documentation efforts [7] - volunteer desktop artwork 
>  - and most importantly, voice your opinion on how this project 
>  should be realized! Choice of media/desktop/applications 
>  /configuration etc. More proposals on this coming soon.
>  
>  Packaging the software and building the media constitutes less than
>  a quarter of the effort required here. What we need most is strong 
>  community support so please respond to this email if you are
>  interested!
>  
>  Lets do it
>  
>  Brendan
>  
>  [1] https://admin.fedoraproject.org/accounts/ [2]
>  http://fedoraproject.org/wiki/Audio_Creation [3]
>  http://fedoraproject.org/wiki/AudioCreationSpinDevelopment [4]
>  http://fedoraproject.org/wiki/QA [5]
>  http://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
>   
[6] https://admin.fedoraproject.org/pkgdb/
>  [7] 
>  http://docs.fedoraproject.org/en-US/Fedora/15/html/Musicians_Guide/index....
>
>   _______________________________________________ music mailing
>  list music(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/music 

- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPQoxN2ZIOBq0ODEERAlGYAJ4zazFG3smCvCDaJwK5ygx693TezACeJsUh
> oQ+0cyYySvWPd4WzEAj1X5U=
> =Nom/
> -----END PGP SIGNATURE-----

[Brendan Jones]

On 02/20/2012 07:09 PM, Karsten 'quaid' Wade wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Just a top-post to say, Brendan, thank you for making the call and
>  taking the lead in making this happen. As I get more musicians in the
>  house (my daughters keep getting older and more skilled), it's
>  important to me that I can have a top-notch FLOSS audio workstation.
>  I'll do whatever I can to help with the Audio Spin.
>  
Thanks for the pledge and kind words! Lets make it happen.

[Brian Monroe]

I'm in, but is there a IRC channel you all hang out in? I join
#fedora-audio but there's not much going on there it seems, but maybe I'm
just on at the wrong times.

On Sun, Feb 19, 2012 at 7:24 AM, Brendan Jones
<brendan.jones.it(a)gmail.com&gt;wrote:

>  Hi all,
>
>  Traditionally Fedora has been known to walk the bleeding edge in free and
>  open source software development but for some reason this has never been
>  realised in the realms of pro-audio/music creation.
>
>  Fedora has never really attracted the support of the audio development
>  community, and as a direct result has only flagging support from audio
>  users, enthusiasts and professionals alike.
>
>  I think there are a number of reasons for this:
>   1) Strict packaging and licensing guidelines,
>   2) relatively short release support cycles
>   3) the absence of an stock RT kernel
>   4) the effort required to tailor an installation for audio use
>
>  Distributions like Debian/Ubuntu/Arch (and others like AVLinux) have
>  garnered strong support because they in some way address all of these
>  issues. Fedora however...
>
>  1) and 2) we can't change. In fact at the end of the day these strengthen
>  the distribution by making the packages we ship more robust and closer to
>  upstream. It also demands a certain amount of love to ensure that
>  updates/ABI bumps/breakages are dealt with decisively and swiftly. It also
>  means that audio developers are more unlikely to maintain their own
>  packages in Fedora (we need more maintainers)
>
>  3) I can't see happening any time soon. The kernel team maintain so many
>  out of tree patches already that I don't think they really have the time
>  nor desire to maintain the realtime kernel as well. I don't see this as a
>  problem - recent kernels have incorporated much of the the rt kernel
>  patches of old and should satisfy most users. For those with more stringent
>  requirements can rely on the CCRMA patched kernels
>
>  4) is where I think an audio spin comes into play. If we can
>  collate/automate all of the steps involved in setting up Fedora for audio
>  production we will attract both users and maintainers alike alleviating the
>  problems caused by 1 and 2.
>
>  I'm proposing to formally revive the past Fedora Audio Spin / Music
>  Creation efforts of a couple of years ago in time for an F18 Audio spin
>  release. This means we have one whole release cycle to get all of the
>  packages we require into stable so they can be available for Live composes
>  for the F18 release cycle.
>
>  Apart from packaging efforts, the last few weeks for me has been an
>  information gathering exercise. More on this soon, but briefly, the current
>  to do list is:
>   - pulling in all of the must have packages from CCRMA
>   - determining the package list
>   - packaging the Fedora Musician's guide
>   - repackaging/patching rpmfusion packages for Fedora (qtractor and
>    others if required)
>   - developing sane RT priorities for the stock kernels (threadirqs)
>   - consensus on distribution media, default desktop/supported desktops
>   - default systemd enabled services
>   - themes and artwork
>   - resubmit the Spin proposal for F18
>
>  If you want to contribute, here's how:
>   - become a contributor/get a FAS account [1] and join the
>    music-creation group
>   - help maintain the audio creation wiki's  (formalize the to do
>    list)[2][3] - this is really out of date. Many packages have been
>    orphaned or are already in Fedora. Needs to be brought in line
>    with the package database [5]. I'm not convinced that this page
>    really needs to be so detailed. Wish lsit is probably the most
>    important
>   - register your interest in the contributor section of the audio
>    spin wiki [3]
>   - help test new packages - I will be listing all upcoming changes on
>    this list and I encourage other package maintainers to do the same
>    [3]
>   - become a tester or packager of audio packages [4][5]
>   - help test the new spins as we make them available.
>   - join Chris in his documentation efforts [7]
>   - volunteer desktop artwork
>   - and most importantly, voice your opinion on how this project
>    should be realized! Choice of media/desktop/applications
>    /configuration etc. More proposals on this coming soon.
>
>  Packaging the software and building the media constitutes less than a
>  quarter of the effort required here. What we need most is strong community
>  support so please respond to this email if you are interested!
>
>  Lets do it
>
>  Brendan
>
>  [1]
> https://admin.fedoraproject.**org/accounts/<https://admin.fedoraprojec...
>  [2]
> http://fedoraproject.org/wiki/**Audio_Creation<http://fedoraproject.or...
>  [3]
> http://fedoraproject.org/wiki/**AudioCreationSpinDevelopment<http://fe...
>  [4] http://fedoraproject.org/wiki/**QA <http://fedoraproject.org/wiki/QA>
>  [5] http://fedoraproject.org/wiki/**Join_the_package_collection_**
>  maintainers<http://fedoraproject.org/wiki/Join_the_package_collection_...
>  [6]
> https://admin.fedoraproject.**org/pkgdb/<https://admin.fedoraproject.o...
>  [7] http://docs.fedoraproject.org/**en-US/Fedora/15/html/**
>
> Musicians_Guide/index.html<http://docs.fedoraproject.org/en-US/Fedora/...
>  ______________________________**_________________
>  music mailing list
>  music(a)lists.fedoraproject.org
>
> https://admin.fedoraproject.**org/mailman/listinfo/music<https://admin...

[Brendan Jones]

On 02/22/2012 04:45 AM, Brian Monroe wrote:
>  I'm in, but is there a IRC channel you all hang out in? I join
>  #fedora-audio but there's not much going on there it seems, but maybe
>  I'm just on at the wrong times. 
I'll try to lurk in #fedora-audio - but it is pretty quiet mostly.