[Solved] HDAudio -- lots of noise after some reboots

[igorzwx]

@igorzwx: You're quite the grump, aren't you?
Also, your suggestion didn't work.

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).

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=15880
It 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.

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.html
They 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:

Code: Select all

$ yaourt gnome-settings-daemon-nopulse
1 aur/gnome-settings-daemon-nopulse 3.4.1-2 (Out of Date) (35)
    The GNOME Settings daemon, without PulseAudio support
==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3)
==> -------------------------------------------------------
==>

The OSS4 packages are not yet outdated:

Code: Select all

1 community/oss 4.2_2006-4
    Open Sound System UNIX audio architecture
2 community/libflashsupport-oss 4.2_2006-4
    Adobe flash plugin support lib (OSSv4)
3 aur/oss-hg 894-1 (30)
    Open Sound System UNIX audio architecture
4 aur/lib32-libflashsupport-oss 4.2_2003-1 (21)
    Open Sound System UNIX audio architecture support for Flash plugin

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.

The problem of switching OSS4<->ALSA can be solved with a simple script:
viewtopic.php?f=3&t=3981&p=15880
viewtopic.php?f=3&t=4772#p18645

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

[PulseCloud]

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.

[igorzwx]

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.

You may try to preload ALSA modules with mkinitcpio

Code: Select all

$ cat /etc/mkinitcpio.conf
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
#
#MODULES="ac battery button processor thermal fan video cdrom agpgart ati_agp tpm_bios tpm tpm_tis tpm_tis dcdbas drm_kms_helper drm radeon ttm hid k8temp i2c_algo_bit i2c_piix4 i2c_core evdev joydev psmouse serio_raw sparse_keymap mmc_core pci_hotplug shpchp dell_laptop dell_wmi wmi ssb sp5100_tco crc_itu_t pata_atiixp scsi_mod ahci libahci libphy ppp_generic slhc tg3 rfkill pcmcia_core pcmcia pcmcia_rsrc yenta_socket usbhid usbcore ehci_hcd ohci_hcd firewire_core firewire_ohci sd_mod sr_mod st sg media uvcvideo videodev usb_storage fuse loop b43 mac80211 cfg80211 bcma"

# Wireless - do not load here
# ssb b43

# Failed to find st sg
# scsi_mod st sg

MODULES="ac battery button processor thermal fan video cdrom agpgart ati_agp tpm_bios tpm tpm_tis tpm_tis dcdbas drm_kms_helper drm radeon ttm hid k8temp i2c_algo_bit i2c_piix4 i2c_core evdev joydev psmouse serio_raw sparse_keymap mmc_core pci_hotplug shpchp dell_laptop dell_wmi wmi sp5100_tco crc_itu_t pata_atiixp ahci libahci libphy ppp_generic slhc tg3 rfkill pcmcia_core pcmcia pcmcia_rsrc yenta_socket usbhid usbcore ehci_hcd ohci_hcd firewire_core firewire_ohci sd_mod sr_mod media uvcvideo videodev usb_storage fuse loop mac80211 cfg80211 bcma"


# 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 libraries
BINARIES=""

# 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

[code]# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"[/code]
#
##   This setup assembles a pata mdadm array with an encrypted root FS.
##   Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
#    HOOKS="base udev pata mdadm encrypt filesystems"
#
##   This setup loads an lvm2 volume group on a usb device.
#    HOOKS="base udev usb lvm2 filesystems"
HOOKS="base udev autodetect pata scsi sata filesystems keymap usbinput fsck"

# 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"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""

MODULES
The MODULES array is used to specify modules to load before anything else is done. To accelerate the boot process, users may opt to disable the udev hook and list required modules here instead:

Code: Select all

MODULES="piix ide_disk reiserfs"

[...]

HOOKS="base autodetect ide filesystems"

https://wiki.archlinux.org/index.php/Mkinitcpio#MODULES

WARNING: It is supposed that advanced users know which modules should be loaded. Otherwise, disabling of the udev hook may case troubles.

HINT: Preload some modules (including ALSA modules), and do not disable the udev hook .

It is not a simple procedure. The manual is here: https://wiki.archlinux.org/index.php/Mkinitcpio

Save a copy of your Linux kernel image,
/boot/initramfs-linux.img
/boot/initramfs-linux-fallback.img
before doing such experiments. And make backups.