I spent some free time today getting caught up on the large backlog of phonon-gstreamer bugs. Towards the end, I started to have delusions of grandeur: Imagine a phonon-gstreamer codebase that doesn’t require supporting a zillion different audio frameworks, and instead belays that task to something that I don’t have to maintain.
My question here, is how many people would throw a fit if phonon-gstreamer dropped support for ALSA and OSS, and forced everyone to use pulseaudio by way of GStreamer’s excellent pulseaudio support?
Hold on, lower your pitchforks for a minute. Let us consider the audio framework landscape in the modern world:
- Pulseaudio is the One True Way for audio playback in Gnome
- For 90% of the support questions we handle in #kde-multimedia, the solution is “use pulseaudio”.
- Pulseaudio can handle using OSS, ALSA, Bluetooth, or whatever your audio output is, through one consistent entry point
- It is a total headache to figure out any bugs in your audio when music goes from Amarok->Phonon->Phonon-GStreamer->(ALSA, OSS, Pulseaudio, god knows what)->Speakers->Earholes
Additionally, I really don’t feel like testing phonon-gstreamer on all those different kernel-level interfaces with exotic setups every time I fix a bug and am afraid I’d introduce another twelve. The PulseAudio folks seem to do a fantastic job at that already. Phonon isn’t meant for real-time playback or production studio quality audio. Thats what Jack is meant for.
I can’t think of a good reason why we shouldn’t stand on the shoulders of giants by making PulseAudio handle all the hard stuff on Unix involving massaging PCM formats, equalizers, matching playback category with output device, enumerating outputs both real and virtual, volume control, etc.
If you can, leave a comment on this post. I’m not making an official statement saying that I’m definitely removing ALSA and OSS support from phonon-gstreamer, I’m merely asking for feedback to see what can be done to fix things at all levels in the audio stack.
For me, there is one big reason – it doesn’t always work.
I somehow got used to /sound works out of the box/ since I haven’t had any problems from the late ninties and Red Hat 5.x series when I had two sound-cards in my system and both worked without any additional work, to the point in time distributions started pushing Pulse.
Guess I could make it work on my system, but so far it was always easier to do a apt-get purge … and rely on alsa which haven’t failed on me yet.
To be honest, I know a lot of opposite support requests that ended in PA’s removal to be able to use audio
I concur with Ivan – my approach every time I install a new version of kubuntu (at every release, at least) is to try leaving pulseaudio in place for a couple of weeks, but I usually never get past the first week. Sometimes it gives problems with some app, or can’t set the microphone sound, or doesn’t detect that I just plugged the headphones, more frequently it is just wasting CPU cycles like crazy, which isn’t good for my battery life. And I never find out nothing that pulse audio helps me with that I can’t do better with alsa.
In the end, it is a rare event that I have still not purged pulseaudio after a couple of weeks.
So please, keep alsa support. Pulseaudio adds nothing and mostly is a source of troubles to me.
Out of curiosity, what distro are you using?
Kubuntu right now, but looking at arch as possible alternative.
I use kubuntu too and had problems before but since 3-4 versions pulseaudio just works.
Only thing is that sometimes I needed to enable micro from pavucontrol.
I totally support this move. Pulseaudio’s being successfully ported to platforms like Android so I really see no reason not switching to it exclusively.
I second that. Once I got KDE + PulseAudio correctly configured (5.1) everything is smooth. However (and I’m not sure of the correct place to say it), I would like for more integration of PulseAudio controls into KDE. I can use pavucontrol to define things, but in KDE system settings, I can’t figure out how to out put any sound in any speaker configuration mode. Maybe it is just me, but I think it would be very nice if there was some kind of communication (by means of phonon, gstreamer, wherever) among pulseaudio configs, kde multimedia configs and the real output devices so that we could use KDE’s system settings to chose the default device, its mode (5.1, 7.1, 2, etc), and other configutarions…
Thats sorta the plan here. I really want to unify the configuration system for the entire desktop’s sound system.
Note that it would require a good hard look at how well or not Phonon integrates with Pulseaudio. Specifically it would be good if KDE applications could take advantage of Pulseaudio properly, for example Kmix could do with the single most useful feature of Pavucontrol: move an apps sound sink to the right card; or adjust volume based on which applications are running/system notifications.
In fact, rigging pulseaudio so that it’ll send anything to the “configured” sound card rather than relying on the user to figure out to use pavucontrol to get Flash to work etc. would be a major improvement.
KMix can already do that if it’s running in PulseAudio mode. You may have to restart KMix for that to work, I’ve found it to often autostart before PulseAudio is ready and thus defaulting to the ALSA backend, and sadly it requires a restart to switch the backend.
I actually agree. Pulseaudio works much better now that it did before, and it actually gives a number of benefits. Also, using PA directly can ease development, allowing for a more solid product, so I am all into this.
Unfortunately Pulseaudio is stained by its rather unwieldy past, I don’t think popular opinion is going to be positive…even if it’s demonstrated being a competent sound system by now (even for developing, where it used to lag, but not anymore!).
“Phonon isn’t meant for real-time playback or production studio quality audio. That’s what Jack is meant for.”
that’s all i need to know.
so, Amarok->Phonon->Jack->Speakers->Earholes
anything else is bloat/useless.
I’m not sure why Phonon is still included there. Additionally, you still need all the other bits that Phonon provides, such as video recording, file format decoding, streaming, and more. Jack doesn’t do that.
Can JACK directly interface with speakers or are you implying:
Amarok->Phonon->Jack->(ALSA/OSS)->Speakers->Earholes
If you want to use your PC normally while also doing low-latency audio when you need to, the full stack is: -phonon-pulseaudio-jack-alsa-speakers-earholes. The trouble is 1) it’s a pain to get set up in a way that it works without fiddling each time, 2) it breaks constantly due to the pa/jack bridge and 3) when it works, you have so many mixer controls that you could start a business selling them and never run out of inventory. Linux audio is a bit of a joke from the 10,000ft view right now. In the few cases where it all works right, low latency audio on linux is rock solid and better than any other platform. Trouble is, those cases are vanishingly rare once you take pro audio device compatibility and recording software into account.
I totally agree with you. Linux should have better audio support, and looking on limited contributor resources, it makes sense to support only few most popular frameworks/API’s.
I think that Phonon-GStreamer should thrive on its absolutely best possible support for modern multimedia features in Linux. If it makes developement easier and faster then removing ALSA and OSS should be done right away. I doubt that there’s any other realistic way of getting there but simplifying the stack and focusing on what really matters.
KDE Multimedia is having some really nice developement going on right now like Plasma Media Center, Bangarang (sematic media player) and Veromix (PulseAudio mixer). Phonon is also used by other interesting projects like Tomahawk and Minitube. It’s absolutely crucial for it to support the advanced features so these applications can truly shine.
PulseAudio is the future and it should be embraced. Having good support for speacker setup, system wide and application spesific equalizers and volume control, networking and other modern features would make KDE a lot more pleasant for people who enjoy media.
Thank you.
Just curious how this would affect the rest of the open-source OS landscape, where PulseAudio is regarded as unnecessary crap and doesn’t get used? For instance, FreeBSD’s OSS supports just about everything PulseAudio does (and has for many many years before Pulse was ever conceived).
It doesn’t affect me, personally, as I use phonon-vlc. Just curious, is all.
Thats the only thing that really bothers me. I’m starting to think about maybe just stripping out all the other support in an experimental branch and incremently adding shims for the gstreamer support on those platforms.
Wouldn’t it be fine to just say if don’t want to use PulseAudio, use Phonon-VLC?
PVLC still uses pulseaudio
which version?
phonon-backend-vlc-0.5.0 on chakra works without pulseaudio
> For instance, FreeBSD’s…
That’s exactly what Lennart Poettering told us about – obsolete systems are holding back innovations.
Its a bit rude to call *BSD an obsolete system. I’d say they’re more unsupported and lacking in developer manpower than anything else.
I hardly doubt that FreeBSD’s OSS does the same thing that PulseAudio does. Maybe they added a software mixer after years of allowing only one application to produce audio. Remember that was the reason audio daemons got invented in the first place. Because OSS sucked so damn bad. PulseAudio does a lot more than software mixing. BT-audio without PA is a great pain in the ass. Per application audio settings are very nice. Easy streaming over the network can be quite handy. Does OSS provide all those features?
Yes PA had a rough start and somethings could be done better. But I’m absolutely okay with Phonon kicking Alsa/OSS support. Maybe that way we’ll get a nice usable KMix that can use Phonon features.
Perhaps you should learn your history a little better.
OSS *on Linux* has only ever allowed a single application to open /dev/dsp, leading to the development of sound daemons *on Linux*,
OSS *on FreeBSD* has supported virtual channels since the 4.x days, over a decade ago. /dev/dsp was just a symlink to /dev/dsp0. Well-behaved applications would open /dev/dsp, get linked to a virtual channel, and all the audio would be mixed in the kernel and played out the speakers. Mis-behaved applications that required being the sole user of a DPS could be configured to use /dev/dsp0.1, /dev/dsp0.2, etc and the kernel would handle all the mixing.
Long before Linux had PulseAudio, aRts, esound, and even ALSA, multi-source sound mixing was working in FreeBSD … using OSS.
Why not use just Jack? Phonon is really needed? Why so many layers over layers creating more overhead?
Jack only does audio playback. Phonon does more than just audio, such as webcam recording, opengl video playback, file decoding, and streaming.
Same reason we don’t rely on GStreamer or any other Framework or API directly, the sole reason for Phonon existing is so that we have a stable and supported multimedia API throughout the life-cycle of a KDE major release (i.e. KDE4). If we used Jack or GStreamer directly we would then be dependent on their maintaining API stability for the entire release (i.e. we dictact their release cycle and api) or would be stuck with an ever-aging version. We’ve been through that pain before, we don’t wish to repeat it. Instead Phonon makes us independent of the backend, if GStreamer upgrades and changes their api in the process then we just write a new Phonon backend plugin, no KDE app needs to change a single line of code as a result.
That doesn’t really address the problem though. There’s a *lot* of issues with Phonon’s API design that gives headaches to people. Instead of everyone being stuck with the 0.10 gstreamer API (which hasn’t changed in *eons*), everyone is stuck with the 4.0 Phonon API.
Then why the Phonon API has not been extended, while keeping the old API as deprecated?
It has been extended, and old API has been deprecated. However, some parts of the API that need fixed would be a really huge change, breaking source and binary compatability.
Hoo boy are you in for it now
For myself – sounds a good idea. Pulse is not going away and why duplicate all that work. I used to really dislike pulse, but last 2 releases of kubuntu its been very reliable for me.
From what I see, PulseAudioe doesn’t add anything that I’d need apart from yet another abstraction layer (TM) between ALSA and Phonon, another dependancy and with that another possible point of failure.
I’m using Gentoo and whereas I understand many binary distros have forced PulseAudio to be the default and hard to turn off, with Gentoo it’s not the case. For me, ALSA just works and when I tried PulseAudio, it didn’t.
That being said, I’m by far not an audio guru, so that’s just my two cents as an end user.
Gentoo seems to be the last bastion of good pulseaudio support. Most major distros (RHEL, Fedora, Ubuntu, SUSE, etc) all have amazing pulseaudio support. I don’t feel it worth the time to give 100% of our support to platforms that choose to have an audio stack without pulseaudio “because I don’t want it”.
My pure ALSA audio stack works very well out of the box.
So it is not that I don’t want, but rather I don’t need PulseAudio.
So why would I use something I don’t need ? It can only worsen things: new bugs, security problems, and don’t forget those introduced by the added dependencies.
Gentoo is all about freedom of choice, which I believe is also the very essence of free software.
Free software is not about choice, it is about the freedom to copy and modify source code. You have no choice of an X server if you want to have a graphical environment. It is XOrg or nothing. If the kernel developers decided to remove support for HFS+, it isn’t your choice if they do or not.
I didn’t say choice. I said freedom of choice. There is a subtle difference.
Of course there are lots of cases where I can’t make any choice. But there are also lots of cases where there are perfectly valid alternatives. In those cases, I want to decide. That is the main reason I use Gentoo.
PulseAudio is shiny with all its features, that’s fine for people who need them. I don’t. So I keep the KISS solution. And I want to be able to do that choice.
Infact that will means that KDE will depends on PulseAudio (like GNOME), not the entire distro.
I use openSUSE 12.1 (the current release version). It ships with PA1 and it’s far from amazing. As I wrote in another post, it mutes my sound output randomly.
How is that amazing?
I’d second that experience – in opensuse 12.1, to get working 5.1* sound I can not use pulse audio, infact the most effective solution has been to remove just about all packages/settings related to audio to make sure nothing but alsa is expected anywhere. After that it seems to only be a matter of making sure all volume controls are turned up.
*working as in: all speakers used, and all channels using the right speaker – pulse audio has a tendency to play random channels in random speakers, far from good enough.
I’m a longtime hardcore Gentoo (+10years) and KDE (+14 years) user.
I hated PulseAudio like nothing else, until it became suddenly usable and also a crucial part of my sound setup.
It works now flawlessly and makes it possible to have a dynamic sound setup on my Laptop, switching between:
- USB headset
- Bluetooth headset
- Internal sound
- Internal sound with earphones plugged in
- Stream via TCP to server which provides 5.1 output
I’d totally vote for focussing on PulseAudio support!
I would stop developing for JuK. When Phonon finally couldn’t work with the old phonon-gst I would write phonon-null and use that.
I lived through aRts until the bliss of aKode made everything better. I’m not going back.
Sorry, but there’s a null backend in the phonon sources already
I personally think that have less bugs is the main priority, as you said phonom is not meant to be a low latency framework or something like this.
PS: phonom : KDE = gstreamer : GNOME?
I don’t know, I’m a GNOME user, and I’m still confused about phonom, gstreamer, xine, ALSA, OSS, Pulseaudio, Jack, ESD… I don’t know exactly who is up to what!
Linux audio mess is a consolidated statement and there is no clarity about.
Seems that ISO/OSI network stack looks more clear about…
Very approximately:
ALSA is the lowest level. You can look at it simply as being the device drivers, as a useful approximation. ALSA talks to the hardware, and actually makes things go squeak. Apps _can_ sit right on top of ALSA, giving you a nice short easy to understand chain, but there are reasons not to do this. Keep reading.
PulseAudio sits on top of ALSA. It provides (or, rather, aspires to provide) a universal interface for apps that want to make things go squeak (or record things going squeak) to talk to, without having to deal with all sorts of painful hardware-specific stuff you have to deal with in order to talk directly to ALSA. It handles stuff like ‘okay, what cards are actually connected to this machine? What output on what card should we be going squeak through? How do we handle these three apps which all want to go squeak at the same time? What speaker setup is attached to this card?’ If you’re writing an app to PA all you really have to say is ‘hey, PulseAudio, I want to go squeak’, and let it take care of the gory details.
in GNOME, apps then sit directly on top of PA, and that’s really your whole stack. gstreamer isn’t directly in this chain, it sits a bit off to the side somewhere: gstreamer is more about encoding and decoding video and audio than it is about outputting it, exactly.
In KDE things are a bit more complex because you have Phonon, which more or less sits on top of PulseAudio – yes, it’s an abstraction layer on top of an abstraction layer. Why? AIUI, because KDE wanted a KDE-specific multimedia abstraction layer. It doesn’t _just_ handle audio, as Trever pointed out, it does other stuff too. When it’s handling audio and using PA as a backend, yes, that’s a mite superfluous, but as it’s really a unified abstraction layer for multimedia handling in general, it still more or less makes sense. If you’re writing an app that’s going to do stuff with media in KDE, you’re supposed to go through Phonon, and again, let it take care of the hard stuff. You just tell it you want to play some video.
Well, hope that helped…
As for the others you mentioned…
xine is a media player. Not a massively widely used one, these days. Phonon could use it as a backend for handling media decoding, I believe. Not sure it can any more. It is/was an alternative to gstreamer – you can have Phonon use either xine or gstreamer to, say, decode some MP3 audio or an MPEG-2 video file.
OSS is an alternative to ALSA, it’s an alternative set of device drivers for audio adapters. It’s rarely used on Linux these days. The few people who do use it tend to be, ahem…enthusiastic, shall we say. In the dim and distant past, OSS was quite proprietary, and a restricted free version was the default set of audio drivers for the Linux kernel. Then ALSA came along and was the shiny new thing; for a long time it existed independently of the Linux kernel, which still contained OSS/Free drivers, and distributions would often build kernels with _both_ the OSS/Free drivers and the ALSA drivers, and let you pick which to use. Because it was around first, the OSS interface became something of a de facto standard, and ALSA drivers were (and still are) compatible with it – apps that were native OSS would work with ALSA drivers, because the ALSA drivers provided all the interfaces OSS drivers did. Happily, these days, all this is rapidly becoming ancient history and you don’t have to care an awful lot about it any more.
JACK is a pretty specialized daemon which is _approximately_ an equivalent of PulseAudio in terms of where it sits in the stack – between ALSA and applications – but has a pretty different purpose. JACK is very focused around pro audio. So it gives you a lot of manual control and tweakability over stuff like sampling rates, and it focuses a lot on reducing latency. Most pro audio apps on Linux really, really want you to run them through JACK. If you’re not doing pro audio, you can pretty much ignore it.
ESD (EsounD) is what GNOME used at the same level as PulseAudio in the stack before PulseAudio came along. KDE had something similar called aRts. They’re very dead now and you really don’t have to care about them. They basically existed to do just one of the many things PulseAudio does these days – software mixing (allow multiple apps to play sound at the same time).
Again, hope that helps. Consider yourself lucky you live in a world where you mostly don’t have to know or care about OSS, ESD, aRts and the various wrappers around all of ‘em any more. Very, very lucky.
Yes that’s true, the situation now is LESS worse!
Again I don’t see the esigence to have Jack or Pulseaudio… both should be able to to the same stuff, in a perfect world (more tweak about latency in PulseAudio or more feature to Jack isn’t the solution?)
You said GNOME leaved ESD because of Pulseaudio, aRTS (yes I’ve heard about it, I started with opensuse in 2005) is similar to ESD so why KDE doesn’t leaved aRTS for Pulseaudio
With the evident benefits…
I think it effectively has. I don’t think aRts exists any more. They shifted at KDE 4.0, with Phonon. Correct me if I’m wrong.
I guess in theory you could make some kind of hybrid out of JACK and PA, but I’m not sure it’d be the way to go. They’re ultimately targetting _very_ different use cases, and it might make more sense for them to be separate than combined.
Upstream didn’t really support PulseAudio back in 4.0, we patched Phonon in Fedora to work well enough over PulseAudio (with a single “PulseAudio” device), but all the nice support with System Settings integration for PulseAudio devices etc. came only in later releases. The upstream default for Phonon in 4.0 was to directly output to ALSA; it tried to configure a custom dmix setup, but that setup only worked for Phonon apps (if at all); systemwide dmix or the ALSA PulseAudio plugin weren’t supported. (In other words, with the default setup in 4.0, Phonon was mutually exclusive with any other ALSA apps.) My patches made Phonon prefer the native PulseAudio output to ALSA when available.
FWIW, we were shipping PulseAudio by default even on the KDE spin already back in Fedora 8 (i.e. along with the rest of Fedora!). The default there was actually aRts over alsa-plugins-pulseaudio over PulseAudio, fun! With Phonon, we at least had native PulseAudio support without a second sound server. (We kept shipping aRts by default for KDE 3 apps for a few more releases though and we still have it in the repo now, though of course not installed by default anymore. But we never configured Phonon to output to aRts, we had both Phonon and aRts output to PulseAudio instead.)
The Phonon Xine backend has been discontinued by upstream, it stopped working (always crashes) with Phonon 4.5 and has been dropped from Fedora 16 and later. (Other distros hopefully followed suit, they shouldn’t be shipping a no longer working, unmaintained Phonon backend.) There has been an announcement about Phonon-Xine being discontinued on this blog.
Yes, once or twice or thirty times.
Hmm, a few months ago, the first shot for all audio problems I saw on forums and on IRC was “remove pulseaudio”.
The people who wrote that are ignorant and unhelpful. Removing PulseAudio is actually the best way to break your sound. (In particular: No more mixing, i.e. only one sound app at a time. Note that dmix is no longer configured by default in PulseAudio-using distributions, because PulseAudio replaces it.)
Go for it.
We have to define parts of our stack, which of course are continously changing and evolving. PA is mature enough to be set as a dependency of at least some parts of KDE.
Dario Freddi will probably write a new “PA integration” without any phonon (workspace) or kmix support so we can have a 100% PA experience in KDE.
Of course will we continue having the excellent KMix around it will be up to distributions decide which one to use.
I’m not sure I understand this post. Does this mean that (if Dario writes the PA integration) that KDE multimedia apps will talk directly to PA instead of to Phonon (and therefore will have to support both as long as Phonon exists)?
I have an on-board soundcard, nothing more. I don’t use Phonon for every sound since I use MPD for listening to music. What’s the point of Pulseaudio for me?
Apparently nothing, but thats not really what this is about.
If PulseAudio2 is going to have better hardware support, why not? If GNOME has a hard depenency on it, it means that most distros will already support it (so it shouldn’t bother many packagers). Phonon is supposed to be nothing more than a higher-level API for KDE multimedia support, isn’t it? So would it really bother application developers? If you Phonomials feel it is a reasonable decision, go for it!
The decision here isn’t one for the application developers to be concerned about. Its mostly for the users. Nothing in libphonon would change, so thanks to the magic of phonon’s abstraction, they don’t have to care
So, there is not much of a problem then. Many packagers are packaging PulseAudio as default so I doubt most users will care about not choosing their backends and lower level audio systems! Reading some of these comments above it seems most users agree that PulseAudio.
Also, if the decesion to only support PulseAudio can make the Multimedia KCM simpler; that’s another plus of this decision.
Go forth and do, may the force be with you!
Please read on and try to understand my concerns. PulseAudio is not an option yet. Implementations of it are not that good.
For example, VLC2 comes with one, that is bad. If you raise the volume over 100%, it will modify the system volume. This includes ALL applications. And, yes, you have to restore all volumes, one per one, by hand. Very nice.
Skype won’t work out of the box with PulseAudio. Unless you’re lucky. If you’re under 64 bits, you have to install the 32 bits PulseAudio system, and that’s something for you to guess. And, if you let Skype handle the volume levels, you can be certain that no one will be able to hear you speak. You have to disable that option by hand and then go to pavucontrol and change the input volume until it’s reasonable. This is several calls to the Skype Echo Service. Same with VirtualBox.
And that’s GNOME, with KDE is even worse. KMix implementation of PulseAudio is poor. Very poor. If you manage to open the mixer without it crashing, it probably won’t work: you won’t see some devices, you won’t see some applications… that is a mess.
And yes. You’re going to say: that’s not PulseAudio’s fault. It’s a bug in the applications you use, and in KDE Mixer. Yes, I know. But, what does the user see? The user will try to use PulseAudio and see that Skype doesn’t work, that KMix crashes… then it will revert back to regular ALSA and everything will be fine.
And that’s everything the final user knows about PulseAudio: that it sucks.
You also need to install a ton of other 32 bit libraries. libpulseaudio.i386 is minor compared to Qt4.
If they keep using ALSA, Pulseaudio will not get better. The audio stack will remain the same bloated zombie that it is today.
That last argument is horrible! It’s why people hate pulseaudio in the first place. Software doesn’t magically improve itself if you force it down every user’s throat. The developer and testing communities should take care of the testing and fixing and polishing well before the product is let loose into production systems.
So? I mean, the user just uses ALSA and see that it works. Why should she care about PulseAudio not getting better? In fact he’d just want PA to disappear.
And your way to remove bloat is to force another layer?
If you keep using PulseAudio, ALSA will not get any better. The audio stack will remain the same bloated zombie that it is today. My argument make more sense since PA is the extra “bloat” layer cause it wouldn’t be possible without ALSA.
If ALSA is broken then fix it.
I’m sorry you can’t fix something that is “broken” at its base level by wrapping it in layers and layers of abstraction. By building superstructure around the broken core you only hold it togather not fix the flaws.
Another issue with layers is you have to trust every single layer in the output process to do the “right thing” the more layers the less likely that will happen correctly 100% of the time.
If ALSA is not broken then there is no need to have PA.
Stock ALSA doesn’t do mixing, by design. ALSA ships a plugin called dmix which does software mixing, but PulseAudio is just a much better dmix. Just think of PulseAudio as a replacement for dmix (and yes, unless you’re one of the lucky few who still have a sound card which does mixing in hardware, you do need one of those two), not as an extra layer.
As bad as Skype is the problems with PA you describe are non-existent for me. I run 64-bit Debian testing system. The thing I needed to do was pass a variable to Skype to use legacy Linux video interface for webcam. And as a final user I can talk and hear clearly.
Same here on Fedora. I’ve only ever used Fedora, and the packagers handle it *very* well. The only problems I had with pulse was when it first started out and every application out there was apparently using the unsafe ALSA api that demanded exclusive access to audio devices, and never even tried using the ‘default’ device, which I had routed to pulse itself.
I solved Kmix problem installing Veromix. It should be installed by default on KDE distros.
The last time I tested pulse-audio in Debian Testing (some weeks ago), it still did not really work. There were some random changes in the volume control and not all programms could play their sounds. I decided to wait another year until pulseaudio is possibly usable in KDE.
Besides, with pulseaudio your list does not get much shorter, as I see it (but I am not an expert):
Amarok->Phonon->Pulseaudio->(ALSA, OSS, god knows what)->Speakers->Earholes
The distance isn’t really important, its the fact that we’d be pushing the various different backends (ALSA, OSS, etc) further down the stack. It shouldn’t be KDE’s job to handle Linux’s audio issues. PulseAudio tries to do that.
“PulseAudio tries to do that.”
And fails…
Pure ALSA works.
It’s ok for me. But PulseAudio support in KDE isn’t perfect yet (as of KDE SC 4.8.3).
At least there should be a decent PulseAudio GUI in KDE. I mean, not all functionality from pavucontrol and paprefs can be reached from KDE.
For example, there is no way to configure simultaneous output from KDE, there is no way to select the output device for audio streams from kmix.
The GUI in systemsettings → multimedia is not nice (compare systemsettings and kmix to pavucontrol).
Veromix plasmoid supports most of the important features of PulseAudio like multiple outputs, channel swapping, application spesific volume control and equalizers etc. But agreed PulseAudio support is still bit lacking in KDE.
Yeah, do it. As long as you keep Phonon-VLC alone, I couldn’t care less about what you do with the mess that’s GStreamer at all. Any media framework that randomly stops playing my music is not worth to use anyway. (And no, I won’t try to debug the issue and file a bug report because VLC works just fine.)
I did not have the chance to test PA2, yet, but PA1 had the habit to randomly mute my sound output.
Because of these two reasons, for me: Phonon-VLC + pure ALSA = Win!
Ok. No need to trash the system that you don’t use.
You asked to hold the pitchforks for a minute. I did and once the minute passed, I used my pitchfork.
And no, I did not lie. Neither PA nor GStreamer work well for me.
Whats wrong with GStreamer?
I don’t know what markus problem with Gstreamer is, but I can tell one thing which doesn’t work for me (and I got no clue how to make any meaningful bug report of it). As it turns out phonon-gstreamer doesn’t like the front 2.5mm headphone jack. No sound at all. works fine with phonon-vlc alas that comes with it’s own set of problems.
As I already wrote: It randomly stops playing my music.
When VLC 2.0 came out, I had to use Phonon-GStreamer for a while until updated Phonon-VLC packages were available.
Every once in a while JuK simply refused to play a song. Not that the file was incompatible (hitting Play again played the file) – it was completely random.
No idea whether it was GStreamer’s own fault or that of Fluendo-MP3 and I do not care. With Phonon-VLC everything is silky smooth.
You are right that “Phonon isn’t meant for real-time playback or production studio quality audio. Thats what Jack is meant for.”
While things are a lot better than they used to be, Pulseaudio unfortunately still causes issues for those of us who want to use Jack. Sure there are workarounds but they are just that – workarounds. Basically this means either stopping Pulseaudio altogether (under your proposal losing sound from any KDE/Qt application that uses Phonon) or running Pulseaudio through Jack (last time I tried caused all sorts of wierd issues, including glitches in audio – unnacceptable for users of Jack).
I realise you’re the one doing the work, so ultimately it’s up to you and whoever else is working on Phonon… But I was under the impression that one of the reasons for creating Phonon in the first place was that it would allow KDE applications to “just work”, no matter what the backend/audio system is. So mandating the use of Pulseaudio seems to go against that goal, especially when ALSA is so much more reliable and well tested at the moment, especially in cases where Jack is also present. In fact Pulseaudio is the main reason I stayed away from Ubuntu/GNOME and searched for a good distribution running KDE when I started using Linux.
By the way, there is still an issue with the Phonon-GStreamer backend (or maybe the issue is in knotify). Jack can’t start – it gives a message that says the soundcard is already in use by another application. Killing knotify allows Jack to start. This is not an issue with Phonon-VLC or even Phonon-Xine. Unfortunately the Phonon-GStreamer backend (through ALSA!) seems to be the best for KDE applications at this point.
> Pulseaudio is the main reason I stayed away from Ubuntu/GNOME and searched for a good distribution running KDE when I started using Linux.
have you found it? what is it, in your opinion? thanks
For me Arch Linux is the best choice. I like a lot of manual control, and for pro audio it works well. I like the fact that with Arch you can include what you want, by default only a very basic system is installed (without Pulseaudio!)
Also the Arch forums and wiki are among the best sources of Linux information anywhere on the web, I have certainly learnt a lot from both of these.
But depending what you want/need you might prefer something else… Arch takes more time and effort to set up than some other distros, but if you know what you want you can do it with Arch.
As a side note – there are a few distributions which are focused on audio which generally use a more minimal desktop environment such as XFCE. I have a reasonably modern computer, and while KDE might not be as light as some other desktop environments, I don’t find that it uses too much memory/cpu or gets in the way of any the audio applications that I use.
Thanks! By the way, now I’m testing chakra (son of arch)… Not bad
Avoiding the “soundcard already in use” issue is exactly what sound servers like PulseAudio and JACK are for. Unfortunately, there are 2 of them, and their developers see their use cases as mutually exclusive.
Thr s n sr wy. Jst kll Phnn-GStrmr trght.
[Where are the vowels?]And what might that solve?
All problems present in GStreamer and not VLC.
Nothing, of course.
Can you please devowelize that troll? 
Thank you for Phonon-GStreamer in the name of the entirety of Fedora and please do not let such trolls discourage you!
I personally welcome this. The only thing I concerned is JACK. Although it’s not that popular among users I believe it worth to support it as well.
I fully support this too.
I used to be one of those who were outright against using PulseAudio (ArchLinux user).
Then I bought myself a flat TV and wanted to send audio output through HDMI…
Sure it was possible with ALSA, editing ~/.alsarc each time I wanted to switch to using audio over HDMI, but that wasn’t very convenient.
So I ended up installing PulseAudio, and was amazed at how good the support was, everything worked out of the box.
Now I use it even on my laptop where I wouldn’t really need it, just because it gives me less trouble than using plain ALSA and also provides me with features like system wide equalizer.
So if dropping OSS and ALSA support could make the code easier to maintain this would be a very welcome change to me.
I’m not a guru, but i’m quite practical: do it in a experimental branch, then we’ll test it.
Yup, thats the plan.
How many more audio stacks are going to be flavour of the year? Over the years each one has been the “greatest” and now they are the “bloated” mess.
I wish they would stick one system. How long before pulseaudio is last weeks news?
“Pulseaudio is the One True Way for audio playback in Gnome” – if you are going to make a comment like that then you might as well say “GTK is the one true way for a GUI in Gnome – lets junk QT”
If you want all functionality in one audio server then it’s going to be bloated and there’s no way around it. PulseAudio is nowadays the de facto audio server on Linux and I don’t see anything replacing it in the next decade. It has active developement team and it is used in many commercial platfroms like Maemo, Meego, webOS, Chrome OS, Tizen… and of course every major Linux desktop distribution out there.
Whatever you do, please leave a way for Phonon to be used without PulseAudio – for example, by means of phonon-vlc.
The first time that I actually solved audio problems by installing PulseAudio is less than three months ago. Then I tried to use it on my system, too, and got it working everywhere – except for wine. I assume this is due to wine being a 32bit application, and PA has *way* more dependencies than pure ALSA – and for a 32bit application to use the ALSA emulation provided by PA, the 32bit PC library has to be installed. Which is a pain. So I’m back to a PA-less system again, with perfectly working sound.
However, I wonder why this move is even necessary – I thought gstreamer abstracted ALSA/PA/OSS away from its users, by choosing an appropriate output module (or sink or however they call it) itself?
Is it possible to split libphonon and leave the ALSA/OSS support in a separate lib, still available but no longer supported (unless someone else wants to take it up)?
My Mom said I should check my earholes, because I seem to fail to hear what see says. I tried to file a bugreport at the creators, but somehow it got marked wontfix.
anyways audio works out of the box for many kubuntu releases, so i dont care what you do with it as long as it keeps working out of the box!
Pingback: Trever Fischer pensa a rimuovere il supporto di ALSA e OSS da Phonon | RampaCrew
Pingback: Trever Fischer pensa a rimuovere il supporto di ALSA e OSS da Phonon | Tuttolinux - novità ed articoli dal mondo del pinguino !
I use ALSA, and I don’t see why I should even try using PulseAudio. I have two outputs (headphones and speakers), but I don’t mind at all if the software considers them as one and the same. In fact, only recently an ALSA upgrade allowed the mixer to control the master volume of the speakers and the headphones independently.
I don’t need equalizers or playback categories. I don’t need to route different apps to different outputs or control their volume independently. ALSA Works For Me(tm).
Funnily, the first thing I do on a new installation is to remove PulseAudio. Then my audio always does exactly what I want. Did PulseAudio improve so heavily recently?
If by ‘recently’ you mean within the last year, yeah. Until about a year ago, most people removed pulseaudio and phonon had fewer problems (most certainly not zero problems, but fewer). Nowadays, our default reply in #kde-multimedia is to “pull your head out of the sand and try pulse.” Problems magically go away afterwards.
I certainly don’t like it. I tested pulseaudio 2 a few days ago and I still have issues with it. Sound crackles every time a new audio source is played by some new application. This is especially annoying for system notifications. Also, crackling occurs when changing low volumes. I seriously couldn’t understand pushing this change if pulseaudio still has issues like these while ALSA works perfectly out of the box.
It seems to me though that it is a vocal minority of users who have issues with PulseAudio, and it can usually be traced back to their distribution’s packaging of it.
I doubt that. Currently, I am running ArchLinux on my system (which in my opinion has excellent out-of-the-box experience for nearly anything you install). Before that I used Kubuntu. The heck, I will try the latest Fedora live CD (or any other distro you’d like to throw at me that allegedly has “perfect PulseAudio support”) once I downloaded it and guess what: these issues will come (And I will keep you posted on the result of this here
.
And trying to find a solution to these problems always result to the same outdated tips how to solve them. Only problem is that those tips don’t help or the issue they resolved were fixed in PulseAudio long ago.
And that’s why I don’t want this particular change until all PulseAudio issues have been resolved and will ship out-of-the-box in all major distribution without the user having to make some voodoo changes of its configuration files to make it work.
I mean: I am running on a computer that’s from 2004! No special configuration. Just some audio boxes plugged into the onboard audio. ALSA works perfectly, PulseAudio has issues with it. So I guess PulseAudio’s focus has been on the special cases of – I don’t know – combining two audio cards for virtual surround sound? Here’s what I’d expect from the “One True Way for audio playback”: to work out-of-the-box for a simple configuration like mine. And you say it yourself: “For 90% of the support questions we handle in #kde-multimedia, the solution is “use pulseaudio”.” What are the other 10%? PurgeI doubt that. Currently, I am running ArchLinux on my system (which in my opinion has excellent out-of-the-box experience for nearly anything you install). Before that I used Kubuntu. The heck, I will try the latest Fedora live CD (or any other distro you’d like to throw at me that allegedly has “perfect PulseAudio support”) once I downloaded it and guess what: these issues will come (And I will keep you posted on the result of this here
.
And trying to find a solution to these problems always result to the same outdated tips how to solve them. Only problem is that those tips don’t help or the issue they resolved were fixed in PulseAudio long ago.
And that’s why I don’t want this particular change until all PulseAudio issues have been resolved and will ship out-of-the-box in all major distribution without the user having to make some voodoo changes of its configuration files to make it work.
I mean: I am running on a computer that’s from 2004! No special configuration. Just some audio boxes plugged into the onboard audio. ALSA works perfectly, PulseAudio has issues with it. So I guess PulseAudio’s focus has been on the special cases of – I don’t know – combining two audio cards for virtual surround sound? Here’s what I’d expect from the “One True Way for audio playback”: to work out-of-the-box for a simple configuration like mine. And you say it yourself: “For 90% of the support questions we handle in #kde-multimedia, the solution is “use pulseaudio”.” What are the other 10%? Purge PulseAudio?
Anyway, I’m rambling now. I am willing to help someone advanced enough in PulseAudio debugging to debug this issue I am experiencing (which is most certainly in PulseAudio itself and not its distribution packaging).
PulseAudio already ships in all major distributions by default. If the problem isn’t the configuration then it’s in all likely hood the drivers. PulseAudio requires some functionality from the drivers to work and even though things have gotten a lot better since the early days of PulseAudio there are still some that haven’t been fixed yet.
We simply can’t let bad drivers hinder the entire developement of the rest of the audio stack on Linux. It just about the same with video drivers. We shouldn’t develope our window managers by the limits of the worst hardware possible.
Only funny thing is: the intel8x0 driver is supposedly fixed.
It has nothing to do with the distribution packaging. It’s mainly about KISS.
Many people just don’t NEED PulseAudio.
A desire to keep things simple does not explain the issues I see when Pulseaudio can’t read the audio devices on a fresh install of a linux distro.
Many other people do need it, and the goal is to support as many hardware setups as possible out of the box, even if that includes a piece of software which might not be strictly necessary for you.
I’m a long-time KDE/Linux user and honestly, I’m REALLY VERY MUCH in favor of this. I’ve only had trouble just relying on low-level OSS (before there was ALSA) and then ALSA – KDE3′s artsd actually helped a lot in making stuff actually work[tm] but ate away lots of CPU and caused a high latency.
I’ve only really been happy with sound under Linux since recent versions of PulseAudio. Multiple streams and mixing now just work, I can tune audio levels properly, not having to see 50 different hardware-related mixers I don’t actually care about anyway, but now I can actually also change the volume of different *programs* relative to each other.
The only thing I’m not really happy is that as a KDE user, some PulseAudio settings can’t be properly changed via KMix, I have to use pavucontrol – which I have to start manually and can’t just click on the volume icon in the system tray.
Also, I really have the impression that with PulseAudio, things are constantly improving and bugs are fixed and features added in a relatively short timespan. With just plain old ALSA (yeah, I know PA is on top of ALSA, but it also works around bugs in ALSA) the impression I had was that no matter how much time passed, the general state of affairs didn’t really change. (Software mixing with ALSA alone still doesn’t work properly for me.)
And as for compatibility with older software – as far as I know, PA provides a /dev/dsp-wrapper like artsd used to for really old software and for a bit newer software you can easily configure ALSA to default to PulseAudio output if you install the correct plugin (which at least Fedora does by default anyway). But even Skype supports PA out of the box nowadays. And in the past I’ve always had trouble with Skype on top of ALSA alone, especially with Bluetooth headsets; whereas it just works now with PA.
To be fair to some of the cirtics: up to 2 to 3 years ago, I didn’t use PulseAudio either, because (a) the software integration was not even remotely as good as it is today (even though KMix doesn’t support every feature of pavucontrol, most standard everyday stuff does actually work) and (b) it really was quite buggy back then. But I see old versions of PulseAudio in analogy to KDE 4.0: that wasn’t very well-polished either, had lots of bugs and created a lot of hate on the internet – but that doesn’t mean we should ditch current versions of KDE SC, I’m very happy with KDE SC 4.8. Same argument should go for PulseAudio IMHO.
I see several advantages to this move, as a kde user :
* users who don’t want pulseaudio will move to phonon-vlc
* users who want pulseaudio will move to phonon-gstreamer, report new bugs and the puleaudio integration in KDE will be improved
* gstreamer code base quality will be improved and your work will be easier
The big drawback is for platforms not supported by pulseaudio (*bsd ?).
Hi Trever,
I fully support your move, even if I’m not 100% happy with PA yet. But that’ll come once people are bold enough to do decisions like this.
What you’re trying is to aim for more quality while cutting down on the quantity (of features). That’s, for me who’s mostly a KDE user these days, the best thing that can happen.
If somebody needs to work without PA let him find a way or create a phonon-gstreamer-alsa fork, whatever. Or let them pay you for it… This is important: focus, so that you can keep the fun going while working on it, otherwise the result might be resignation (even if you can’t see that coming yet), which would the worst outcome.
Cheers, and thanks a lot for your work!
Matthias
This makes a lot of sense to me.
As a KDE user I’m very much in favor of development and testing being focused on as few setups as possible, and despite what some people say PulseAudio is far superior to ALSA, and once bugs have been ironed out it will be a no-brainer to use PA for all users.
If the case is that there are still serious bugs with PA under some hardware, then maybe wait a bit before you remove the old code, but you could certainly clearly mark it as deprecated already now, and close all bugs as “wontfix”.
Thanks for all your hard work!
Well, you asked the entire Internet what it thinks about PulseAudio, and here’s the result anybody could have predicted. If someone wants to keep the other backends in good condition, they can go ahead and do it themselves. It’s 2012 now, and Linux audio is just as often a shit-show as not… if everybody switched to pulse when Fedora did, we’d all be in happy-land by now. There’s only one time everybody’s going to switch: when they have to.
The “entire Internet” seems to have a lot of different experiences with Pulseaudio. Enough to conclude that for many, Pulse is making Linux audio more of a shit-show, not less. This might change in the future if Pulse does indeed reach its potential – but right now ALSA without Pulse works a lot better for many people. In fact, I have never had any problems with desktop audio in the 4 years I have been using Linux with ALSA.
To be fair I have re-read the blog and it seems that phonon-vlc would still work without Pulse, I did not realise that at first. Maybe this is all a bit of a storm in a teacup then, assuming phonon-vlc is supported for the forseeable future. Although I have had issues with phonon-vlc in the past…
Pingback: Trever Fischer pensa a rimuovere il supporto di ALSA e OSS da Phonon | Indipedia – Indipendenti nella rete
I use openSUSE 12.1 with KDE SC 4.8 – and a setup with PulseAudio works well. If I recall correctly PulseAudio did not work well before 12.1, but that’s history and the topic here is the future.
As you write, testing for multiple configurations is an additional effort which should be avoided if possible. If the developer(s) thinks the way forward is to concentrate on a good PulseAudio solution I think that should be the way forward.
If Pulse Audio being an absolute dependency, means breaking sound under Linux, then it’s fine by me. Who needs sound anyways?
Thankfully your premise is false.
Last time I checked pulseaudio with a live cd, I couldn’t get 5.1 surround output working. It also made the various soundcard settings (upmixing, phase inversion and the like) inacessible.
Did this change recently, or does pulse still only target onboard card systems?
I’m not sure what you mean by ‘recently’, but my desktop has had 5.1 surround sound with my PCI card for at least two years. My USB headset also works flawlessly.
Definetly support the move to PA. This is a de-facto standard on modern distro. But before of this move KDE PA support really needs improvements. Just to say here amarok always reset its volume to the master one couse the PA connection is restarted every time. kmix should really looks more like pavucontrol: it should be easy to change the output and the progress bar showing the realtime volume of the stream are really a killer feature (just think when you have to test your microfone).
About ALSA always working for me it is the opposite. I can’t make the microfone to work with PA and I don’t understand why. This is on sabayon. I don’t say ALSA support should be dropped, may be just simplify to be able to maintain it, but Pulseaudio support should really be the first priority given it gives you a lot of features (separate volume per stream, switching input/output source on the fly, echo cancellation and so on….) and it is the default on most ditribution (also on KDE focused distros)
While I find it very appealing to *simplify* the layers-upon-layers-upon-layers KDE/Linux audio stack I have several reasons against limiting gstreamer to Pulseaudio:
1) “usb_set_interface” failed log spam for USB sound card sonica theater which Pulseaudio then doesn´t recognize (trac ticket #826). Pulseaudio recognized that sound card only some of the time.
2) severe stuttering on ThinkPad T23 for up to *one minute* – *with* rtkit installed and promoting Pulseaudio threads to realtime priority. May be related to slow and aged BTRFS filesystems, but then it doesn´t happen without Pulseaudio.
3) USB Sonica Theater has more channels than Pulseaudio supports and then resets volume to single channel mono only on every resume from suspend-to-disk (fdo bug #48730). GStreamer w/o audio seems to have the issue also, but at least doesn´t reset volume on every resume. alsamixer -c1 nicely shows all channels.
4) At work I have two sessions on my production laptop. One private one which sometimes plays music, the work one for work related stuff. The only way to get audio playback from the private session while using the work session seems to use system-wide Pulseaudio which is not officially supported and requires adding exit 0 to start-pulseaudio-kde and dpkg-diverting (fdo bug#48728).
5) Sometimes Pulseaudio is just not there anymore. There is no Pulseaudio process anymore. I assume it silently crashed and but never checked it.
6) Upstream IMHO seem to have a “we support this usecase and if you have another usecase, then go away” GNOME-likish habit. (see pulseaudio-discuss mailinglist archives for responses to my post).
Admittedly I do not have much interested in spending much time to make Pulseaudio work right for me. I removed it from my Amarok playback machine again due to issues 1+2+3.
For further feelings about Pulseaudio just read my post:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-April/013296.html
Severaly times I have been very, very frustrated about Pulseaudio, cause usually when I want to hear music I just want to hear music. I want that it *just works*. Like my CD player. I do not want to configure anything, I do not want to enable system mode, I do not want to adjust volume levels when the last ones used have been good, I want my Amarok machine to resume playback at where it paused when I hibernated it. I just want to hear audio as simply as using my CD player and be done with it.
Thus my current wish would be to just use ALSA and maybe improve its mixing technologies and skip Pulseaudio until it has proven to support these easy usecases.
Re Markus S.: I had it that Amarok wouldn´t play certain tracks. I used Phonon Gstreamer. I now switched to Phonon VLC. And now it plays these tracks. At least the ones I tried quickly.
Thanks you for the hint to try Phonon VLC if Phonon GStreamer doesn´t play something.
by the way, there is also phonon-mplayer! just in case the previous don’t play something
Phonon-MPlayer is as unmaintained as Phonon-Xine.
The correct approach to having phonon-gstreamer not playing certain files would be to file a bug so that the developer can fix it.
The reality is that if you are forced to pick and choose different phonon backends because they are all broken in some manner then that means that you will never have a solution that actually works. But if you pick one solution and then fix it when problems come up then at least then you have a fighting chance to get it right for as many situations as possible.
Anyways the media playback features for VLC is mostly provided by the libavcodec, which comes from the ffmpeg project. Gstreamer features support for ‘Gstreamer ffmpeg plugin’, which provides the same functionality. So when everything is working correctly then maintaining both vlc and gstreamer backends is redundant.
I definately support the move to pulseaudio only development efforts. In the years I’ve used fedora I’ve never had a single problem with pulseaudio, and the only time I ever need to call alsa directly is when passing AC3 5.1 straight to my receiver (but I heard PA is working on this).
IMO the stalwart enemies of PA fall into two categories, the people running ancient hardware and those hobbiest with esoteric setups who prefer doing things a certain way. My personal opinion is that no development efforts should be wasted on these types of people. If your computer is too old to play sound using modern technology, buy a new one.
“If your computer is too old to play sound using modern technology, buy a new one.” your sentence is absurd
Efforts are wasted on nerdy creative types and non-moneyed non-consumers? Oy, thanks :/
BeOS had sub 5 msec latency on 90′s hardware with no aliasing or glitchs… now my 2 years old pc is “too old to play sound using modern technology, buy a new one.”?? you gonna be kidding! there is another explanation: pulseaudio sucks.
PulseAudio works just fine on this 9-year-old computer.
PulseAudio does not even work properly on my Core i3, GTX 560 Ti, Ubuntu 12.04 (no KDE, but with support for my Wifi adapter), Firefox, 720p Flash video, fullscreen: The sound stutters from time to time. After “sudo apt-get purge pulseaudio*” everything is fine, even if I loose the ability to control the volume with my keyboard.
Try upgrading to a newer release. Launchpad lists quite a few closed bugs related to stuttering: http://goo.gl/TdhH0
@Trever
It is the most recent version i.e there are no further updates/upgrades (but pulseaudio –version ist 1.1). The stutter is reproducible in this scenario. Simpler tasks like playing music with Amarok work flawlessly with and without PA, but regarding backends phonen-vlc uses less CPU resources than phonon-gstreamer.
Does Ubuntu still disable timer-based scheduling by default (against Lennart’s explicit recommendation)? Try enabling it.
Ubuntu does not disable timer-based scheduling in the driver, the corresponding line in /etc/pulse/default.pa is simply
load-module module-udev-detect
What actually helped was to enable realtime-scheduling (and high-priortiy for the daemon), but this is quite dubious for a desktop sound server. Given similar problems with arts, it seems the idea of a sound server (i.e. a separate process) is fundamentally flawed, it is apparently only viable with a real-time OS with hard guarantees for a deadline.
Please fix KMix first. In the current state it doesn’t really work with PulseAudio besides having a horrible UI. Take a look at how Veromix works or make Veromix the KMix replacement.
If you can get Audacity, Flash, and KDE (mostly Amarok) to all play well together and not take exclusive locks on the PulseAudio stack (which Flash and Audacity both seem wont to do), then I’d say go for it. (Saying those programs are to blame is probably obvious, but they’re not getting fixed so what can KDE do to mitigate the issues?)
Removing the other aspects (OSS, Alsa) at least would remove some of the complexity in options, and when it doesn’t work I know ifs PA’s issue and not something strange with Alsa going on (it’s always PA anyways). This would give the KDE audio people a single point to focus on for bug fixes etc.
Both Audacity and Flash support PulseAudio these days. Make sure the ALSA PulseAudio plugin is installed. (It should also be set up as the default device in ALSA. At least in Fedora, that is the default ALSA configuration.) Also make sure the applications are set up to use the default device (or the pulse device explicitly); again, they should be set up that way by default. And finally, if you are using 32-bit applications on a 64-bit system, make sure you also have the 32-bit versions of the ALSA PulseAudio plugin and of the PulseAudio libraries installed.
Pingback: Links 19/5/2012: Mandriva Linux Freed, New Linux Mint RC | Techrights
Just do it. Pulse 2.0 is awesome. There is no need for the duplication of effort. I’m a KDE man but I wish KDE would just leave pulse do it’s thing. It does a damn good job (esp in 2.0) Pulse should be your PRIMARY focus.
I use Kubuntu and PulseAudio has been working great for me, even when I plug in my wireless Airhead mic/headphones. Sometimes it mutes a channel, but that’s an easy fix.
I don’t understand the enthusiasm for pulseaudio. While it may be ok for purely domestic entertainment reasons, it’s completely useless for more dedicated audio and video applications. PA has something like a 2 second buffer that it tries to fill, and latency is frankly horrible. Try using midi or sync midi/audio/video with anything but jack, on linux.
Imho, there should be only one stack, and that’s a vastly improved ALSA. It’s not good at the moment for midi timing, and could do with a serious update.
But PA is not the answer, and was forced on users without consultation with other interested linux audio stack users groups.
Flame me all you want, but PA is inclusive, and excludes large chunks of the linux community by its very design. Imho, Poettering, backed by RH, wanted to impose this model on all, and got his wish.
I use Linux for a living, and have worked hard to support Linux publicly to engender a more positive contribution and perception of linux audio, midi, and video apps. There’s still some crud out there, and we’re still missing a few bits, but the introduction of PA set us all back a long way, and just made the process of growing the linux audio user base harder.
This is not a rant about PA’s poor introduction. This is a statement that the design is inherently poor, and will haunt linux in the future, imho.
We’re still no closer to a unified stack, and with the takeup of PA, now further away than ever.
I totally agree with you.
Trever, of course you can do your phonon-gstreamer-only-pulse backend… but please, do also a phonon-gstreamer-legacy(*) backend. Then we’ll choose the one that works better!
(*)without pulseaudio
I can live with the Gnome-Shell or Unity panel mixers not doing ALSA because everything still *works* without PA. And also because I’m not using Gnome-Shell or Unity much. If Phonon could only output to PA, it’d ruin KDE for me, and I’m not joking.
As an end-luser I can never make sense of what’s going on audio-wise when PA takes over.
Between on-board audio, “chosen” sound card and TV capture card, nothing’s named in PA with any reference to the actual devices. I have to infer it from the capabilities.
PA allows me to record from “microphone” or “monitor” only, with no apparent way to select-for-capture, mute, or change the individual levels of the line-ins, auxes, HD & optical whatsits and what have you as none of those exist… at least not in kmix (PA mode) or pavucontrol. If there’s a special way to get back control with PA that doesn’t involve somehow working around it by fiddling with the underlying ALSA stuff… I haven’t found it.
And if I have to kill the main sound server and apps with it every time I want to run JACK, ugh.
These extra hoops and extra headaches and the near-limitation to playback aren’t worth the advantages, especially since I haven’t needed those yet. I’m not an expert, but I can do everything with ALSA and very little with Pulse.
FYI, you can use
KMIX_PULSEAUDIO_DISABLE=1 kmixto get KMix in ALSA mode even when PulseAudio is running, though of course that’s still “working around it by fiddling with the underlying ALSA stuff”.mmmm… I’d like you explain why you don’t choose jack:
“JACK is system for handling real-time, low latency audio (and MIDI). It runs on GNU/Linux, Solaris, FreeBSD, OS X and Windows (and can be ported to other POSIX-conformant platforms). It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Its clients can run in their own processes (ie. as normal applications), or can they can run within the JACK server (ie. as a “plugin”). JACK also has support for distributing audio processing across a network, both fast & reliable LANs as well as slower, less reliable WANs. ”
however, whatever you choose, I hope you’ll provide also a classic version of phonon-gstreamer. I mean, today i can easily switch from phonon-gstreamer to phonon-vlc (or phonon-xine or phonon-mplayer)… Tomorrow i hope i can switch from phonon-gstreamer-pulseaudio to phonon-gstreamer-classic if i have problems… In fact, with two different phonon-gstreamer, we have a choice! and you can understand easily where are the bugs… and everybody is happy
Because JACK is designed for pro audio, not desktop audio.
if it’s designed for pro audio, so it’s not good enough for desktop audio?
Yes, the requirements are very different. Please read Lennart’s blog and/or listen to his recorded talks, he explained it in detail. The main point is: In pro audio, the one thing that counts is latency, and JACK’s design is completely based on that premise; in desktop audio, there are plenty of other issues which have higher priority.
Many thanks. BTW, this is the post, if anyone is interested:
http://0pointer.de/blog/projects/when-pa-and-when-not.html
@Trever
FWIW, I withdraw my objection
but please, support (for a while) also a phonon-gstreamer-legacy, for people having problems with PA. Many thanks
I use Audio app -> Phonon -> Phonon-vlc -> ALSA -> Speakers
Don’t touch my sauce! It has been working well for years.
Nobody is touching Phonon-VLC, this is only about Phonon-GStreamer.
As someone already noted, we on FreeBSD can’t force a dependency on PulseAudio, as it doesn’t always work, and because our OSS implementation works brilliantly on its own, without the need for any additional layer. And I know for sure that many happy KDE users would abandon it should they install PulseAudio. Plus, don’t forget how strongly Lennart advocates against continuing *BSD support: what if PulseAudio becomes Linux-only?
We have quite a lot of KDE users, and some KDE developers too. KDE software is fully supported on FreeBSD thanks to the work of several maintainers, and, of course, to the willingness of the KDE developers. Please, don’t invert this trend, and stop considering us second-class citizens.
No, sorry, FreeBSD is not dead at all, nor it is obsolete.
Of course, I thank you, Trever, for bringing up the discussion instead of stealthily committing a patch. I hope you will take into account our position.
Your friendly neighborhood KDE/FreeBSD maintainer.
P.S. Oh, ALSA is of no interest for us.
Pssh, I’d never stealthily commit something. I already have enough people hating me, why would I want more?
I’ve come up with a different plan though, I’ll explain in a blog post sometime this week. FreeBSD will become a first-class citizen, provided that GStreamer continues to support it as such.
I hope you don’t have people hating *you*.
Maybe someone hates your technical decisions… but not *you*.
I do have something on the order of three individuals at my university who really do hate me. Buy me some beer and I might divulge
at university? ahhhh! Easy to explain: they don’t really hate you… they are jealous of your talent!
Sounds promising! Thanks.
+1 from me as well.
That would also simplify things for me in the kde-telepathy call-ui, which uses GStreamer directly. Right now, if pulseaudio isn’t there, the code tries to retrieve phonon settings from phononserver over d-bus, but I doesn’t seem to work very well (because alsa devices simply suck). Officially deprecating ALSA support would be a step forward.
Do you have some bugs for that? I hadn’t heard of that issue, but I’m working on fixing and improving device selection and such in both pgst and libphonon.
If you could, ping me on IRC in an PM or something. I’m more likely to see them than on a blog post I occasionally check up on.