A little talk about technical details, which one should be aware when using openArtist, as well as Linux in general.
One of the biggest drawbacks of Linux is the non-unified method of installing graphics drivers. There are openSource drivers and proprietary ones. The openSource one are delivered with Linux, the others not. Also the quality of the drivers is a big issue. As the openSource drivers or Nvidia/AMD still mostly are not really competitive with the proprietary, closedSource ones, the use of the Latter ones is mostly mandatory.
Although the situation gets better, the openSource ones lag behind in performance. In terms of stability, AMD/Ati does not provide with their closedSource driver either, thus the User of very demanding graphics Apps is forced to use Nvidia cards only. This is the recommendation for now, as it provides the best experience performance-wise (some apps demand to have an nvidia card, the (for now) nvidia-only CUDA framework for GPU computing is way beyond openCL etc. etc.), stability-wise. The AMD/ati blob can make problems, but it can also work out ok.
What both proprietary drivers have in common: They provide much faster support for new Graphics cards. So if you have to use newest top-grade equipment, you are bound to use these.
If you are not using high demanding Graphics apps, GPU computing, games, or the newest graphics cards, the openSource drivers should suffice. Sadly, only AMD/ATI is supporting the floss (free libre openSource software) driver development in providing schematics and design specs of their GPUs, as well as now switching to floss drivers base. Nvidia is doing not so much for it, so the Nouveau driver is a piece of complete reverse engineering work, much harder to code.
Also the company refuses to support their Optimus technology in Linux, which is built in recent laptops and allows for less power consumption by switching between two graphics chips (one for 2d, one for 3d). For people with such hardware, a solution exists provided by the bumblebee project. It starts an extra X window manager session, for the program which has to be explicitly told to use it. OpenArtist features Bumblebee-config-Gui to manageNvidia Optimus.
For openArtist, there are three methods to install proprietary ATI/AMD and NVIDIA drivers. The openSource drivers are already included in the operating system.
1) use (Contol Center > Hardware > Additional Drivers). This is the standard procedure. It detects your hardware and suggests the right package to install. You do not get the newest drivers here, Bleeding edge cards are not supported.
2) use Sgfxi. (Contol Center > Hardware > Sgfxi). This will open Sgfxi on command-line. The default driver is the driver that is installed if no arguments are used to override it. Unless your card is too old, and requires a legacy driver, in which case the script will it determine for you. When you run the script, it will stop, and tell you what driver it is going to install. You can accept that, or exit and redo it with an override option if you want something different.
Sgfxi currently supports AMD and Nvidia drivers. It also supports switching from or to openSource drivers like ati, intel, nouveau, nv. Not all features or options work for every distro, and AMD support tends to vary Distro to Distro and time to time. At any case, you will need the headers (package named linux-headers-… of the actual kernel you use installed, better all headers of all kernels you use, as there is a utility to install the drivers into all kernels at once. Openartist’s default kernel’s headers are installed by default.
3) Do it by hand. Normally not needed because of sgfxi is also up-to-date (even with beta versions) and much easier to use. Kernel headers are needed as well here.
Nvidia install : Download the driver ( currently .run self-extracting archive available at http://www.nvidia.com/object/unix.html ), follow install notes (currently http://us.download.nvidia.com/XFree86/Linux-x86_64/352.55/README/index.html ). Some selfmade instructions and more info about installing by hand can be found at /opt/scripts/
AMD Catalyst install: Download the driver ( currently Ubuntu packages available at http://support.amd.com/en-us/download/desktop?os=Ubuntu+x86+64 ), follow install notes (currently http://www2.ati.com/relnotes/amd-catalyst-graphics-driver-installer-notes-for-linux-operating-systems.pdf)
Generally one of these methods almost certainly works for you. But keep in mind that not all of these drivers work with all kernels. Be prepared that you cannot boot into the GUI, if you have bad luck (hint: boot with “nomodeset xforcevesa” kernel parameters set to get a basic resolution GUI up). More information about the graphics stack and how to cope with such situations later.
Another drawback(or a feature, depends on sight of view) is with Audio in Linux. There is more than one way for audio on Linux. In openArtist, there are Jack ( Jack2 to be precise) and Alsa, as well as Pulseaudio.
How things work
Alsa is the bare metal hardware communication sound library, which all other SoundServers depend on. While Alsa is the one which directly talks with the hardware, it’ s not doing everything well. You sometimes cannot always play two sound sources at the same time with it. Sounds crazy, but happens. So don’t be scared if you are using only Alsa because of it’s low overhead and resource friendliness, and some program does not produce sounds. Its very likely that the hardware device (the soundcard) is blocked by another program. That’s why Pulseaudio was made in first place, and apart from many other features like sending sound over network, it’s exactly helping out in that situation. You can lookup which program uses the sounddevice with a script (Audio > Control > Check which program uses the sounddevice)
Jack for inter-application audiorouting
But PulseAudio is not made for routing audio between applications, but only directly to the output. That’s where Jack (the jack audio control kit) comes into play, a sound server for professional audio use. Jack has audio and midi I/O routing capabilities. Basically, you can build stream chains between programs, routing the signals as you like, keeping low latency. But not all programs use jack. When Jack is running, programs that only use Alsa, PulseAudio normally cannot play sounds… but fear not, openartist solves all issues by intelligently routing between the three. Normally you should get sound in almost any circumstance. It’s the goal of openArtist to make technology as configurable as possible but also reducing complexity in the first place, so e.g. Jack is not started by default, as some audio-focused Distros do, as that would hinder other use-cases of openArtist. So a minimum understanding of underlying technology is inevitable.
Soundcontrols and Automation
OpenArtist wants you in control, and so it always shows you that a SoundServer is running.
OpenArtist by default runs PulseAudio SoundServer alongside Alsa; This is indicated via the PulseAudio System tray application. You can control and quit PulseAudio from there. For applications that use JACK, openArtist launches audio applications the way they want to be launched:
– For every program that needs Jack to run, Jack will start with that program. Note that this is not the case in other distributions.
You can also see that in the system tray, there is the cadence OR qjackctl icon popping up when you start an application in the need of Jack. So there are two different programs to control jack form which you can use from. The first is default and uses the JackDBUS interface of jack2, the latter is configured to use the non-DBUS jackd interface, without sacrificing the functionality of plugging Alsa and PulseAudio into Jack.
– todo: provide a list of programs which MUST, CAN, and CANNOT use jack, and which audio device is selected in the program settings by default.
Software pools for ruling them all
Repositories are software pools. You get all the Ubuntu packages via Repositories, there is a repository specifically for openArtist.
And there a many more, as many people provide fresh versions of software or extra functionality and tools via those. The ones hosted at launchpad.net are called PPAs, which is important as openArtist uses them heavily. the file /etc/apt/sources.list contains all Repostiories openArtist uses. Please read the warnings and comments at the beginning or that file, as they are vital. Currently, this file has over 2000 lines length, so there are hundreds of PPAs and Repositories used.
Ubuntus greatest feature are these Repositories/ppa’s as they keep the software up-to date while having a reasonably stable base system, in opposite to many other rolling release distributions. That’s the cause why openArtist is based on ubuntu.
The sheer amount of Repositories is hard to maintain, some update mechanism to fix some of these is already implemented in openArtist, so if you are patient, the errors you get at updating your packages should go away. But it’s a good idea to know how to fix issues in here, as it is not complicated at all.
– some Repos will start claiming that there is no pubkey: ControlCenter -> System -> Add/refress missing apt GPG keys
– some Repos will be disfunct because the server is offline, it gets deleted etc. : ControlCenter -> edit /etc/apt/sources.list and comment (with a # the line with the disfunct Repos.
If you get other errors google it or ask at the forum.
OpenArtist is only available as 64bit Distribution. Sorry for users of older hardware. I recommend using Antix. Or use the /etc/apt/sources.list of openArtist on a fresh (X/lub)ubuntu install. Mabye I will provide a minimal ubuntu-based version myself if time permits.
The Tuning/Kernel Category of Control Center has many things to try out for optimizing system performance. OpenArtist features different kernels, for example Liquourix kernel, or a Realtime kernel, all of which will be described in detail her in time.
The Realtime Kernel
You can install a realtime kernel. With Ingo Molnar’s Realtime Preemption patch and Thomas Gleixner’s generic clock event layer with high resolution support, the kernel gains hard realtime capabilities.
So whats this all about?
To put it simple, imagine a robot arm in a car building facility. If the is no guarantee that it will be ready with a movement at a certain time, it will e.g make holes at the wrong place, so this is where hard realtime capabilities are needed. Or at sattelite communication between basestation and sattelite, there also must not be any delays.
Why should I care?
You’d want a real-time kernel when you’re using your machine for audio production. It allows you to use real-time effects and allows for lower latency settings (ie. with a Firewire soundcard a latency below 3ms is possible with a real-time kernel).
For Multimedia/3D work, including simple tasks such as playing streams of data from services like Spotify, YouTube etc, you can benefit greatly use a realtime kernel optimized for fast redraws in memory allocated to applications, that demands functions such as streaming multimedia with pre-compiled static kernel libraries. If you work with 3D apps, and compositing in applications like Nuke, try a side by side comparison after switching to a RT kernel…
It gives better performance even in simple tasks such as music playback, not to mention communication on the bus between soundcards.
While RT kernels provide benefits for audio and video, even at render applications, they will drain your laptops battery power, because all power-saving functions present in the default kernel are missing. But you can switch between kernels at boottime, anyways.
(Maybe too technical, but for the curious…)
The Realtime Preemption patch converts Linux into a fully preemptible kernel. The magic is done with:
- Making in-kernel locking-primitives preemptible. (using spinlocks, a lock where the thread (=execution path of a program) simply waits in a loop (spins) repeatedly checking until the lock becomes available)
- Critical sections in the Kernel are now preemptible. The creation of non-preemptible sections (in kernel) is still possible.
- Implementing priority inheritance for in-kernel spinlocks and semaphores (semaphores can be thought of as really generic advisory locking mechanisms. You can use them to control access to files, shared memory, and, well, just about anything you want. The basic functionality of a semaphore is that you can either set it, check it, or wait until it clears then set it).
- Converting interrupt handlers (points where Linux talks with the hardware, e.g the mainboard, CPU..) into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented like a common userspace process (In Linux, the RAM is always divided into two areas: userspace, where the processes of the programs can run, and kernelspace, where the kernel and everything close to the hardware (e.g X-server) runs. However it is also possible to register an interrupt in kernel context.
- Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to userspace POSIX timers with high resolution.
grub will always boot into the last selected startup option. So when you start with e.g. a realtime kernel once, it will start into it automatically the next time when you (re)boot your machine. Same If you have windows/macos on your machine, it will boot the last entry that was chosen at prior boot.
Also, the grub selection menu is resembling the old behavior of having many entries in the same list and no sublists where kernels are hidden in.