Uninstalling OSS, deleting its dir and reinstalling doesn't fix the problem.What does work is uninstalling, deleting its dir, installing alsa-utils from the Arch repos, starting the snd_hda_intel module and reinstalling OSS. But doing this every boot is obviously impractical.

Before installing OSS the first time, a bunch of snd_hda_* modules exist. After installing OSS, they're deleted and they're not recreated when uninstalling OSS.I THINK that installing alsa-utils and then OSS makes OSS recreate those modules when removed. Not sure, though (would have to reinstall Arch again, even though it takes 20 mins).

PulseCloud wrote:I tried it and it works perfectly.I'd have to do it every boot, though, which would add quite some time to the boot...If there's no other way (building just snd-hda-intel?), I guess I have no choice but to do it until OSS is patched.

It should not be very difficult to modify the OSS4 starting script /etc/rc.d/oss (it is a simple bash script in Arch Linux), so that it will load ALSA modules before loading OSS4. It would add a second to the boot time.The ALSA starting script is /etc/rc.d/alsa (in Arch Linux). You may open it with a text editor and see what is inside.

One year ago it was still possible to load ALSA without uninstalling OSS4 viewtopic.php?f=3&t=3981&p=15880It took a few minutes to switch from OSS4 to ALSA, and other way round.

In the beginning of 2012 it did not work anymore (because of radical innovations, such as sound-preoss.tar.bz2).Perhaps, Cesium may explain how to roll it back.

cesium wrote:Well, my understanding was that releasing new source tarballs would help with the orphan package issue...

The delay of the latest tarball release for a few days was a formal reason to deprecate OSS4. It was just a pretext, nothing more. It is not difficult to find other "ostensible reasons", if you want to get rid of OSS4 (it is not purely "open source" in an absolute sense, an so on).The real reason is that it became rather difficult to maintain both ALSA and OSS4 simultaneously.This was clearly explained https://mailman.archlinux.org/pipermail ... 23511.htmlThey seem to be paid for maintaining PulseALSA, not for maintaining OSS4. The real reason is always money, the lack of resources and the like.

Incompetence and impotence might also be real reasons. The Arch developers had already deprecated the so-called "unsupported patch" of gnome-settings-daemon in accord with a certain "plan" viewtopic.php?f=3&t=4153 This mostly affected those ALSA users, who do not want to use PulseAudio. Many of them might already have switched to other Linux distros. It was surely planed to deprecate OSS4 as soon as possible.

gnome-settings-daemon-nopulse is now in AUR. It is already outdated and orphaned, but not yet thrown away:

The personal (pragmatic) interests of the developers are always much more important than the interests of the users. This is true not only for "open source", of course. You may need to get rid of "idealistic dreams", "unrealistic hopes", and "naive illusions", if you are going to solve practical problems:

Realpolitik refers to politics or diplomacy based primarily on power and on practical and material factors and considerations, rather than ideological notions or moralistic or ethical premises. In this respect, it shares aspects of its philosophical approach with those of realism and pragmatism. http://en.wikipedia.org/wiki/Realpolitik

From the pragmatic point of view, it might be reasonable to pretend that OSS4 is "user friendly" and "easy to use", and the interests of users are not neglected by OSS4 developers. You may even promise "professional sound quality", a "lossless player" (for HiRes FLACs), and anything else, including the so-called "production quality with extra precision" (which somehow vanished from the OSS4 package), and any other sort of Cargo and miracles. Such a "cynical pragmatism" might be in perfect accord with the Open Source Testament. You may try to follow the precepts. It is about "survival strategy", you see.

An official manual and tested scripts, which automatize changing of sound system (OSS4 → ALSA → OSS4), might be included into the OSS4 Wiki.

The only problem is ALSA bugs. Otherwise, it would be possible to change sound system (OSS4 → ALSA → OSS4) in a few seconds through a help of a magic script (without reboot and reinstalling OSS4) viewtopic.php?f=3&t=3981&p=15880#p15880

cesium's script solved the problem, so I'm marking this thread as [Solved].The only drawback is the additional 30 seconds added to each boot, which is quite a lot.I guess the only way for this to be properly solved (ie, not through some dubious hack) is in the devs' hands.

Thank you both, igorzwx and cesium.If you know of a way to shorten the time it takes to fix OSS at boot, please post.

PulseCloud wrote:cesium's script solved the problem, so I'm marking this thread as [Solved].The only drawback is the additional 30 seconds added to each boot, which is quite a lot.I guess the only way for this to be properly solved (ie, not through some dubious hack) is in the devs' hands.

Thank you both, igorzwx and cesium.If you know of a way to shorten the time it takes to fix OSS at boot, please post.

# BINARIES# This setting includes any additional binaries a given user may# wish into the CPIO image. This is run first, so it may be used to# override the actual binaries used in a given hook.# (Existing files are NOT overwritten if already added)# BINARIES are dependency parsed, so you may safely ignore librariesBINARIES=""

# FILES# This setting is similar to BINARIES above, however, files are added# as-is and are not parsed in any way. This is useful for config files.# Some users may wish to include modprobe.conf for custom module options# like so:# FILES="/etc/modprobe.d/modprobe.conf"FILES=""

# HOOKS# This is the most important setting in this file. The HOOKS control the# modules and scripts added to the image, and what happens at boot time.# Order is important, and it is recommended that you do not change the# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for# help on a given hook.# 'base' is _required_ unless you know precisely what you are doing.# 'udev' is _required_ in order to automatically load modules# 'filesystems' is _required_ unless you specify your fs modules in MODULES# Examples:## This setup specifies all modules in the MODULES setting above.## No raid, lvm2, or encrypted root is needed.# HOOKS="base"### This setup will autodetect all modules for your system and should## work as a sane default# HOOKS="base udev autodetect pata scsi sata filesystems"### This is identical to the above, except the old ide subsystem is## used for IDE devices instead of the new pata subsystem.# HOOKS="base udev autodetect ide scsi sata filesystems"### This setup will generate a 'full' image which supports most systems.## No autodetection is done.# HOOKS="base udev pata scsi sata usb filesystems"/etc/mkinitcpio.conf

# COMPRESSION# Use this to compress the initramfs image. With kernels earlier than# 2.6.30, only gzip is supported, which is also the default. Newer kernels# support gzip, bzip2 and lzma. Kernels 2.6.38 and later support xz# compression.#COMPRESSION="gzip"#COMPRESSION="bzip2"#COMPRESSION="lzma"#COMPRESSION="xz"#COMPRESSION="lzop"