[Fedora-music-list] Call to arms - Fedora Audio Spin

[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.