I 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 OSS – Open 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.
/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 libprotocol-esound.so
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 fix_pulseaudio_wine_sound_probs.sh 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 permanently enable Cookies in Lynx text browser – Disable accept cookies prompt in lynx console browserWednesday, April 18th, 2012
The default behaviour of lynx – console text browser on Linuces, BSD and other free OSes is to always ask, for the accept cookies prompt once an internet web page is opened that requires browser cookies to be enabled.
I should admin, having this "secure by default" (always ask for new cookies) behaviour in lynx was a good practice from a security point of view.
Another reason, why this cookies prompt is enabled by default is back in the days, when lynx was actively developed by programmers the websites with cookies support was not that many and even cookies was mostly required for user/pass authentication (all those who still remember this days the websites that requires authentication was a way less than today) …
With this said the current continuing security cautious behaviour in the browser, left from its old days is understandable.
However I personally sometimes, need to use lynx more frequently and this behaviour of always opening a new website in text mode in console to prompts me for a cookie suddenly becomes a big waste of time if you use lynx to browser more than few sites. Hence I decided to change the default way lynx handles cookies and make them enabled by default instead.
Actually even in the past, when I was mainly using internet in console on every new server or home Linux install, I was again making the cookies to be permanently accepted.
Everyone who used lynx a few times already knows its "annoying" to all time accept cookie prompts … This provoked me to write this short article to explain how enabling of constant cookie accepting in lynx is done
To enable the persistent cookies in lynx, one needs to edit lynx.cfg on different GNU / Linux and BSD* distributions lynx.cfg is located in different directory.
Most of the lynx.cfg usual locations are /etc/lynx/lynx.cfg or /etc/lynx.cfg as of time of writting this post in Debian Squeeze GNU / Linux the lynx.cfg is located in /etc/lynx-cur/lynx.cfg, whether for FreeBSD / NetBSD / OpenBSD users the file is located in /usr/local/etc/lynx.cfg
What I did to allow all cookies is open lynx.cfg in vim edit and change the following lines:
uncomment it to:
c) next, change
Onwards opening any website with lynx auto-accepts the cookies.
For people who care about there security (who still browse in console (surely not many anymore)), permanently allowing the cookies is not a good idea. But for those who are ready to drop off little security for convenience its ok.
Tags: ALL, authentication, Auto, browser cookies, BSD, bsd distributions, cfg, change, convenience, Cookie, default behaviour, Draft, everyone, file, free oses, GNU, gnu linux, good, How to, internet web, Linux, Lynx, lynx one, NetBSD, Onwards, OpenBSD, page, persistent cookies, point of view, programmers, quot, reason, security point, squeeze, support, text, text browser, text mode, time, TRUEb, TRUEc, TRUEuncomment, uncomment, use, using internet, vim, waste, waste of time, web page, writ
Posted in Curious Facts, Everyday Life, FreeBSD, Linux, System Administration | 1 Comment »