[PlanetCCRMA] Problem with qjackctl in Fedora 14

[Fernando Lopez-Lezcano]

On 12/30/2010 11:11 AM, Fernando Lopez-Lezcano wrote:
> On 12/30/2010 10:47 AM, Orcan Ogetbil wrote:
>> On Thu, Dec 30, 2010 at 1:17 PM, Fernando Lopez-Lezcano wrote:
>>> I have to see what I can do to change things in the rt patched kernel and
>>> rtirq so that it is possible to use it with the reduced (arbitrary) priority
>>> of 20.
>>>
>>
>> Let me know what comes out. I might get yelled at if I update the F-14
>> jack package just with this change, because of these new updates
>> policies.
>
> It is a pain, right? I find this all a bit ironic as Fedora has never
> been too concerned about stability or major changes that break things.
>
>> Is there any other fixes, patches that I can throw in and
>> that would be nice to have?
>
> Let me think a bit about this. We will eventually need something that
> allows us to change the directory where jack stores the fifos and
> sockets but that is probably in the fc15 time frame (and it may be
> included in newer versions of jack).
>
> I'm trying to see how to do the rt priorities through udev, does not
> seem too easy (I have to somehow link the sound device to the irq pid so
> that I can use chrt to reorder priorities...)

I made some progress today but I seem to have hit a wall...

I can get udev to trigger on a soundcard insertion through a rule like 
this one (all in one line):

----
SUBSYSTEM=="sound", ACTION=="change", ATTRS{irq}=="[0-9]*", 
DRIVERS=="*", RUN+="/home/nando/work/sound_udev/bin/sound_new $attr{irq} 
$driver"
----

Where "sound_new" is a shell script that prints the stuff out to a file. 
So, I manage to pass the irq of the soundcard and the "driver" to the 
script (along with other stuff that is in the environment) - all stuff 
that udev sees.

The problem I'm having is how to map from those parameters to the pid of 
the system thread that is handling the soundcard's irq. For example this 
is the driver that handles the Audigy2 I'm plugging in (which uses irq 19):

$ udevadm info --query=property 
--path=/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/0000:06:00.0/sound/card2 
--attribute-walk|grep DRIVER
     DRIVERS=="EMU10K1_Audigy"

(I'm removing some non-relevant stuff from the output of udevadm)

But this is what I find under irq 19:

$ ps -e -o "pid comm"|grep irq/19
   136 irq/19-ehci_hcd
  1023 irq/19-ohci1394
  4970 irq/19-EMU10K1

Of course I would only want to chrt pid 4970, right?
This ones seems to be simple (use the first part of DRIVERS).

But then I look at the onboard soundcard, driver for that is:

$ udevadm info --query=property 
--path=/devices/pci0000:00/0000:00:1b.0/sound/card0 
--attribute-walk|grep DRIVERS
     DRIVERS=="HDA Intel"

and the interrupt (31 this time) looks like:

$ ps -e -o "pid comm"|grep irq/31
  1092 irq/31-hda_inte

Which does not really match what I see in DRIVERS (of course you can 
make it match somehow but I'm trying to avoid hackery).

So far I don't see where the irq process naming comes from.

Anyway out there knows? Any gurus reading? (I'd rather not have to 
browse through the kernel code... :-)

-- Fernando