Posts Tagged ‘bsd systems’

How to solve ALSA sound problems with old Linux programs and games depending on (OSS)’s /dev/dsp / fix wine games and pulseaudio problems – My few thoughts on OSS and ALSA

Wednesday, January 11th, 2012


ALSA OSS Pulseaudio ESD Some fixes workaround to gnu linux audio messI remember GNU / Linux, 11 years from now, times when ALSA was not standardly shipped with Linux.
Back then ALSA still lacked good support for many SoundCards and was still a "baby project".
In that time what we used to have sound on Linux was OSSOpen Sound System. OSS emerged right after the first ever Linux sound system VoxWare (formerly known as the Linux Sound Driver).

Back in those days OSS was used for multimedia support on both GNU / Linux and BSD based free OSes. It was few years later when I heard and used ALSA for a fist time and it wasn't really a love from first sigth.

One can easily find out by the name ALSA it is a system especially built for the Linux kernel and that's one of the reasosn why *BSD systems has their custom separate sound system.
There is plenty of reasons why OSS was substituted with ALSA. Main reason was its commercial like license, OSS wasn't completely "open source" GPLed (free software), there was resctions on use of OSS for commercial goals.

With its emerge ALSA started to push away OSS slowly. Somewhere in 2003, alsa has officially entered the Linux kernel source and until 2005 it was the default standard for all GNU / Linux operating systems.

As of time of writting ALSA has become the only sound system to have support for multiple sound card devices for Linux.
My experiences with ALSA, however ain't so nice if I take a look in my past experiences.
Since the very beginning of using ALSA, I had plenty of troubles with configuring properly my sound card not to mention, even after configuring it the MIDI support was not there.
Besides all the troubles main problems were stemming from the many applications still written to use OSS as sound system and hence with those sound was impossible with ALSA.The most problematic thing about apps written with OSS in mind was all of them tried to stream sound via /dev/dsp (OSS Digital Sound Processor), since alsa did not used /dev/dsp those programs was soundless.

On the other hand OSS was creating issues as well, one severe problem with OSS was the inability to stream multiple sounds simultaneously, because each sound stream required to pass voice through /dev/dsp and usually there was only one /dev/dsp.

The message;

/dev/dsp: Device or resource busy
and the proceeding irritation that used to annoy us in the early GNU / Linux days had of course some raw workarounds hacks but generally the workaround did not fix problems always.

Introduction of alsa free us from /dev/dsp issues but on the other handy has created a whole ocean of new BIG problems …
ALSA has modular structure and this imposes a great problem nowdays. The modular architecture is generally a good idea, however the way this was implemented within ALSA is far away from clear and easy to understand by the end user and therefore makes it very unintuitive and obscure.
Alsa misses simplicity which somehow was partially in the days of OSS. Thinking over the general situation with Linux multimedia nowdays, I believe it was exactly ALSA Project responsible for the so delayed mass Desktop Linux adoption.

Many long year standing Linux users had certainly had the alsa troubles during new system installs (correct me if I'm wrong).
The only fix to multiple soundcard initialization problems was to download alsa source and compile from source and hence made it hard and discouraging for people giving Linux a try.
This kind of ALSA "brokenness" pattern continues even to this very day (in Debian) Linux and probably building the alsa system from source is among the good practices to have a functional Linux sound system…

With all said the historic reason why ALSA was not quickly adopted and still is not a preferred default system for many applications ported to Free Software OSes by commercial company vendors is clear. Its simply not working out of the box …

Hope some ALSA developers will read this post work on changing the crazy structure of ALSA over complexity. ALSA needs automate way to solve issues with itself, the configuration should be more trivial and unified if Linux has to become more attractive for Desktop adoption.

Anyways, after the few words of history and indicating my pesonal observations on ALSA. I will proceed and explain few things on how ALSA can be configured to support and play nice with OSS dependant programs as well some basic explanations on common incompatibility between esd and pulseaudio and how this can be fixed;.

To assure nowdays OSS API built programs and games would work with Alsa its necessery to have installed;

ALSA wrapper for OSS applications

On Debian, Ubuntu, Fedora and most Linux distributions the Alsa OSS compatability layer comes under a (deb / rpm) package named alsa-oss

To install OSS compatability on Debian, Ubuntu and the like Debian based distributions issue:

debian:~# apt-get install alsa-oss alsaplayer-oss

On Fedora and other rpm based distributions install is with:

[root@fedora ~]# yum install alsa-oss alsaplayer-oss

alsa-oss provides with a command called aoss that should be used to work around some issues with old applications still depending on OSS:

hipo@debian:~$ aoss programName

Using aoss is helpful especially in situations if you have to run programs which deal with MIDI and others which somehow want to use /dev/dsp

There is also alternative way to enable alsa native support for MIDI and OSS by loading 3 kernel modules:

debian:~# modprobe snd-seq-oss
debian:~# modprobe snd-pcm-oss
debian:~# modprobe snd-mixer-oss

Note! The three modules has to be separately build using kernel source at most cases and does not come with most Linux distributions, so on many installations (including my current), they will be missing. If for you they load properly or you have customly build them add them also to load on system boot, like so:

echo 'snd-seq-oss' >> /etc/modules
echo 'snd-pcm-oss' >> /etc/modules
echo 'snd-mixer-oss' >> /etc/modules

The Linux sound situation becomes even more messy when ESD enters the scene. Many of the novice new Linux users certainly don't remember (Enlightened Sound Daemon) . ESD historically preceded PulseAudio . Hence it will be good to mention ESD was used for few years in GNOME and in around 2006-2007 it was substituted by PulseAudio.
Many applications, however who was ported or written for Linux especially (the proprietary ported ones) was already built to work with ESD and even though newer GNOME releases was fully using pulseaudio, this (non free software apps and games) were still depending on ESD.

The situation was partially fixed by creation of module for pulseaudio which added emulation support for esd . This was done by a module library for pulseaudio called
The package for almost all Linux distributions which does the esd emulation via pulse is pulseaudio-esound-compat . In latest Fedora Linux pulseaudio-esound-compat is installed by default.
In Debian and other Linux distributions it might need to be installed via apt with;

debian:~# apt-get install pulseaudio-esound-compat

pulseaudio-esound-compat solves some of the ESD app incompability but not always …
Handy tool also worthy to mention in solving PulseAudio, OSS incompatibility issues is padsp

padsp is helpful in solving obsolete issues with OSS applications (trying to access /dev/dsp) and therefore unable to communicate with Pulseaudio
padsp – is a PulseAudio OSS Wrapper.

An example where padsp is helpful is in case of /dev/dsp errors like:

/dev/dsp: Device or resource busy
Could not open /dev/dsp

Another common problem with sound on Linux is when running windows applications (running windows games with wine).
Quite often sound fails to work since wine tries to directly communicate with alsa and fails because alsa sound channel is taken by pulseaudio.

To workaround wine issues with pulseaudio, one of the solutions is to temporary stop pulseaudio, before running the wine emulated application:

hipo@debian:~$ pulseaudio --kill

Later on when the windows wine emulation is completed, pulseaudio has to be started once again in order to make Pulseaudio applications produce sound again, e.g. one has to issue:

hipo@debian:~$ pulseaudio --start
Alternative way to workaround wine sound issues is by using a script to kill pulseaudio every second. Here is script

This script was reported by many people as fix to problems with wine games failing to play sounds and music, anyhow I personally prefer using the stop / start pulseaudio method.

The picture below is taken from Wikipedia and illustrates, clearly the intergalactical complexity of sound systems on Gnu / Linux and BSD

I just hope one day this (OSS, ALSA, esd, Pulseaudio) mess will be over! In the mean time I hope my suggested work arounds helps someone. If someone has a better more unified script or solution please share in comments

How to check any filesystem for bad blocks using GNU / Linux or FreeBSD with dd

Monday, November 28th, 2011

Check any filesystem partition for BAD BLOCKS with DD on GNU Linux and FreeBSD

Have you looked for a universal physical check up tool to check up any filesystem type existing on your hard drive partitions?
I did! and was more than happy to just recently find out that the small UNIX program dd is capable to check any file system which is red by the Linux or *BSD kernel.

I’ll give an example, I have few partitions on my laptop computer with linux ext3 filesystem and NTFS partition.
My partitions looks like so:

noah:/home/hipo# fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2d92834c
Device Boot Start End Blocks Id System
/dev/sda1 1 721 5786624 27 Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2 * 721 9839 73237024 7 HPFS/NTFS
/dev/sda3 9839 19457 77263200 5 Extended
/dev/sda5 9839 12474 21167968+ 83 Linux
/dev/sda6 12474 16407 31593208+ 83 Linux
/dev/sda7 16407 16650 1950448+ 82 Linux swap / Solaris
/dev/sda8 16650 19457 22551448+ 83 Linux

For all those unfamiliar with dddd – convert and copy a file this tiny program is capable of copying data from (if) input file to an output file as in UNIX , the basic philosophy is that everything is a file partitions themselves are also files.
The most common use of dd is to make image copies of a partition with any type of filesystem on it and move it to another system
Looking from a Windows user perspective dd is the command line Norton Ghost equivalent for Linux and BSD systems.
The classic way dd is used to copy let’s say my /dev/sda1 partition to another hard drive /dev/hdc1 is by cmds:

noah:/home/hipo# dd if=/dev/sda1 of=/dev/hdc1 bs=16065b

Even though the basic use of dd is to copy files, its flexibility allows a “trick” through which dd can be used to check any partition readable by the operating system kernel for bad blocks

In order to check any of the partitions listed, let’s say the one listed with filesystem HPFS/NTFS on /dev/sda2 using dd

noah:/home/hipo# dd if=/dev/sda2 of=/dev/null bs=1M

As you can see the of (output file) for dd is set to /dev/null in order to prevent dd to write out any output red by /dev/sda2 partition. bs=1M instructs dd to read from /dev/sda2 by chunks of 1 Megabyte in order to accelerate the speed of checking the whole drive.
Decreasing the bs=1M to less will take more time but will make the bad block checking be more precise.
Anyhow in most cases bs of 1 Megabyte will be a good value.

After some minutes (depending on the partition size), dd if, of operations outputs a statistics informing on how dd operations went.
Hence ff some of the blocks on the partition failed to be red by dd this will be shown in the final stats on its operation completion.
The drive, I’m checking does not have any bad blocks and dd statistics for my checked partition does not show any hard drive bad block problems:

71520+1 records in
71520+1 records out
74994712576 bytes (75 GB) copied, 1964.75 s, 38.2 MB/s

The statistics is quite self explanatory my partition of s size 75 GB was scanned for 1964 seconds roughly 32 minutes 46 seconds. The number of records red and written are 71520+1 e.g. (records in / records out). This means that all the records were properly red and wrote to /dev/null and therefore no BAD blocks on my NTFS partition 😉

Easy way to look for irregularities and problems in log files / Facilitate reading log files on GNU / Linux and FreeBSD

Thursday, November 24th, 2011

LogWatch logo picture check Logcheck Linux BSD look for irregularities in log files

As a System Administrator I need to check daily the log files produced on various GNU / Linux distributions or FreeBSD. This can sometimes take too much time if the old fashioned way using the normal system tools cat, less and tail etc. is used.

Reading logs one by one eats too much of my time and often as logs are reviewed in a hurry some crucial system irregularities, failed ssh or POP3 / Imap logins, filling disk spaces etc. are missed.

Therefore I decided to implement automated log parsing programs which will summary and give me an overview (helicopter view) on what were the system activities from the previous day (24h) until the moment I logged the system and issued the log analyzer program.
There are plenty of programs available out there that does “wide scale” log analysis, however there are two applications which on most GNU / Linux and BSD systems had become a de-facto standard programs to scan system log files for interesting lines.

These are:

  • 1. logwatchsystem log analyzer and reporter
  • 2. logcheckprogram to scan system log files for interesting lines

1. logwatch is by default installed on most of the Redhat based Linux systems (Fedora, RHEL, CentOS etc.). On Debian distributions and as far as I know (Ubuntu) and the other deb based distros logwatch is not installed by default. Most of the servers I manage these days are running Debian GNU / Linux so, to use logwatch I needed to install it from the available repository package, e.g.:

debian:~# apt-get install logwatch

logwatch is written in perl and with some big files to analyze, parsing them might take hell a lot of time. It does use a bunch of configuration scripts which defines how logwatch should read and parse the various services logwatch support by default. These conf scripts are also easily extensible, so if one has to analyze some undefined service in the conf files he can easily come up with a new conf script that will support the service/daemon of choice.Using logwatch is very easy, to get an overview about server system activity invoke the logwatch command:

debian:~# logwatch
################### Logwatch 7.3.6+cvs20080702-debian (07/02/08) ####################
Processing Initiated: Thu Nov 24 05:22:07 2011
Date Range Processed: yesterday
( 2011-Nov-23 )
Period is day.
Detail Level of Output: 0
Type of Output/Format: stdout / text
Logfiles for Host: debian

——————— dpkg status changes Begin ————- 

libfreetype6 2.3.7-2+lenny7 => 2.3.7-2+lenny8
libfreetype6-dev 2.3.7-2+lenny7 => 2.3.7-2+lenny8

———————- dpkg status changes End ————————-

——————— httpd Begin ————————

Requests with error response codes
400 Bad Request
HTTP/1.1: 2 Time(s)
admin/scripts/setup.php: 2 Time(s)
401 Unauthorized

———————- vpopmail End ————————-

——————— Disk Space Begin ————————

Filesystem Size Used Avail Use% Mounted on
/dev/md0 222G 58G 154G 28% /

———————- Disk Space End ————————-

###################### Logwatch End #########################

The execution might take up from 10 to 20 seconds up to 10 or 20 minutes depending on the log files size and the CPU / RAM hardware on the machine where /var/log/… logs will be analyzed.

logwatch output can be easily mailed to a custom mail address using a crontab if the server runs a properly configured SMTP server. Using a cron like:

00 5 * * * /usr/sbin/logwatch | mail -s "$(hostname) log files for $(date)"

Here is time to make a note that logwatch is ported also to FreeBSD and is available from BSD’s port tree, from a port with path:


2. logcheck is another handy program, which does very similar job to logwatch . The “interesting” information it returns is a bit less than compared to logwatch

The good thing about logcheck is that by default it is made to mail every 1 hour a brief data summary which might be of an interest to the sys admin.
Logcheck is available for install on RedHat distros via yum and has existing package for Debian as well as a port for FreeBSD under the port location /usr/ports/security/logcheck

To install on logcheck on Debian:

debian:~# apt-get install logcheck

After installation I found it wise to change the default mailing time from each and every hour to just once per day to prevent my email from overfilling with “useless” mails.

This is done by editting the default cron tab installed by the package located in /etc/cron.d/logcheck

The default file looks like so:

# /etc/cron.d/logcheck: crontab entries for the logcheck package
@reboot logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
2 * * * * logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi

To change it run only once per day its content should looks something like:

# /etc/cron.d/logcheck: crontab entries for the logcheck package
@reboot logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
2 5 * * * logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi

Altering it that way the log summary interesting info analysis will be sent on mail every day in 05:02 a.m.
Changing the default email logcheck will ship its log analyzer report emails on deb based distros is done via editting the file:


And changing the SENDMAILTO=”” variable to point to the appropriate admin email email addr.