Re: [arch-general] PulseAudio in [testing]
I believe this was the right choice. Pulseaudio should be in extra and all applications build with pulse support. Regarding phonon, i believe KDE intends to drop it at some point, not sure were i read that. I remember reading something about KDE 5 not including phonon, but it may be FUD. Anyone more informed on the issue? In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to target for all apps. The kind of functionality it provides it is needed if modern distros are to compete with Windows 7. Windows 7 now provide the functionality to switch sound cards on the fly without restaring the app playing sound. This is possible only with Pulseaudio as far as i can tell in the Linux world. And this is just one example. Imagine if you have a headset with included sound card, for example a 5.1 headset. Without Pulseaudio, it is a chore to switch sound to it, with Pulseaudio it is easy and userfriendly. Windows 7 now can do it too. Imagine if a user tries to do it in Linux without pulse, he will be frustrated. Of course, Arch users should be knowledgable enough to switch sound cards in ALSA, but it still is a chore. And it is not the point. The point is, Linux needs a sound daemon to provide modern user friendliness. So it is a matter of time for GNOME and KDE to support it natively. KDE tried it with phonon, but it seems phonon is more problematic than pulseaudio, with less features. At least for me, when phonon sits on top of ALSA, i get all sorts of messages informing me that some interface should be disabled, it is annoying. Plus when i change a sound card, the app needs restarting. So yes, in time pulseaudio should become the default linux api for Linux/GNU, if not already. If there are bugs, they could be solved if all those geniuses bitching about it and use ALSA could be bothered to help a little.
On Sun, 2010-11-28 at 12:11 +0200, Χρήστος Κώτσαρης wrote:
I believe this was the right choice. Pulseaudio should be in extra and all applications build with pulse support.
Except for the fact that Pulse Audio is an incredible REGRESSION in Linux sound and causes far more problems than it solves. Do a google search on it sometime, you'd be surprised what a huge headache Pulse Audio actually is.
Regarding phonon, i believe KDE intends to drop it at some point, not sure were i read that. I remember reading something about KDE 5 not including phonon, but it may be FUD. Anyone more informed on the issue?
KDE has no intention of dropping Phonon. Largely because they just implemented it as new in KDE 4. And they wouldn't drop it in favor of something as low quality and unstable as Pulse Audio. GNOME might, but their developers are idiots.
In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to target for all apps. The kind of functionality it provides it is needed if modern distros are to compete with Windows 7. Windows 7 now provide the functionality to switch sound cards on the fly without restaring the app playing sound. This is possible only with Pulseaudio as far as i can tell in the Linux world. And this is just one example.
Linux has no need for Pulse. ALSA works perfectly fine. Pulse is a regression in Linux sound. If you think PA will catch Linux up to Windows 7 (It should be noted Linux is way ahead of Windows 7 in all the ways that actually count.), you're going to get a painful bite of reality when countless Windows 7 users correctly point ou ttheir sound Just Works where Linux USED TO before Pulse Audio came around and broke absolutely everything. Besides, both KDE and GNOME already provide user-friendly audio utilities that are easier to handle with Pulse Audio and, here's the killer feature, don't break sound AT ALL.
Imagine if you have a headset with included sound card, for example a 5.1 headset. Without Pulseaudio, it is a chore to switch sound to it, with Pulseaudio it is easy and userfriendly. Windows 7 now can do it too. Imagine if a user tries to do it in Linux without pulse, he will be frustrated. Of course, Arch users should be knowledgable enough to switch sound cards in ALSA, but it still is a chore. And it is not the point.
Actually, ALSA has a pretty simple and easy means to switch to USB audio devices. The Arch wiki even says so. Pulse might provide an easy way to switch to it, but it's completely outweighed by the fact that there's a 70% chance Pulse Audio will break most (If not all.) your sound.
The point is, Linux needs a sound daemon to provide modern user friendliness. So it is a matter of time for GNOME and KDE to support it natively. KDE tried it with phonon, but it seems phonon is more problematic than pulseaudio, with less features. At least for me, when phonon sits on top of ALSA, i get all sorts of messages informing me that some interface should be disabled, it is annoying. Plus when i change a sound card, the app needs restarting.
Phonon is far less problematic than PA. HAving actually used both extensively. Largely because Phonon doesn't hijack ALL sound on the system it runs on like Pulse Audio, so that even if Phonon breaks (Has yet to happen with me.) you can STILL use SOME sound, whereas in the inevitable eventuality Pulse Audio breaks, ALL your sound goes with it, even if you manage to kill it, because it took it on itself to take all your sound over, which no other sound daemon does, and for damn good reason.
So yes, in time pulseaudio should become the default linux api for Linux/GNU, if not already. If there are bugs, they could be solved if all those geniuses bitching about it and use ALSA could be bothered to help a little.
First off, Pulse Audio is not a sound API like ALSA or OSS, it's a Daemon, and a very crappy one at that. In fact, it's a crappy sound daemon that breaks sound that it and its developers somehow convinced themselves was a legit sound API akin to ALSA and OSS. Second off, no, it should NOT become a universal default for Linux because its a horrendous regression running on top of ALSA. Even the Linux kernel developers themselves have said so, even the ALSA developer suggested rewriting ALSA would be a far better alternative to Pulse Audio. Finally, the problems introduced in Pulse audio are NOT the fault of ALSA, drivers, OR distributions no matter how much PA's upstream loves to clamor for it to be true. The sad cold fact is Pulse Audio is buggy, unstable, unnecessary, slow, bloated, and causes WAY more problems than it solves. In fact, there's no problems actually PRESENT in ALSA Pulse is actually solving. Before Pulse came along, ALSA was doing very well. If you were to ask the opinion of myself and my colleagues, I'd recommend abandoning to idiotic sound daemon idea altogether and instead use or create an audio abstraction library akin to libao. That would allow user-friendly interfaces to sound without resorting to crappy daemons like Pulse Audio. Plus it'd be easier on resources and allow cross-platform audio development to be a lot easier. Two things even the "magical" Pulse Audio will never deliver. If you don't like how ALSA handles things, switch to OSS, instead of adding ANOTHER high-latency abstraction on top of it that solves nothing and breaks everything. Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.
On 29 November 2010 00:08, Yaro Kasear <yaro@marupa.net> wrote:
Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.
Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.
On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:
On 29 November 2010 00:08, Yaro Kasear <yaro@marupa.net> wrote:
Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.
Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.
What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.
On 11/28/2010 06:18 PM, Yaro Kasear wrote:
On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:
On 29 November 2010 00:08, Yaro Kasear<yaro@marupa.net> wrote:
Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.
Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.
What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.
dear Mr Yaro. I suggest to read again the first message from the list. It doesn't ask for opinions about pulse on how good or bad is. Keep your opinions for yourself. You are not forced to use pulse if you hate it, pulseaudio is optionally unless you are using gnome. Starting GNOME 3, we will include support by default. This it happened some time ago upstream but WE keep it out, until now. PLEASE, but PLEASE keep your junks out on my inbox -- Ionuț
On Sun, 2010-11-28 at 10:18 -0600, Yaro Kasear wrote:
On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:
On 29 November 2010 00:08, Yaro Kasear <yaro@marupa.net> wrote:
Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.
Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.
What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.
Gnome. But as you've already stated yourself, their devs are idiots. Since you obviously use KDE, as all other enlightened souls do. I'm unsure on why you're directing such vitriolic hate on pulseaudio. 70% sound system breakage? Regression which causes more problems than it solves? Perhaps you should specify[1] what you're talking about rather than generalizing. That is, if you're interested in being taken seriously. Split this off, its just noise to most, so I think many would just want to mute this new thread. [1] - note, a 'google about pulseaudio problems' doesn't count as specifying. Googling 'linux problems' gives far more, but we don't take that seriously, do we? Or 'KDE problems', or 'some-piece-of-software problems'
On Mon, 2010-11-29 at 00:27 +0800, Ng Oon-Ee wrote:
On Sun, 2010-11-28 at 10:18 -0600, Yaro Kasear wrote:
On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:
On 29 November 2010 00:08, Yaro Kasear <yaro@marupa.net> wrote:
Once again, I say PA is far from the kind of quality I'd expect from a package in [extra], and I'm surprised the Arch devs are even considering it, especially in light of the fact that there's far more stable and useful packages in [community] getting passed up.
Once again, nobody asked for opinions on PulseAudio, the software. If it does affect you directly, do report that here or the bugtracker. It was moved to [extra] for package-specific reasons, not just on a whim as you would like to think.
What packages actually REQUIRE Pulse Audio? I don't know of a single Linux app to date that actually NEEDS it over what already exists in ALSA itself.
Gnome. But as you've already stated yourself, their devs are idiots. Since you obviously use KDE, as all other enlightened souls do.
I'm unsure on why you're directing such vitriolic hate on pulseaudio. 70% sound system breakage? Regression which causes more problems than it solves? Perhaps you should specify[1] what you're talking about rather than generalizing. That is, if you're interested in being taken seriously.
Split this off, its just noise to most, so I think many would just want to mute this new thread.
[1] - note, a 'google about pulseaudio problems' doesn't count as specifying. Googling 'linux problems' gives far more, but we don't take that seriously, do we? Or 'KDE problems', or 'some-piece-of-software problems'
GNOME 3 isn't even released yet. There's no CURRENT dependency in Arch, in [extra], for Pulse Audio. Fine, Then I'll list all of its problems right here: - It's unstable. - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software. - It wastes a lot of RAM. - It wastes a lot of CPU. - It causes noticeable audio latency. - It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon. - It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong. - It's not really necessary for any actual Linux audio needs, where things like ESD and Phonon had already fixed the problems Pulse Audio has no use for. - Even the Pulse Audio devs at one point admitted it breaks Linux audio. - A great deal of Linux applications have problems working with it, far more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done. - An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use themselves. Never count on networking where an actual local system will do.) that Pulse Audio fans never use bt love to brag about so they can distract from Pulse Audio's obvious problems, just like you are doing right now. - Much, much more, but you get my point. Maybe wait until GNOME 3 actually gets released before put something unstable and useless in [extra] needlessly.
On 11/28/2010 06:38 PM, Yaro Kasear wrote:
Maybe wait until GNOME 3 actually gets released before put something unstable and useless in [extra] needlessly.
our experience in packaging software, fixing bugs and debugging is far superior than yours. we have just made a small step in adding default support in gnome, instead of doing everything when gnome 3 is released. In this way we can ensure that everything works before pushing this permanently. Just understand, Pulseaudio is optionally -- Ionuț
On Sun, 2010-11-28 at 18:44 +0200, Ionuț Bîru wrote:
On 11/28/2010 06:38 PM, Yaro Kasear wrote:
Maybe wait until GNOME 3 actually gets released before put something unstable and useless in [extra] needlessly.
our experience in packaging software, fixing bugs and debugging is far superior than yours.
we have just made a small step in adding default support in gnome, instead of doing everything when gnome 3 is released.
In this way we can ensure that everything works before pushing this permanently.
Just understand, Pulseaudio is optionally
I do. Most my response is to the people who think Pulse Audio is the end-all Audio solution when it's far from actually being so (With the fact it's clearly not stable or mature enough for [extra] as part of this.). The opinion it should be a default for Arch, for example, or that it should be the standard for Linux are idiotic, since, as I stated many times before, Pulse Audio is crap that solves nothing and breaks everything. I'll stop posting on this topic now.
Let me answer on your points...
Fine, Then I'll list all of its problems right here:
- It's unstable. NEVER crashed on me... - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software. Possible, tho i did not experience any... - It wastes a lot of RAM. never see it in top. - It wastes a lot of CPU. see above. In fact it uses LESS cpu then pure alsa does here, since alsa is resampling everything, altho my card can natively play all samplerates. Pulse behaves correctly here and simply routes it forward. - It causes noticeable audio latency. You cant be serious? i have been using pulse audio over network from one room to the next. It synced audio with my movies 100% even over a slow wifi network. This would never work with high latency audio backends... - It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon. - It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong. I am actually not too sure about this one, since upstream alsa DOES have a lot of bugs that never get fixed. - It's not really necessary for any actual Linux audio needs, where things like ESD and Phonon had already fixed the problems Pulse Audio has no use for. Phonon has solved what exactly? Its totally useless overhead with not a single complete backend. Every single backend is missing features the other one has. - Even the Pulse Audio devs at one point admitted it breaks Linux audio. - A great deal of Linux applications have problems working with it, far You can simply forward alsa AS IS to pulseaudio - this should work for about any software you can think about. Btw: skype works much better with pulse than with alsa. i know, bad example, but still. more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done. actually it is. mplayer, mpd, clementine <insert some audio software here>, all have native pulse audio backends. And those are normally used by people with small WMs, not gnome users. - An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use See above. I know several people (also on arch) that use pulse audio with mpd, since its the easiest way to control mpd remotely AND have sound locally.
Let me answer on your points...
Fine, Then I'll list all of its problems right here:
- It's unstable. NEVER crashed on me... From the PA page: "Current Status The PulseAudio daemon and utilities are still under heavy development. Although they are generally considered stable, they haven't seen enough testing to warrant a first completely stable release." - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software. Possible, tho i did not experience any... - It wastes a lot of RAM. never see it in top. It shouldn't, PA is also to a large degree developed for mobile phones. - It wastes a lot of CPU. see above. In fact it uses LESS cpu then pure alsa does here, since alsa is resampling everything, altho my card can natively play all samplerates. Pulse behaves correctly here and simply routes it forward. I'm rather sure PA resamples everything and with alsa it depends on the configuration. They might use different algorithms by default. - It causes noticeable audio latency. You cant be serious? i have been using pulse audio over network from one room to the next. It synced audio with my movies 100% even over a slow wifi network. This would never work with high latency audio backends... Low-latency is no goal of PA, its latency might change at any time or all the time, it simply doesn't matter for the use cases it is designed for. - It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon. - It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong. I am actually not too sure about this one, since upstream alsa DOES have a lot of bugs that never get fixed. - It's not really necessary for any actual Linux audio needs, where things like ESD and Phonon had already fixed the problems Pulse Audio has no use for. Phonon has solved what exactly? Its totally useless overhead with not a single complete backend. Every single backend is missing features the other one has. - Even the Pulse Audio devs at one point admitted it breaks Linux audio. - A great deal of Linux applications have problems working with it, far You can simply forward alsa AS IS to pulseaudio - this should work for about any software you can think about. Btw: skype works much better with pulse than with alsa. i know, bad example, but still. It should, but apparently doesn't. From what I read in this thread xine and apparently also mplayer (an mplayer update tries to pull libpulse) are fine examples. This probably is due to incomplete 'libalsa pulse',
more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done. actually it is. mplayer, mpd, clementine <insert some audio software here>, all have native pulse audio backends. And those are normally used by people with small WMs, not gnome users. Not long ago Lennart urged developers not to use the PA API. That may have changed now, but I guess this is because people didn't listen and he was under pressure not to change the API. Anyway, if PA really worked
Excerpts from Rasmus Steinke's message of 2010-11-28 18:00:52 +0100: the part of PA that is supposed to imitate the alsa. that well and could emulate alsa and everything else as it should then why would the PA API be used at all? One PA to rule them all, One PA to find them, One PA to bring them all and in the darkness bind them
- An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use See above. I know several people (also on arch) that use pulse audio with mpd, since its the easiest way to control mpd remotely AND have sound locally.
On Sun, 2010-11-28 at 10:38 -0600, Yaro Kasear wrote:
On Mon, 2010-11-29 at 00:27 +0800, Ng Oon-Ee wrote:
GNOME 3 isn't even released yet. There's no CURRENT dependency in Arch, in [extra], for Pulse Audio.
Others have explained this to you already.
Fine, Then I'll list all of its problems right here:
- It's unstable. - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software.
Where you've mentioned specific bugs below I'll answer. Otherwise this is just FUD generalization. And pulseaudio is not unstable just because an implementation in ANOTHER distro YEARS ago caused some problems.
- It wastes a lot of RAM. - It wastes a lot of CPU. - It causes noticeable audio latency.
RAM and CPU usage never appear on top 5 on my system. Its at 2% of CPU and 0.3% of RAM (4 GB) here on top. And synchronization of movie audio is perfect here (even when outputting at the same time to multiple sound cards, including a BT headset, try that with alsa)
- It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon.
nedko (jack2) and the Pulseaudio devs specifically worked on such support. Just because you are ignorant of it does not make it not exist. As correctly pointed out though, jack2 is a separate implementation of jack from jack1, jack1 does not support notifying pulseaudio about its 'claim' on the soundcard. There's 2 players here, not just one.
- It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong.
The ONLY major ALSA 'feature' which is not supported is memmap. Direct access to the sound-card's memory. Pulseaudio's devs are of the opinion that this cannot and should not be emulated, and that apps which use it are broken in design. I've not come across any latest-version-apps where this is still a problem, do you know of any?
- It's not really necessary for any actual Linux audio needs, where things like ESD and Phonon had already fixed the problems Pulse Audio has no use for.
Necessity is a weird thing that seems to you to imply "what I need". Sorry, you're not Linux Audio. Even a cursory glance through this thread should indicate to you that there ARE people who need it for something or other. Not 'just' networked audio as you imply. Routing between multiple sound cards, good and automatic BT headset support, per-volume app control. Yep, ESD and phonon have all that.
- Even the Pulse Audio devs at one point admitted it breaks Linux audio.
Context, please. Quotation if possible. The only similar statement I remember is Lennart saying (more than a year ago) that it would break audio apps which rely on alsa hacks (most apps AT THE TIME). Which would mean that these apps need fixing. If you think 'oh, what works before must be great code', I'm sure you'd be one of the first to protest (for example) Wayland on the grounds that X11 works just fine.
- A great deal of Linux applications have problems working with it, far more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done.
See above. You do not understand what is being done, nor have you made an attempt to. Pick up the latest Ubuntu liveCD, run it on almost any system you want. Sound will 'just work (tm)'. And they get all those nice features which they can CHOOSE to use or not. Your complaining is 2 years too late, because linux apps NOW support pulseaudio just fine. mplayer, vlc, mpd, wine, sdl, gstreamer et. al. The only sort of apps which still don't have good PA support are audio editing apps which are more meant for use with Jack (ardour and audacity for example).
- An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use themselves. Never count on networking where an actual local system will do.) that Pulse Audio fans never use bt love to brag about so they can distract from Pulse Audio's obvious problems, just like you are doing right now.
Yes, you don't use a feature so its utterly useless. Good point! And its not like that's the ONLY feature available to pulseaudio.
- Much, much more, but you get my point.
Maybe wait until GNOME 3 actually gets released before put something unstable and useless in [extra] needlessly.
Obviously you have not been keeping track of how Arch handles this. If something is coming, the devs make a collective decision to incorporate it as soon as possible without breaking things. See python3. Pulseaudio has already been delayed much longer than anything else, partially because of FUD from folks like yourself. The other reason as I understand is that JGC is simply too overworked with his thousands of packages to bother prior to this to figure out how to integrate pulseaudio PROPERLY. Which he has now done, and in a way such that without his announcement email you would not have noticed it at all. Since you're basing complaints on past problems and not any CURRENT problem with your Arch system.
On Mon, Nov 29, 2010 at 07:28:45AM +0800, Ng Oon-Ee wrote:
The ONLY major ALSA 'feature' which is not supported is memmap. Direct access to the sound-card's memory. Pulseaudio's devs are of the opinion that this cannot and should not be emulated, and that apps which use it are broken in design. I've not come across any latest-version-apps where this is still a problem, do you know of any?
While I would agree with anything else you wrote, if the comment quoted above refers to ALSA's mmap access mode it is wrong. All this mode has to do is provide the client application with pointers to read/write a period of samples from/to. The memory pointed to _may_ be directly mapped to a HW buffer, but there is nothing in the API that requires this - it could just be a user space memory buffer. ALSA itself provides mmap access to e.g. USB audio devices, this most certainly does not provide pointers to any USB hardware. Mmap mode can be emulated quite easily on top of another access mode (although it usually makes more sense to do things the other way round). There is nothing wrong with apps using this mode, and in fact many do, including Jack. Given that any driver will have either access to real HW buffers, or will create its own ones in memory, it's in fact the simplest and most direct way to get to the audio data. Ciao, -- FA There are three of them, and Alleline.
On Mon, 2010-11-29 at 01:10 +0100, fons@kokkinizita.net wrote:
On Mon, Nov 29, 2010 at 07:28:45AM +0800, Ng Oon-Ee wrote:
The ONLY major ALSA 'feature' which is not supported is memmap. Direct access to the sound-card's memory. Pulseaudio's devs are of the opinion that this cannot and should not be emulated, and that apps which use it are broken in design. I've not come across any latest-version-apps where this is still a problem, do you know of any?
While I would agree with anything else you wrote, if the comment quoted above refers to ALSA's mmap access mode it is wrong.
All this mode has to do is provide the client application with pointers to read/write a period of samples from/to. The memory pointed to _may_ be directly mapped to a HW buffer, but there is nothing in the API that requires this - it could just be a user space memory buffer. ALSA itself provides mmap access to e.g. USB audio devices, this most certainly does not provide pointers to any USB hardware.
Mmap mode can be emulated quite easily on top of another access mode (although it usually makes more sense to do things the other way round).
There is nothing wrong with apps using this mode, and in fact many do, including Jack. Given that any driver will have either access to real HW buffers, or will create its own ones in memory, it's in fact the simplest and most direct way to get to the audio data.
Ciao,
Thanks fons, I was under the mmap alsa capability implied direct control over the hardware's memory.
On Mon, Nov 29, 2010 at 10:31:06AM +0800, Ng Oon-Ee wrote:
Thanks fons, I was under the mmap alsa capability implied direct control over the hardware's memory.
It probably does in some cases (e.g. a hw: device on a PCI bus), but only to the sample data - there's no direct access to any control registers ever in ALSA. Since the access _could_ be to real HW it's of course ALSA that dictates the layout (separate buffers for each channel, or interleaved, or even more complex schemes) and the sample format (16/24/32 bit or float, LE or BE). The client application just has to accept this and do any conversions itself. Maybe the PA devs were thinking they had to emulate all of those, which could be a nightmare but is not necessary. They could just select the format that corresponds to any buffers they already have, and only support that one. Clients using mmap mode check what is available and adapt to it. Ciao, -- FA There are three of them, and Alleline.
Just to clarify a few things... 1) If you only install libpulse, you are not not using pulseaudio. It is just another "useless" library on your system. You already probably have plenty of libraries installed on your system that you do not use. If you really do not want it installed, rebuild the relevant package using ABS. But given that with its dependencies it takes up a total of 1.17MB on my system it seems an utter waste of time... If you want your system that clean of unused libraries, look at Gentoo and USE flags. 2) You are not being forced to use pulseaudio. The next GNOME release will be using pulseaudio by default. That is a decision from the GNOME developers which we have held off implementing for a couple of releases, but Arch follows the upstream developers decisions. If you do not want pulseaudio, pick a better desktop such as XFCE! You are not being forced to use GNOME or pulseaudio. 3) Any package that does force you to use pulseaudio (beyond installing libpulse) is probably a bug. All packages so far have been built with optional pulseaudio support. File bug reports. 4) If you _choose_ to use pulseaudio and run into issues, file a bug report. We have a fairly vanilla setup, so you can go directly upstream with your issue or go via our bug tracker if you think the issue may be Arch specific. Non-specific complaints about bugs get everyone nowhere. Bug reports FTW. Regarding #3 and #4, I see maybe one bug report in our tracker about breakages in pulse and the packages built against it in our tracker. So I guess congratulations to the developers dealing with this upgrade for what appears a relatively seemless transition because no-one is having actual issues... Which leads me to (rhetorically) query why this thread is so long and filled with "facts" about pulse being broken? Allan
On Mon, 29 Nov 2010 07:28:45 +0800 Ng Oon-Ee <ngoonee@gmail.com> wrote:
- It's unstable. - It's got far too many unresolved bugs the upstream developers defer INCORRECTLY elsewhere simply because they can't be bothered to fix their software.
Where you've mentioned specific bugs below I'll answer. Otherwise this is just FUD generalization. And pulseaudio is not unstable just because an implementation in ANOTHER distro YEARS ago caused some problems.
What Yaro said was not a generalization, or even FUD. It was intended to be a statement of opinion, based on scientific theory of "If A works, and B doesn't, B must have problems" Plus, look at all the Ubuntu and RedHat folks who ask "How, How do I remove this beast of a pile from my system?"
- It wastes a lot of RAM. - It wastes a lot of CPU. - It causes noticeable audio latency.
RAM and CPU usage never appear on top 5 on my system. Its at 2% of CPU and 0.3% of RAM (4 GB) here on top. And synchronization of movie audio is perfect here (even when outputting at the same time to multiple sound cards, including a BT headset, try that with alsa)
Yeah, you aren't running on REALLY low end hardware. Try my box: a 700Mhz P3 Coppermine chip with 240MB of RAM open to the kernel. PA is a pile on that machine, and doesn't understand the ESS Maestro3i chip that's in it. ALSA when run through alsaconf... DOES! Start using REALLY low-end hardware and stop using flat top. As for multiple sound cards? Not a problem. I consistantly go between a USB headset and a full speaker system. How? Oh i don't know, by telling the app I want to talk to to talk to hw:1,0 instead of hw:0,0? Something like that. ALSA is a magificent Pile of steaming shit. Its just not as gold-covered as PA.
- It DOES NOT release sound to other daemons as your erroneously claim. It will not turn itself off for JACK just as it won't turn itself off for ESD or Phonon.
nedko (jack2) and the Pulseaudio devs specifically worked on such support. Just because you are ignorant of it does not make it not exist. As correctly pointed out though, jack2 is a separate implementation of jack from jack1, jack1 does not support notifying pulseaudio about its 'claim' on the soundcard. There's 2 players here, not just one.
That's a deeper, fundamental problem with the sound on Linux. Five different daemons do NOT need to be implemented just to do SOUND anymore. I think that's what Yaro is trying to get at.
- It actually doesn't support ALSA that well, it's ALSA module is stuck at 70% completion, with a lot of critical ALSA support stuck on that missing 30%. Again, further upstream blame gets laid on ALSA or drivers where it doesn't belong.
The ONLY major ALSA 'feature' which is not supported is memmap. Direct access to the sound-card's memory. Pulseaudio's devs are of the opinion that this cannot and should not be emulated, and that apps which use it are broken in design. I've not come across any latest-version-apps where this is still a problem, do you know of any?
You're going to go rally hardware vendors, right? What about my ESS Maestro3i? *the damn thing needs firmware* and its a *right bitch* to get working. Oh and did I mention on my other box the Realtek chipset needs to be told what it can output "Front" to? THis is a non-issue when it comes to comparing PA to ALSA. Blame vendors for being total shitheads. until then, there's a quite nice reason to emulate some hardware memmapping. As for apps that need it, I know a few. Quake, as well as some virtualization systems, really like having it because it makes their life Easier. SDLQuake relies on ALSA to do this, as well, and uses quite a bit of hardware memory because its CHEAPER. And ALSA has way more features not supported, for example this magical idea of "switches" -- You know, those things that fiddle bits in some keep-alive packet to the hardware that say "I want this to be like this". yes, I have to use switches.
- Even the Pulse Audio devs at one point admitted it breaks Linux audio.
Context, please. Quotation if possible. The only similar statement I remember is Lennart saying (more than a year ago) that it would break audio apps which rely on alsa hacks (most apps AT THE TIME). Which would mean that these apps need fixing.
You don't read through RH's bugtracker for PA do you?
If you think 'oh, what works before must be great code', I'm sure you'd be one of the first to protest (for example) Wayland on the grounds that X11 works just fine.
I'll protest Wayland because its Yet Another Thing To Change The World Coming Out Of RedHat. Oh, and that my computers don't all have full 3D glx acceleration. Really! they don't.
- A great deal of Linux applications have problems working with it, far more than any other daemon to date. Upstream, rather than making Pulse Audio abstract itself like ESD or Phonon does, seems to want app developers to write their code SPECIFICALLY for Pulse Audio, which is NOT how its done.
See above. You do not understand what is being done, nor have you made an attempt to. Pick up the latest Ubuntu liveCD, run it on almost any system you want. Sound will 'just work (tm)'. And they get all those nice features which they can CHOOSE to use or not. Your complaining is 2 years too late, because linux apps NOW support pulseaudio just fine. mplayer, vlc, mpd, wine, sdl, gstreamer et. al. The only sort of apps which still don't have good PA support are audio editing apps which are more meant for use with Jack (ardour and audacity for example).
Actually... the latest ubuntu (10.10) segfaults on 3 of my boxes. I haven't used Ubuntu since a futex() bug that they introduced would cause random lockups during Mutex interactions in single-threaded applications. Yes there's a case where you want to use a mutex in a single threaded application, primarily if you're using shared memory. I try playing Quake(2) on PA and I get laggy audio, poor performance (it brings my load up past 10!) and generally REALLY BAD results. PA brings when IDLING my load up to at least 2-3 when I'm on a P3 700Mhz coppermine chip. As someone who regularly calls most of the linux community the "Linux Children", I feel that its appropriate now. With each new Big Thing, its assumed you're using the best damn computer on the face of the planet. When FreeSWAN was doing its development, you know how they found memory leaks? they loaded it on a 200Mhz box with 8MB of ram. Memory leaks of BYTES each were found. As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
- An incredible array of utterly useless features (Like networking sound in a day and age where all PCs have sound systems they can use themselves. Never count on networking where an actual local system will do.) that Pulse Audio fans never use bt love to brag about so they can distract from Pulse Audio's obvious problems, just like you are doing right now.
Yes, you don't use a feature so its utterly useless. Good point! And its not like that's the ONLY feature available to pulseaudio.
Honestly, I think what he was trying to get at is there are much more UNIX-flavored ways to do this. ALSA, OSS, even at one point (And I know I'll get criticism for this) yiff-server[0] get this right. [0] http://packages.debian.org/source/squeeze/yiff -- Morgan Gangwere <0.fractalus@gmail.com> PUNY DISCLAIMER: I'm my own person. I make misteaks. Please, remember this. Debian to Arch convert. indrora on IRC.
Morgan Gangwere wrote:
As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem... Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On 29.11.2010 23:25, "Jérôme M. Berger" wrote:
Morgan Gangwere wrote:
As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
Jerome
did you try manual driver loading? in /etc/pulse/default.pa: ### Load audio drivers statically (it's probably better to not load ### these drivers manually, but instead use module-hal-detect -- ### see below -- for doing this automatically) load-module module-alsa-sink load-module module-alsa-source device=hw:1,0 #load-module module-oss device="/dev/dsp" sink_name=output source_name=input #load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=input #load-module module-null-sink #load-module module-pipe-sink ### Automatically load driver modules depending on the hardware available #.ifexists module-udev-detect.so #load-module module-udev-detect #.else ### Alternatively use the static hardware detection module (for systems that ### lack udev support) #load-module module-detect #.endif
Ulf Winkelvos wrote:
On 29.11.2010 23:25, "Jérôme M. Berger" wrote:
Morgan Gangwere wrote:
As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
Jerome
did you try manual driver loading? in /etc/pulse/default.pa:
Yes, that doesn't work. I don't remember the command, but there is a way to list all the sinks recognized by PA. Manual loading only works to select amongst the recognized sinks. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
2010/11/29 "Jérôme M. Berger" <jeberger@free.fr>:
Morgan Gangwere wrote:
As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
So most likely the driver needs to be fixed instead.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
You could perhaps file a bug with PA. Or find help on the PA mailinglist. Cheers, Sander
On Mon, Nov 29, 2010 at 4:23 PM, Sander Jansen <s.jansen@gmail.com> wrote:
So most likely the driver needs to be fixed instead.
its not even that -- realtek's driver for it is patched against some godforsakenly old version of ALSA.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
You could perhaps file a bug with PA. Or find help on the PA mailinglist.
You'll get "Its ALSA's fault, not ours". Shall I tinge your rose-tinted glasses anymore? -- Morgan gangwere あなたのお母さんは、ハムスターとあなたの父エルダーベリーのワカサギでした - A frenchman.
On Tue, Nov 30, 2010 at 11:03 AM, Morgan Gangwere <0.fractalus@gmail.com> wrote:
On Mon, Nov 29, 2010 at 4:23 PM, Sander Jansen <s.jansen@gmail.com> wrote:
So most likely the driver needs to be fixed instead.
its not even that -- realtek's driver for it is patched against some godforsakenly old version of ALSA.
So the driver is fixed, but not for the current alsa version? Seems like a ALSA problem to me.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
You could perhaps file a bug with PA. Or find help on the PA mailinglist.
You'll get "Its ALSA's fault, not ours".
File a bug with ALSA (or find help on the ALSA mailinglist) then, so the driver works correctly pulseaudio. You act as if they're lying to you and they just want to blame ALSA for all their problems. I hardly doubt that is the case. I don't think complaining on the General Discussion list of Arch Linux will get you anywhere. Cheers, Sander -- "The sands of time were eroded by The river of constant change."
Sander Jansen wrote:
2010/11/29 "Jérôme M. Berger" <jeberger@free.fr>:
Morgan Gangwere wrote:
As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
So most likely the driver needs to be fixed instead.
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
You could perhaps file a bug with PA. Or find help on the PA mailinglist.
I did (well actually, *I* didn't: I went to look and saw that someone else had already asked). The answer was: "Who is stupid enough to have more than one sound card anyway?" Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On Tue, 2010-11-30 at 20:41 +0100, "Jérôme M. Berger" wrote:
Sander Jansen wrote:
2010/11/29 "Jérôme M. Berger" <jeberger@free.fr>:
This bug is even worse for me: the only output that PA will recognize on my system is the HDMI output from my *video* card! I don't have any HDMI capable peripheral to even try to hear it! Alsa outputs to my true sound card without any problem...
You could perhaps file a bug with PA. Or find help on the PA mailinglist.
I did (well actually, *I* didn't: I went to look and saw that someone else had already asked). The answer was: "Who is stupid enough to have more than one sound card anyway?"
Jerome Source please. I (and quite a few others on the PA list) have multiple sound cards, and I've never encountered such attitudes from the primary developers. The whole point of pavucontrol and module-combine is to allow for easy sending of signals to different or multiple cards/outputs.
participants (13)
-
"Jérôme M. Berger"
-
Allan McRae
-
fons＠kokkinizita.net
-
Ionuț Bîru
-
Morgan Gangwere
-
Ng Oon-Ee
-
Philipp Überbacher
-
Rasmus Steinke
-
Ray Rashif
-
Sander Jansen
-
Ulf Winkelvos
-
Yaro Kasear
-
Χρήστος Κώτσαρης