1 What hardware artsd doesn't work well with?
2 Why are there hardware specific problems and how do I see them?
3 What is wrong in the driver if I get the cpu overload problem?
4 What is wrong in the driver if I get the assertion?

1 What hardware artsd doesn't work well with?

It seems that there are a few linux drivers which don't work well with aRts in some kernel versions. Please read this list before reporting a bug. If you find that some information in this list is incomplete, please don't hesitate to let us know.

Linux Driver / SoundcardFails underWorks underRemarks
i810 driver (Intel 810 + AC97 Audio)2.4.92.2.20, commercial oss driver, alsa-0.5.12a with OSS emulationdriver causes cpu overload (see below)
maestro 3/4 chipset2.4.9?driver sometimes causes cpu overload (see below)
aureal8820, aureal8830 drivers from sourceforge2.4.17?driver triggers assertion / causes cpu overload (see below)
OSS Commercial 3.9.4g with Aureal Vortex??system lockup
ymfpci2.4.0, 2.4.122.4.17driver triggers assertion (see below)

2 Why are there hardware specific problems and how do I see them?

The usual problem is that the driver doesn't supply aRts with enough or accurate enough information on when to write sound data. Most OSS drivers do supply correct information, but not all.

You might notice that some other applications (like xmms) may not need this data, and thus work correctly even with your hardware. However, aRts needs this data, so artsd might fail. This is still a bug in the driver, and not in aRts.

There are two kinds of behaviour that artsd exposes on being run on an incorrect driver. Either, it continously tries to feed new data, but never really succeeds, which eventually leads to consuming all CPU power and reporting cpu overload and exiting. The other problem is that artsd might get supplied with wrong information how much to write. Artsd will then stop with an assertion like:

artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
Assertion `len == can_write' failed.
Aborted

3 What is wrong in the driver if I get the cpu overload problem?

Usually, artsd uses select() to find out when to write new data. Then, it uses an ioctl(...GETOSPACE...) to find out how much data to write. Finally, it writes this data.

A problem occurs if artsd is woken up either always or if there are minimal amounts of data to write. The OSS documentation specifies that select() only wakes up a process if there is at least one fragment to write. However, if artsd is woken up if there isn't data to write, or very little, for instance one sample, then it will keep writing little pieces of audio data, which can be very costly, and eventually overload the cpu.

To fix this, the driver should wake up artsd only if there is a full fragment to write.

4 What is wrong in the driver if I get the assertion?

Usually, artsd uses select() to find out when to write new data. Then, it uses an ioctl(...GETOSPACE...) to find out how much data to write. Finally, it writes this data.

If artsd can't write as much data as indicated by the ioctl, it will fail in the assertion. To fix this, the driver should supply the correct amount of free space.

KDE Logo