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

[PulseCloud]

Greetings.
I have Arch Linux installed on a Dell XPS L502X laptop.
After installing OSS while following the guide on the Arch Wiki [link below], everything works perfectly.
After a couple of reboots, though, the sound is filled with noise: not white noise, something more, well, convoluted.
If I disable vmix0 (ossmix vmix0-enable OFF), mplayer's playback is almost perfect: there's some hickups and noise here and there, but it's nothing compared to using vmix0 (which isn't ideal, though, because I want flawless playback). Youtube videos remain impossibly awful, though (I have libflashsupport-oss installed).

I don't know what info to provide, so please tell me if you need to know something.

Help would be much appreciated.
Thank you.

Link to Arch Wiki's OSS page: wiki.archlinux.org/index.php/Open_Sound_System

----------------------------------------------------------
EDIT:
The solution (more like a hack) was posted by cesium in this post: http://www.opensound.com/forum/viewtopic.php?f=3&t=4772&sid=a5299395cb3cfe94d77d348c2cae0858&sid=a5299395cb3cfe94d77d348c2cae0858#p18645
Basically, add this to /etc/rc.local

Code: Select all

tar -C /lib/modules/$(uname -r) -xjf /lib/modules/$(uname -r)/sound-preoss.tar.bz2
depmod -a
modprobe snd-hda-intel
soundon > /dev/null 2>&1


Make sure you don't have "oss" in the /etc/rc.conf daemons list.
Also, you need bzip2: pacman -S bzip2

Conclusion: how to use OSS on a Dell XPS L502X in Arch Linux (it adds 30 seconds to the boot time, but hey -- it works)

Code: Select all

# Install OSS and libflashsupport-oss to add support to Flash (eg: Youtube videos)
sudo pacman -S oss libflashsupport-oss

# cesium's fix
sudo soundon
sudo echo 'tar -C /lib/modules/$(uname -r) -xjf /lib/modules/$(uname -r)/sound-preoss.tar.bz2' >> /etc/rc.local
sudo echo 'depmod -a'                >> /etc/rc.local
sudo echo 'modprobe snd-hda-intel'   >> /etc/rc.local
sudo echo 'soundon > /dev/null 2>&1' >> /etc/rc.local

# Optional: add 96kHz sample rate support by adding "vmixctl rate /dev/dsp 96000" to the file
# /usr/lib/oss/soundon.user and making it executable
sudo sed '/exit 0/ i\vmixctl rate /dev/dsp 96000' -i /usr/lib/oss/soundon.user
sudo chmod +x /usr/lib/oss/soundon.user

# Optional: install a media player, mplayer, and configure it to use OSS
sudo pacman -S mplayer
mkdir -p /home/$USER/.mplayer
echo "ao=oss" >> /home/$USER/.mplayer/config


[igorzwx]

Greetings.
I have Arch Linux installed on a Dell XPS L502X laptop.
After installing OSS while following the guide on the Arch Wiki [link below], everything works perfectly.
After a couple of reboots, though, the sound is filled with noise: not white noise, something more, well, convoluted.
If I disable vmix0 (ossmix vmix0-enable OFF), mplayer's playback is almost perfect: there's some hickups and noise here and there, but it's nothing compared to using vmix0 (which isn't ideal, though, because I want flawless playback). Youtube videos remain impossibly awful, though (I have libflashsupport-oss installed).

I don't know what info to provide, so please tell me if you need to know something.

Help would be much appreciated.
Thank you.

Link to Arch Wiki's OSS page: wiki.archlinux.org/index.php/Open_Sound_System

If it was caused by reboot, the problem might be fixed with chattr http://en.wikipedia.org/wiki/Chattr

To verify this, you may re-install OSS4. Do not forget to remove /usr/lib/oss

It is not always necessary to disable vmix, it might be sufficient to disable resampling:

Code: Select all

vmix0-src <Fast|High|High+|Production|OFF> (currently OFF)

You may post the output of ossinfo, ossmix, and lspci -vnn
Mark them as "code".

Multimedia packages in Arch Linux are usually buggy and infected with libpulse.
To avoid troubles, you have to remove libpulse and recompile everything: ffmpeg, deadbeef, mplayer, vlc, etc.

[PulseCloud]

I removed oss and libflashsupport-oss, deleted /usr/lib/oss, reinstalled both programs and muted the PC speaker so I would only get sound on my headphones.
ossinfo: http://pastebin.com/FiWZCs54
ossmix: http://pastebin.com/uLbDe8bk
lspci -vnn: http://pastebin.com/wW9pBK8g
Sound is mostly fine on mplayer (some noise here and there), but Youtube is awful. Also, if I move the mouse around or use the keyboard, the sound gets completely distorted, even on mplayer.

After rebooting once, everything is perfect: mplayer, Youtube and the mouse and keyboard.
Here's the output of "dmesg | grep -i hda" after the reboot: http://pastebin.com/GhUUmgBQ

After rebooting once again, Youtube sound is broken and moving the mouse breaks mplayer's sound. mplayer presents some noise when not moving.
Here's the output of "dmesg | grep -i hda" after the reboot: http://pastebin.com/n8YSeqSd

After rebooting two more times, I wrote "vmixctl rate /dev/dsp 96000" in the file /usr/lib/oss/soundon.user and made it executable. I then ran soundoff and soundon.
mplayer's sound is now broken. Changing vmix0-src does nothing. Here's more data:
ossinfo: http://pastebin.com/fW2fgJYb
ossmix: http://pastebin.com/QLvP9NYb
lspci -vnn: http://pastebin.com/Q7C95rhQ


I use a JFS filesystem so I guess I can't test chattr...

[igorzwx]

I removed oss and libflashsupport-oss, deleted /usr/lib/oss, reinstalled both programs and muted the PC speaker so I would only get sound on my headphones.
ossinfo: http://pastebin.com/FiWZCs54
ossmix: http://pastebin.com/uLbDe8bk
lspci -vnn: http://pastebin.com/wW9pBK8g
Sound is mostly fine on mplayer (some noise here and there), but Youtube is awful. Also, if I move the mouse around or use the keyboard, the sound gets completely distorted, even on mplayer.

After rebooting once, everything is perfect: mplayer, Youtube and the mouse and keyboard.
Here's the output of "dmesg | grep -i hda" after the reboot: http://pastebin.com/GhUUmgBQ

After rebooting once again, Youtube sound is broken and moving the mouse breaks mplayer's sound. mplayer presents some noise when not moving.
Here's the output of "dmesg | grep -i hda" after the reboot: http://pastebin.com/n8YSeqSd

After rebooting two more times, I wrote "vmixctl rate /dev/dsp 96000" in the file /usr/lib/oss/soundon.user and made it executable. I then ran soundoff and soundon.
mplayer's sound is now broken. Changing vmix0-src does nothing. Here's more data:
ossinfo: http://pastebin.com/fW2fgJYb
ossmix: http://pastebin.com/QLvP9NYb
lspci -vnn: http://pastebin.com/Q7C95rhQ


I use a JFS filesystem so I guess I can't test chattr...

You may try to install the "closed-source" package of OSS4. It should have "HDAudio PCI device IDs" viewtopic.php?f=19&t=4754#p18535

[cesium]

You could be having a similar issue to this. Consider building from hg repo.

[PulseCloud]

I built OSS from hg.
When it was finished, I tried mplayer: moving the mouse created lots of noise.
Here's some output:
ossinfo: http://pastebin.com/KnM0UXtS
ossmix: http://pastebin.com/ceEWGZS0
lspci -vnn: http://pastebin.com/LHh1itZC

After that, I rebooted.
I tested mplayer and it said

Code: Select all

[AO OSS] audio_setup: Can't open audio device /dev/dsp: No such file or directory
Failed to initialize audio driver 'oss'
Could not open/initialize audio device -> no sound.


So I ran soundon. Here's the output:

Code: Select all

Error: Module snd_hda_codec_hdmi is in use
Error: Module snd_hda_codec_realtek is in use
Error: Module snd_hda_codec is in use by: snd_hda_codec_realtek snd_hda_codec_hdmi
Error: Module snd_hwdep is in use by: snd_hda_codec
Error: Module snd_pcm is in use by: snd_hda_codec_hdmi snd_hda_codec
Error: Module snd_page_alloc is in use by: snd_pcm
Error: Module snd_timer is in use by: snd_pcm


And here's "dmesg | grep -i hda"

Code: Select all

[    6.950515] snd_hda_intel 0000:00:1b.0: irq 54 for MSI/MSI-X
[    7.630615] hda_codec: ALC665: SKU not ready 0x598301f0
[    7.632874] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input9
[    7.779796] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[    7.780118] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[    7.780164] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[    7.780205] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
[   73.393351] oss_hdaudio: HDA codec 0x10ec0665 not known yet
[   73.404176] oss_hdaudio: HDA codec 0x80862805 not known yet
[   73.406733] oss_hdaudio: HDA codec 0x10ec0665 not known yet
[   73.407134] oss_hdaudio: HDA codec 0x80862805 not known yet


I rebooted again. I tried to restart the oss daemon with "sudo rc.d restart oss", but it said

Code: Select all

:: Daemon script oss does not exist or is not executable.

So I ran soundon again. It worked, so I tried mplayer: mouse still breaks the sound.
Setting the Sample Rate to 96000 makes it even worse.

I don't know what to do. Now I can't even start oss at boot due to no daemon...

[igorzwx]

The "closed source" OSS4 package can be downloaded here: http://www.opensound.com/download.html
together with manual.

It is very simple. Download tar package and run the install script.

If nothing helps, you may try to change permissions for /usr/lib/oss (and its content) after fresh install.
If the owner is not allowed to modify anything inside...
It is more reliable to set the immutable bit (recursively) with chattr (if it works).

Do not forget to remove the old /usr/lib/oss before new install.

If it is very difficult to fix sound on Arch, you may try Ubuntu, Linux Mint, or else.

Do not forget that Arch Linux is crapware. It may even destroy your processor viewtopic.php?f=3&t=4349#p18327

[cesium]

OK, so that didn't help (and I don't think the closed source binary would do any good - it's almost the same). Anyhow, starting oss at boot: add soundon to whereever arch allows the user to add startup commands (it's usually /etc/rc.local on distros). As for noise, lets (before trying 96000 - that's for later), try some stuff:
A) disabling vmix ("ossmix vmix0-enable OFF" when nothing is playing). [Edit: Nevermind. I forgot the note in the original message about this]
B) playing with the mixer to mute input (mute all the non-vmix controls in ossxmix and then trying unmuting stuff and see what happens).

[igorzwx]

OK, so that didn't help (and I don't think the closed source binary would do any good - it's almost the same). Anyhow, starting oss at boot: add soundon to whereever arch allows the user to add startup commands (it's usually /etc/rc.local on distros). As for noise, lets (before trying 96000 - that's for later), try some stuff:
A) disabling vmix ("ossmix vmix0-enable OFF" when nothing is playing).
B) playing with the mixer to mute input (mute all the non-vmix controls in ossxmix and then trying unmuting stuff and see what happens).

As I remember, it was sufficient to make immutable /usr/lib/oss/etc and some other subfolder of /usr/lib/oss/
It was a very old notebook with ICH6. It was a very long story of "trial and error". We discussed it in detail some years ago.

It seems that the content of /usr/lib/oss/ has already changed.

Could you please explain which subfolders of /usr/lib/oss/ should be made immutable?
It is not very convenient to have all the /usr/lib/oss/ immutable, because a kernel upgrade may kill sound.

[cesium]

Hmmm... Well, IIRC the only thing we changed at the time was dealing with the /usr/lib/oss/etc/mixer.save file. It doesn't really have to be immutable - we can erase it and comment out the line in /usr/sbin/soundoff which creates it ('savemixer'). One more idea - try to load ALSA first and then run "sudo soundon" to load OSS instead - I wonder if this is an init issue.

[igorzwx]

Hmmm... Well, IIRC the only thing we changed at the time was dealing with the /usr/lib/oss/etc/mixer.save file. It doesn't really have to be immutable - we can erase it and comment out the line in /usr/sbin/soundoff which creates it ('savemixer'). One more idea - try to load ALSA first and then run "sudo soundon" to load OSS instead - I wonder if this is an init issue.

As I remember, It was not sufficient to make /usr/lib/oss/etc/ immutable together with all its content.
Some other subfolder should be made immutable too. It was, however, some years ago. The problem had persisted for two years.
And it may still persist. I may try to find that old notebook next week.

In that particular case, reloading OSS (soundoff/soundon) had the same effect as reboot.
So that, experiments can be made with Arch LiveCD and that "closed-source" package of OSS4.
Archiso LiveCD: viewtopic.php?f=3&t=3933&p=15691#p17316
CTKArch LiveCD: viewtopic.php?f=3&t=3933&p=15691#p17359
Chakra LiveCD (fork of Arch): http://chakra-linux.org/

Although it may seem to be a dirty hack, it may help to localize the problem.
It is very probable, that it might be sufficient to make "immutable" just a few "mysterious files" inside /usr/lib/oss to fix the problem.
Perhaps, certain files are actually modified during the first reboot, those files which should not be modified during reboot (a kind of bug, an unpredictable behaviour of buggy software).

[PulseCloud]

I did a clean install of Arch Linux (even though igorzwx thinks it's "crap", but for him everything is crap ) and then installed OSS.
After installing OSS from the Arch repos, I tested it with a YT video and, as expected, worked wonderfully.
I then executed the following command and rebooted:

Code: Select all

# chattr -R +i /usr/lib/oss

I then tried to do soundon. It worked, but it said "touch: cannot touch '/usr/lib/oss/starting': Permission denied".
I tested it with a YT video and it was awful. I undid the chattr command, soundoff && soundon, and it still was awful.

Before reinstalling Arch, I tried running the scripts in /usr/lib/oss/scripts and /usr/lib/oss/build/install.sh, but they didn't fix the problem.

I don't know, guys, I have no idea what's happening.
As a musician, I can't fathom using ALSA or PulseAudio knowing that there's something better out there, OSS, but alas, ALSA works and OSS is really trying to push me away.
I was thinking of buying a USB DAC, the HRT Music Streamer II, to complete my headphones+amp setup. By using the DAC am I bypassing the "crap" part of ALSA? Are they even supported by anything other than Windows and Mac OS?

I still want this fixed, so please tell me if you have any idea.

[igorzwx]

I did a clean install of Arch Linux (even though igorzwx thinks it's "crap", but for him everything is crap ) and then installed OSS.
After installing OSS from the Arch repos, I tested it with a YT video and, as expected, worked wonderfully.
I then executed the following command and rebooted:

Code: Select all

# chattr -R +i /usr/lib/oss

I then tried to do soundon. It worked, but it said "touch: cannot touch '/usr/lib/oss/starting': Permission denied".
I tested it with a YT video and it was awful. I undid the chattr command, soundoff && soundon, and it still was awful.

Before reinstalling Arch, I tried running the scripts in /usr/lib/oss/scripts and /usr/lib/oss/build/install.sh, but they didn't fix the problem.

I don't know, guys, I have no idea what's happening.
As a musician, I can't fathom using ALSA or PulseAudio knowing that there's something better out there, OSS, but alas, ALSA works and OSS is really trying to push me away.
I was thinking of buying a USB DAC, the HRT Music Streamer II, to complete my headphones+amp setup. By using the DAC am I bypassing the "crap" part of ALSA? Are they even supported by anything other than Windows and Mac OS?

I still want this fixed, so please tell me if you have any idea.

Just two commands:

Code: Select all

# chattr -R +i /usr/lib/oss
# chattr -i /usr/lib/oss

Then try soundon/soundoff
It should work without problems.

see: http://en.wikipedia.org/wiki/Chattr

Code: Select all

$ man chattr

Then try to play a wave with ossplay
Then test other players.

Then you may try to unset (recursively) the immutable bit on some subfolders of /usr/lib/oss

/usr/lib/oss/etc should stay immutable together with its content.
You should minimize "immutable staff". Otherwise, you may get problems with a kernel upgrade.

As I remember, I managed to minimize "immutable staff" to two subfolders of /usr/lib/oss
Kernel upgrades did not make any harm.

It seems that modern musicians lack imagination and creativity...

After installing OSS from the Arch repos

This package is said to be buggy https://mailman.archlinux.org/pipermail ... 23511.html
It is actually orphaned and going to be deprecated.
You may want to read bug report: https://bugs.archlinux.org/task/31405 [libflashsupport]

[cesium]

Well, my understanding was that releasing new source tarballs would help with the orphan package issue... Anyhow, back to this: Can you do some checks?

A) look at the oss source code you have. Does it include this part?

B) I assume OSS is still installed at your comp, so do this:
"cd /lib/modules/$(uname -r)"
"sudo tar xf sound-preoss.tar.bz2" (we're restoring the ALSA modules)
"depmod -a"
"sudo soundoff" (turn oss off if oss is loaded)
"modprobe snd-hda-intel" (load ALSA)
"sudo soundon" (load OSS again. OSS will unload ALSA automatically)

now test sound. The idea is to let ALSA init the card and then load OSS - if sound works well, then we can conclude this is an OSS card initialization issue.

[PulseCloud]

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

----------------------------
EDIT 1:
@cesium: Great timing there, mate! I'll try reinstalling Arch and trying that without installing alsa-utils.
EDIT 2 (about 5 minutes after EDIT 1):
Actually, 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.