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

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