On Thu, Jul 18, 2013 at 07:05:16AM +0200, John Paul Adrian Glaubitz wrote: > Yeah, I see that. But my original point was that the many griefs and > complaints people about PulseAudio have originate from the fact that > many people already used it when it simply wasn't ready yet, so it's > not fair to use this as an argument against PA.
You suggest that PulseAudio is still not yet mature. The arguments Steve Langasek made and my clueless user experience indeed confirm that sentiment. What I do not understand here is why gnome is pulling it in as a dependency in a stable release then. In your reply to Wouter Verhelst you repeatedly argue how PulseAudio saves time on your end. As has been pointed out this matches neither Wouter's nor my experience. Clearly your claims are not universal. It appears that your use case is significantly different from Wouter's or mine. For instance installing PA breaks an existing mpd (and PA devs acknowledge that, fixing this is harder though due to the architecture). One of the main causes for grief with PA is that you cannot opt-in to it like you can with Jack. Like PA, Jack can implement the default alsa device, but it doesn't do that unless you ask it. Also you are in charge to decide when to start Jack. That removes a fair amount of debugging, because you can easily determine whether an issue is to be attributed to Jack or not. Just to be clear: Jack is not the solution here. It solves a different problem: low latency. As an aside note PA error messages smell badly. When running into a crash with gdb attached to PA, I am told that my alsa device is behaving strangely and that this surely is a bug in the alsa driver. The possibility that PA would be stopped for traceback investigation was simply not considered. How much time does it take to write a utility, that listens to sink state updates? It took me about three hours and a quite a bit of help from #pulseaudio. It does not work like you connect to the bus and listen for the signal. Instead you connect the session bus, to discover the bus address to connect to. Then you tell the core object that you want to receive signals for your sink and then you can actually listen for the signal. Solving the very same task with mpd for instance is radically easier. There are reasons for why so many steps are needed with PA, but those are not spelled out in the documentation. It also appears that much of the troubleshooting documentation concerning PA, that appears in Google, is seriously broken. Half of it advises modifying files in /usr, so it breaks when you upgrade the package. This applies especially to Ubuntu related docs. While PA is not responsible for this broken documentation, the creation was likely caused by absence of useful troubleshooting documentation on the side of PA. So PA is not removing complexity, but adding to it. Surely a bit of complexity is needed to solve sophisticated tasks, but it could indeed do better. For instance pacmd list-* could get some verbosity switches and hide some details in the default view. Scanning a pacmd list-sinks output for the relevant info just takes too long (in addition to needing to scroll the terminal). The sheer number of issues I find when investigating a supposedly mature project is stunning. Clearly PA does not "just work" for me and some others. On the bright side I can recommend upstreams irc channel and reported issues appear to get fixed quickly. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130719095652.ga19...@alf.mars
