"another project from a man that tries to solve
problems where there aren't any". This is probably one of the most clueless comments I've read around here. Audio in Linux needed fixing and albeit PulseAudio has had it quirks, it works much better now, and it went a *long* way at improving the ridiculous audio situation we had before.
Posted Aug 26, 2010 7:57 UTC (Thu) by Hknr (guest, #67789)
[Link]
Thank you.
I'll give you an example: I use an external USB-DAC
that directly feeds into my amplifier. With a little
bit of asound.conf tweaking, I get bit-perfect output
from my flac music collection (and even crossfeed support
when I use my headphones).
So why would I want to add a shitlayer on top of that?
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 11:11 UTC (Thu) by Los__D (guest, #15263)
[Link]
Wow... You "only" need to mess with some obscure configuration file to make stuff work! Everything is perfect then!
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 11:26 UTC (Thu) by Hknr (guest, #67789)
[Link]
Messing with configuration files to make stuff work
is exactly the way we like it in Linux land.
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 11:35 UTC (Thu) by rahulsundaram (subscriber, #21946)
[Link]
Speak for yourself. I rather have stuff work without messing around with configuration files in my Linux land. Busy work makes no sense to me.
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 12:52 UTC (Thu) by nicooo (guest, #69134)
[Link]
With alsa you don't need to edit any files for a regular setup. If you want to do something out of the ordinary, using a config file is easier than some complicated gui.
Systemd gets it right by using ini instead of the xml that everything else hosted on freedesktop.org seems to use.
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 12:18 UTC (Thu) by mpr22 (subscriber, #60784)
[Link]
My attitude to hand-editing configuration files is simple:
The system must allow it.
It should almost never be necessary.
The system should provide tools to make most-or-all commonplace configuration actions, and many less commonplace ones, achievable without using a text editor. If using a text editor to configure the system is necessary, at least one of the following statements is true:
The system's users have unusual requirements not easily predicted by the designers of the autoconfiguration mechanisms and "simplified" manual configuration tools.
The system's configuration has a level of essential complexity high enough that a text editor is the only useful way to configure the system at all, or low enough that you can't plausibly get it wrong in a bad way.
The system is broken.
Some questions that do 3d6 fire damage
Posted Aug 27, 2010 1:20 UTC (Fri) by drag (subscriber, #31333)
[Link]
The other main argument is that hardware is now dynamic.
Here is very common hardware:
* USB headphones with microphones
* USB sound card
* Bluetooth heaphones
Notice how they are all dynamic?
So yeah. Alsa, by itself, can work really well if all you want to do is listen to Flac files over a static configuration... but it's shit if you want to do anything more complicated like:
* play more then one sound simultaneously (I'd like to see you program into your asoundrc file a audio mixer that does not suck)
* use your microphone
* use audio input with more then one application
* Use X11 applications over a network that have audio
* use a USB docking station for your laptop
* use your bluetooth headset
* Be able to switch your bluetooth headset between stereo sound and telephone modes
* configure your laptop's audio output (on the fly) between:
- off
- stereo audio with input
- 4 speaker surround sound
- stereo audio with digital output
- digital output with digital input
* Play your game's audio out through the speakers and then chat with people on your usb headset
And a bunch of other crap people using other OSes take for granted but is nearly impossible to do in Linux with any sort of sanity and when it does works it only works in extremely static and carefully maintained configuration.
And, no, switching to OSS is not going to help any since OSS, even in the newest versions, is less capable and more of a pain in the ass to configure then Alsa is... OH it uses software mixing by default, unlike ancient versions of Alsa. One problem solved and sixty thousand more to go.
Some questions that do 3d6 fire damage
Posted Sep 6, 2010 16:41 UTC (Mon) by nye (guest, #51576)
[Link]
I'm sure those things would be lovely, if there was more than 50% chance that the piece of shit would produce any fucking sound at all.
Some questions that do 3d6 fire damage
Posted Sep 6, 2010 17:10 UTC (Mon) by rahulsundaram (subscriber, #21946)
[Link]
I am sure there is 98.7 % chance of sound. Much better than ALSA's 76.5% :-)
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 21:20 UTC (Thu) by nix (subscriber, #2304)
[Link]
And just how much documentation is there for asound.conf? Sod all useful that I can find, that's how much. There's even a Lisp interpreter in there somewhere, although I'm not sure where. I suspect I'll have to grovel through the source code to figure out the syntax, and life is just too damn short.
I googled for a stanza to force everything through PulseAudio (first hit: pulseaudio.org's Perfect Setup page) and left it at that.
Some questions that do 3d6 fire damage
Posted Aug 26, 2010 21:39 UTC (Thu) by sfeam (subscriber, #2841)
[Link]
And on that Perfect Setup page you will find the following advice:
KDE 4 uses Phonon as the main audio interface. The Xine backend of Phonon should eventually use PulseAudio automatically, but at the time of writing the pulse plugin for Xine is too unreliable, so it's disabled by default. While waiting for that to get better, Phonon uses Alsa. Therefore, to get Phonon to use PulseAudio, you have to edit your ~/.asoundrc or /etc/asound.conf. However, the normal .asoundrc modifications aren't enough. See #232 (specifically the workaround part).
New progress is being made with KDE 4 and Phonon all the time. Please refer to the KDE wiki page for further information and setup instuctions.
... which matches my experience. Getting PA to work with KDE4 is somewhere on the spectrum from painful to impossible. And it doesn't get you away from dealing with the ALSA configuration.
with pulse, it's silent; without sound works
Posted Aug 26, 2010 13:02 UTC (Thu) by sebas (subscriber, #51660)
[Link]
That is to say that even after a couple of months of fiddling with all kinds of configuration options and pulseaudio stuff, my sound was still hit and miss.
I much prefer spending a couple of minutes fixing an ALSA setup than
Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*.
Lennart's answer, when I inquired personally at a conference, was it's the buggy driver's business. The hardware in question was intel's HDA sound chip, likely the most common piece of sound hardware found in today's laptops.
My experience is as simple as: Without pulse it works, with pulse it doesn't. As much as the previous comments sound like flaming, they do match my experience.
If that's any indication of how problems with systemd are being dealt with, I'll rather not install it.
with pulse, it's silent; without sound works
Posted Aug 26, 2010 13:31 UTC (Thu) by mjg59 (subscriber, #23239)
[Link]
That it's an Intel HDA tells you nothing - the HDA spec is pretty much just a semi-defined bit of glue in front of a codec, and there's literally dozens of different codecs. Some of these are more spec-compliant than others and it's not uncommon for them to require chip-specific quirks. See source/pci/hda to get some idea of just how much complexity there is in what looks like a single chip.
with pulse, it's silent; without sound works
Posted Aug 26, 2010 14:00 UTC (Thu) by sebas (subscriber, #51660)
[Link]
Ow, I'm convinced it's rather more complex than I am able to understand -- but that probably goes for the vast majority of the users. The gist is that without pulse it works, and with it, it simply doesn't. And that's also what the user will experience -- a very poor multimedia experience.
with pulse, it's silent; without sound works
Posted Aug 26, 2010 14:29 UTC (Thu) by mjg59 (subscriber, #23239)
[Link]
When you say "The user", you mean "A user with this specific codec". The majority of hda codecs work absolutely perfectly with pulse at this point, and it's usually not too difficult to fix the others. But the fact remains that this is the kernel failing to compensate for broken hardware, and while it may be reasonable to use this as a reason to say that Pulse shouldn't be the default it's unfair to blame the problem on Pulse itself.
with pulse, it's silent; without sound works
Posted Aug 27, 2010 17:12 UTC (Fri) by Trelane (subscriber, #56877)
[Link]
It should perhaps also be mentioned that "codec" is a specific bit of jargon specific to the HDA spec (available on the intarwebs; this is how I know about these things, although it's been a while and I'd greatly appreciate supplements/corrections where appropriate).
The HDA spec has a tree structure, and one of the nodes is a "codec," referring to a virtualized interface to a block that Does Stuff. This is used to interesting effect with the sound card discussed at http://blogs.amd.com/home/2009/06/16/turning-it-up-to-11/, where the HDA protocol itself is used as a transport/formalization of a higher-level protocol used to drive a particularly novel consumer-level sound card.
IIRC. It's been a bit since I read the specs on this card and therefore also the HDA specs to understand Intel HDA as it was being used here. (Sadly, I never got enough hand-holding to get a driver up and running on ALSA and perhaps also lacked the motivation, not actually having hardware to play/test with.)
with pulse, it's silent; without sound works
Posted Aug 27, 2010 9:46 UTC (Fri) by buchanmilne (guest, #42315)
[Link]
Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*.
So, now you aren't sure if it is different (newer/older) snd_hda_intel drivers, or PA.
On a distribution (Mandriva) which defaulted to PA, but allows very easy switching to straight ALSA, I found (about a year ago) by switching to ALSA that the problems I had with sound input on my laptop were not due to PA but the snd_hda_intel driver needing some tweaks for my hardware (in 2.6.27). Some point releases of 2.6.27 fixed and subsequently broke it again. In more recent kernels (2.6.31 and later) I haven't had these problems (although the mic did sometimes stop working after suspend, unloading and reloading snd_hda_intel fixed it - but I haven't seen this problem on 2.6.33 or later). Immediately after having isolated the problem as being the driver, I switched back to PA, and really don't have any issues (on 4 machines, including my media player which has 5.1 via SPDIF enabled from the XBMC settings).
My experience is as simple as: Without pulse it works, with pulse it doesn't
No, technically, your experience was "On one distro it didn't work, on the other it did, the one where it didn't work used PA, the one where it worked didn't", with undefined definitions of "it" and "work", and no clear identification of the cause besides association.