Audio is tricky. This FAQ remains a work in progress.
Changing a kernel and expecting everything that you run to work identically without any changes is unrealistic. So here are some frequently asked questions that should avoid some of the problems people have with audio.
By far the most common reason for suddenly terrible audio playback after upgrading a kernel is that your hard drive no longer is using DMA (direct memory access). Changing from one kernel version to the next, the name of the hardware support and drivers for your hardware in the kernel configuration may change (especially a change in major version like 2.4.x to 2.6.x). Ensure in your configuration that you have the appropriate support for your hardware, and note that some options may worsen the performance of your driver if also compiled in.
eg config options for an ATA drive on an ICH controller (only relevant on and off are shown):
<*> ATA/ATAPI/MFM/RLL support <*> Include IDE/ATA-2 DISK support [*] Use multi-mode by default [ ] IDE Taskfile Access < > generic/default IDE chipset support [*] PCI IDE chipset support [*] Generic PCI bus-master DMA support [*] Use PCI DMA by default when available <*> Intel PIIXn chipsets support
Note that IDE taskfile access is off; this can interfere and almost certainly you will not be using it. Note also generic IDE chipset support is off; this is appropriate if there is a driver for your hardware (which is pretty much all hardware these days).
If you have compiled all that into your kernel you should then ensure that it is actually working. 'dmesg' should show something like this:
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Note that this is only telling you that dma is enabled at bootup. Certain hardware faults and conflicts can make dma disabled so check it manually with hdparm:
hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 0 (32-bit) unmaskirq = 0 (on) using_dma = 1 (on)
Note that the one that makes the most difference is using_dma. If you have using_dma at 1 then the other values are _irrelevant_ and ignored.
You can check the output of
hdparm -I /dev/hda
It should look like this:
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
If you are getting the highest udma supported by your bios and motherboard then all is fine. If you are getting an mdma mode then you need to go back to checking you have your appropriate driver installed, and then seek further help (eg google!).
There are two important things to note about hdparm:
- "hdparm -i" does _not_ tell you what mode the hardware is currently using.
- hdparm can _not_ fix DMA problems if you have not enabled the correct chipset into your kernel. You will get a HDIO_SET_DMA failed error if you don't have the generic IDE driver, or it will set an mdma mode if you have the generic IDE driver. Neither is desirable.
Not all filesystems as set up by distributions are ideal for good audio performance under heavy loads. Each filesystem almost certainly has options which when enabled will decrease their latency. Global to any filesytem is the noatime option which can have massive improvements to latency and can be enabled by default by editing your /etc/fstab file.
E.g. a line:
/dev/hda7 /home ext3 defaults 1 2
can be changed to
/dev/hda7 /home ext3 defaults,noatime 1 2
This will enable it on next reboot, but you can change it on the fly once you have changed the entry with
mount -o remount /home
The disadvantage of noatime is the last access time is not modified on files. For most things this will not matter, but there are some build scripts when compiling your own source that may depend on that particular time so it is worth being aware of.
Details specific to filesystems can be quite extensive, but specifically, for the moment, avoid reiser4 - it is a fast throughput filesystem but can do this at great latency expense causing bad interactivity and/or audio. Reiser3 is a good all round choice that requires little tweaking but has less support and continued development compared to ext3. A tweaked ext3 filesystem is probably the best choice. To tweak ext3 (apart from noatime), use tune2fs and this option:
tune2fs -O dir_index /dev/hda7
dir_index uses hashed b-trees to speed up lookups in large directories, but only works with 2.6 kernels.
A journalling option that is extremely helpful is journal_data_writeback
tune2fs -o journal_data_writeback /dev/hda7
See what this is from 'man tune2fs':
When the filesystem is mounted with journalling enabled, data may be written into the main filesys- tem after its metadata has been commutted to the journal. This may increase throughput, however, it may allow old data to appear in files after a crash and journal recovery.
Despite this warning it is important to realise that this is actually the mode of journalling used by the reiser filesystem, and ext3 is normally more paranoid than this.
You can make this a permanent mount option by adding it to your fstab as well
/dev/hda7 /home ext3 defaults,noatime,data=writeback 1 2
This journalling option can be used with any journalled file system as far as I can tell.
A common trick to improve desktop performance done by about half the linux distributions for kernels prior to 2.6 was to reniceX to a negative number. The tuning in the 2.6 kernel scheduler and the staircase scheduler are specifically designed to not need negative nice levels for any normal userspace tasks, but for critical things like root shells to use in case of emergency, or video and audio capture. If X is reniced to a negative number it is very easy and in fact likely that audio playback will suffer under heavy use of the desktop such as moving windows, scrolling text pages etc. To see what nice level X is currently running at, start the 'top' utility and look in the column NI. 0 is ideal, and any negative number is bad. You can fix the situation instantly (as root) with 'renice 0 $(pidof X)'. To fix this from happening on every startup, it depends on which distribution and login manager (if any) you use to correct it. For example, kdm starts X with the command specified in /usr/share/config/kdm/Xservers. Check it and if it looks like this:
:0 local@tty1 nice -n -10 /usr/X11R6/bin/X -deferglyphs 16 -dpi 92
change it to
:0 local@tty1 /usr/X11R6/bin/X -deferglyphs 16 -dpi 92
There may be a number of entries to allow multiple X sessions, and you'll need to change all of them if you ever use extra sessions.
Also, look in the /etc/X11/Xwrapper.config file and see if you have a nice_value entry, then change it to zero:
There are many 3d games that use the openAL drivers for audio playback, most of them are the unreal tournament based engines. By default, openAL uses the older OSS drivers for sound which 2.6+ kernels only do using an OSS-compatible mode. This make sound perform rather badly and notably causes choppy audio on the staircase cpu scheduler. To make the openAL driver use the ALSA audio drivers, create a file called .openalrc in your home directory if you don't already have one and make it look like this:
(define speaker-num 2) (define devices '(alsa)) (define alsa-out-device default)
If your sound card is supported, you should also consider the hardware accelerated openAL drivers which decrease cpu usage.
The enlightened sound daemon often uses the OSS drivers or a compatibility layer and so it can consume enormous amounts of cpu and lead to bad audio playback. The ARTS sound daemon in kde seems to work very nicely in concert with ALSA drivers so it does not seem prone to the same problems. As 2.6+ use the alsa drivers by default, you no longer need a sound daemon to share the audio card as alsa has software mixing called dmix. You'll need to google to find out how to do this. Newer kernels even support software mixing without any special settings if you use the ALSA driver instead of OSS compatibility.
Cedega (WineX) gamesEdit
Getting multithreaded sound playback and gaming working nicely and well is actually quite tricky. The WineX games have effectively many more layers between the game and the sound card and can easily lead to odd priority inversion problems since "locking" between the threads is very fragile. The trick to making these work is to force them to be all the same priority and this creates some artificial locking between the threads. It appears the most common problem is the wineserver thread doing the harm.
If you use the Point2Play gui with cedega they can tick the Decrease WineServer Priority option in the configure section which changes it to nice +10. If your application is already running, 'nice'ing the wineserver thread to +19 can make a world of difference.
Getting wine to use the alsa sound card is also worth doing.
in config file
[WinMM] "Drivers" = "wineoss.drv"
can be changed to
[WinMM] "Drivers" = "winealsa.drv"
on both wine/cedega
[WinMM] "Drivers" = "winejack.drv"
on wine (probably not cedega)
consider also enabling mmap support, which helps on some hardware.
Mplayer framerate badEdit
Some earlier versions of mplayer (up to 1.0pre4 I think) used a non blocking call to the X server leading to mplayer using a lot of cpu yet not letting the X server actually do it's drawing. If you nice mplayer just +1 and the problem goes away then you are experiencing that problem. Upgrading to a newer version or using an alternative player should improve things dramatically.
Jackd has lots of XrunsEdit
Jackd is designed to run with real time priority. You can currently only do that as the root user because running an application real time will by design cause huge periods of starvation and possibly even hang the machine if the application uses 100% cpu or gets carried away and hangs. An alternative is to run it as SCHED_ISO if you are using the -ck patchset and don't have superuser privileges. SCHED_ISO is designed to minimise latency yet maintain fairness of how much cpu an unprivileged user can have. Launch jackd with the schedtools command:
schedtool -I -e jackd_commands_here
As of 2.6.13+ SCHED_ISO is more real time even than -nice values.
If you try and launch any application as real-time with -ck, and don't have superuser privileges, -ck will automatically drop you to SCHED_ISO. What will be possible in the future for full real-time access is the use of real-time rlmits, provided your distribution has the latest password authentication module to support it and a kernel >=2.6.13. However, SCHED_ISO does not ever allow an unprivileged task to hang the machine with sustained starvation.
If you have choppy audio with your games, any of them can benefit from being niced to +19.