|
|
Subscribe / Log in / New account

with pulse, it's silent; without sound works

with pulse, it's silent; without sound works

Posted Aug 26, 2010 13:02 UTC (Thu) by sebas (guest, #51660)
In reply to: Some questions that do 3d6 fire damage by Los__D
Parent article: Systemd and Fedora 14

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.


to post comments

with pulse, it's silent; without sound works

Posted Aug 26, 2010 13:31 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

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 (guest, #51660) [Link] (1 responses)

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds