If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
So that if your device works, the likelyhood of it working as intended is slim. PA bridges that gap since all it wants is reliable output from ALSA.
How the hell do you figure Pulse makes up for a crappy driver? Pulse still uses the exact same driver that a pure alsa system uses. A crappy driver in a pure alsa system is still going to be a crappy driver with Pulse. You now have just added another complexity of another layer to muddy the waters.
I agree with Kaczu's points. I'm not against "plain" Alsa, but I don't want to give up any of the functionality Pulse provides. It's 2010!
Thanks. I'm not against ALSA either. It's necessary. However, a low level API which ALSA is should not be bloated with features. That's what high level API's are for and that's my guess as to why PA has those features and ALSA doesn't and I don't think it ever will because getting the driver implementation working is a task all to itself without worrying about resampling audio, hardware mixing, or bluetooth headsets.
Also to get back to the main title of this thread, I disagree. For better or worse, we can just expect that Valve will target Ubuntu as the main platform. They won't worry about getting every odd audio setup to work, just the current Ubuntu release. People on other distros will just have to try to get it working themselves, if it doesn't already. If they do decide to support ONLY pulse output over Alsa, they non Pulse users are screwed. That's the cold reality. Hopefully they choose Alsa.
I wasn't going to say it, but that's likely the case. The thing about PA is that Fedora, OpenSuse, Ubuntu, all use it and those are the most popular out there. People who use those distros more or less should be fine.
The second thing is that PA can be turned off at will for things outside of Gstreamer (don't know if that's still the case for 10.04) . For those users who roll their own or have source based distros they can easily turn PA on/off in order for something like Steam. Hell you could create a script that did that if Steam is detected as open. However what is the average user supposed to do if their version of ALSA misdiagrams a user's sound card? Compile the their own? For a game? That's just not reasonable and will do more harm than good.
PulseAudio and Sound in GNOME Applications
KDE installations do not install PulseAudio by default. PulseAudio will be installed automatically if an application, which requires it is installed, but it must still be enabled in YaST to hear sound in these applications. To enable PulseAudio in YaST, open YaST > Sound Module and click 'Other'. Select 'PulseAudio Configuration', then check 'Enable PulseAudio Support'.
Getting rid of it installed by default was one of the most requested features when 11.2 was in development.
How the hell do you figure Pulse makes up for a crappy driver?
Pulse still uses the exact same driver that a pure alsa system uses. A crappy driver in a pure alsa system is still going to be a crappy driver with Pulse. You now have just added another complexity of another layer to muddy the waters.
From what I understand Pulse isn't talking to the driver ALSA is. Let's say ALSA get's the following correct. Front Channel / Master Channel and 1 voice / sample and a max volume gain of +1 and that's it. No hardware mixing of any kind. The fact that ALSA can't do it is irrelevant because Pulse can. The applications are talking to PA's API not ALSA directly. Therefore PA can send 4 samples as opposed to one and send it through as 1 voice with a Gain of +10. Despite what you think PA doesn't just sit there to cause latency it does actually do something.
Will it always work if the ALSA driver implementation is really crappy? No. But overall the outcome should be better if ALSA can get the basics.
You're taking what he's saying out of context. He's not saying to get rid of Pulse. He's describing issues that need to be resolved. However what you cut out is that latency is more related to how timing is implemented not that PA itself is high latency. Actually PA has a low latency mode which can be used to fix many issues which he describes.
How the hell does lessening the buffer fix anything? That's all the "low latency" mode does.
The point was that they all offer it. And as I said the lack of it causes it's own issues. There's enough Intel HDA threads with ALSA that you can send a Mac truck through.
Every linux distro can use it, just because an app is packaged does not mean it is the preferred solution. As far as the HDA threads go, Pulse doesn't cure any of it. If the driver is buggy then Pulse will exhibit the same behavior. Pulse has to go through ALSA. Pulse has no low level interface to the card what so ever.