Some interesting reads:
-- "A history of S_IFMT":
http://www.lubutu.com/soso/a-history-of-sifmt
-- "TASK_KILLABLE":
http://lwn.net/Articles/288056/
-- The syscall "signalfd()" which was new to me (whoops):
http://man7.org/linux/man-pages/man2/signalfd.2.html
-- Why "signalfd()" doesn't solve your problems either:
https://ldpreload.com/blog/signalfd-is-useless
____________________
I spent the better part of the weekend experimenting with PulseAudio.
I've always avoided PulseAudio as best as I could. It's a big
application and people say it causes a lot of problems. Most
importantly, plain ALSA worked okay for me. I have a pretty simple
setup (just a soundcard and speakers) that doesn't change a lot. So
why bother?
Recently, I wanted to use HDMI audio. It took me about an hour to
write an asoundrc for that purpose. Oh, right, I explicitly disabled
HDMI audio before because it was getting in the way.
I also wanted to make use of some bluetooth speakers, but I didn't
even try to get them working.
Okay, let's just give PulseAudio a try.
It works a lot better than I expected. No stuttering, no high latency,
no crashes (yet). The feature set is nice. All applications, even
older ones that use OSS, still work. I think I'll keep it.
Of course, I'd much rather use a simpler sound stack. Right now, sound
goes from the application through some wrapper library (like libao)
through userland ALSA (maybe) which then routes it to PulseAudio which
finally routes it to kernel ALSA. That's crazy.
I agree with many points made in this blog post, even though it's from
2009:
http://insanecoding.blogspot.de/2009/06/state-of-sound-in-linux-not-so-sorry.html
But then again, I'm tired of manually writing some asoundrc when I can
achieve the same goal using PulseAudio with just a few mouse clicks or
pacmd commands.
