[testcases] Creation of Ubuntu Studio specific testcase

[Len Ovens]

On Thu, September 20, 2012 2:00 am, Ralf Mardorf wrote:
> IMO it's also important to check whether rtirq fits to the kernel
> version. To run jack MIDI latency test. Take care about a working,
> complete Jack.
> Rtirq very often is outdated, working for the default config, but unable
> to handle soft IRQs, while hardware does share IRQs.
> It's not an issue for me, I replace bad packages by self-build packages,
> but it's not good, if the installed Ubuntu Studio ships with such
> issues, because a lot of users won't compile basic software.

I (and others) are currently rethinking if rtirq should run by default.
The way it comes out of the box is only really good for internal audio
IFs. However, I have not seen any HW that has the internal audio IF
sharing an IRQ. It normally has the highest (HW wise) priority irq already
and so rtirq is not needed for that. It is needed for most uses where the
user is using "added" (PCI(e), USB, Firewire) audio IFs, but rtirq has to
be set up for each use case differently or it will make things worse not
better.

It does matter which PCI(e) slot is used, it does matter which USB plug is
used and the user needs to find out which slot/plug is the clear one when
they are installing the IF. This varies from HW to HW. Why the HW
manufactures create 100 IRQs (most newer MB have at least 48) and still
cram 3 or 4 things on IRQ16 (like does anyone still use DOS?) I don't
know. There seems to be some standard that one of the PCI slots must be
irq 16, one of the USB ports must be irq 16, etc.

> OT: Perhaps others followed Len's thread at LAU too. I accept that some
> people like to use session managers, OTOH Jack compiled for dbus usage
> is a PITA for many users. While for me it's only annoying, but I'm able
> to handle it, for blind users it could become a serious issue. Since
> Jack anyway is split into several grotesque packages, it might be a good
> idea to have useful packages for Jack with and without dbus. Blind users
> might install Ubuntu Studio and then remove X. Of course, the blind
> users on LAU use other distros, but it couldn't harm to think about some
> new issues.

This is a hard one. Ubuntu in general is an out of the box everything
working distro. That is, everything installed by default works. Studio
comes with the ladi session management installed and with the pulse-jack
bridging installed. Both of these things need dbus to work. Even from a
command line POV, having dbus active is helpful. There are a number of
jack tools for command line that are nice to use that use dbus. So for
Ubuntu to pursue a no dbus alternate route does not seem useful. I think
it would break upstart as well, because dbus is used system side.

Unfortunately, there only seem to be two kinds of linux setups these days,
GUI and server. GUI is X centered and server is service or system centered
and the current setup of dbus handles both of these very well. IMO there
needs to be a third kind of setup for terminal based desktop use. However,
it would take interested people to develop and maintain it. While I do
have interest, I don't have the time and skill to do that on my own. I may
document what I have done though to give others a starting point for their
own projects. My solution is great for single user use, but would be
problematical for more than about two users who needed dbus running in a
terminal environment as it starts dbus instances for any users who might
need it at boot time. A more reasonable solution where more users might
need the service would be something that starts at first login for a user
and then passes the info for second or third logins from the same user at
the same time... then shuts it down when the tty for that user is closing.
That kind of mess is beyond me :P

It might be interesting to have a Blind use distro around That gathers the
tools that are friendly to those without sight.

Len


-- 
Len Ovens
www.OvenWerks.net