Page 1 of 2 12 LastLast
Results 1 to 10 of 87

Thread: PulseAudio 2.0 Runs On HURD, Has Jack Detection

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,677

    Default PulseAudio 2.0 Runs On HURD, Has Jack Detection

    Phoronix: PulseAudio 2.0 Runs On HURD, Has Jack Detection

    Today's certainly an interesting day for some prominent and long-awaited Linux software events. Aside from PowerTOP 2.0, ConnMan 1.0, and the merging of Clover-G3D, PulseAudio 2.0 also made it out the door...

    http://www.phoronix.com/vr.php?view=MTEwMTM

  2. #2
    Join Date
    Jun 2011
    Location
    Barcelona
    Posts
    74

    Default

    Linux sound stack needs an overhaul. Too many abstraction layers

  3. #3
    Join Date
    Jan 2010
    Location
    Somewhere in Kansas.
    Posts
    294

    Default

    Ah. I wonder if microphone input will now work with pulse audio. :-(

  4. #4
    Join Date
    Jan 2010
    Posts
    160

    Default

    hopefully there are less bugs and that it won't end up making it more notorious than this audio server once was in its early days.
    Are you kidding me?! It is still a horrible mess! I've just tried it 3 month ago.

    Pulseaudio is in many parts duplicating work that is already present in ALSA and doing it worse.

    Pulseaudio should focus on being just an audio server with per application sound levels and network transparency. Also it shouldn't try try manage "every" sound output. Programs that don't directly support it shouldn't be touched by it, that is what creates this mess in the first place.

    While at the same time ALSA should make its advanced settings more easily available. Normalizing, noise cancellation, surround sound, all this is already possible with ALSA it is only hard to write into your .asoundrc we actually need a program that is able to create this file automatically depending on the users preferences.

    I would actually love to have a good sound-server on my Linux boxes, but every time I try Pulseaudio it only creates a mess.
    Last edited by Ragas; 05-11-2012 at 04:43 PM.

  5. #5
    Join Date
    Jun 2008
    Location
    Edinburgh, Scotland
    Posts
    455

    Default

    I've been running 1.99.2 since its release with no trouble so this is hopefully a solid upgrade for anyone already using it.

  6. #6
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by Ragas View Post
    Are you kidding me?! It is still a horrible mess! I've just tried it 3 month ago.
    Therein lies your problem -- you're "trying" it rather than actually using it. Don't just give it 5 seconds every 3 months and decide you hate it. Confirmation bias: if you go into it disliking it, you're going to hate it no matter what it does.

    Quote Originally Posted by Ragas View Post
    Pulseaudio is in many parts duplicating work that is already present in ALSA and doing it worse.
    Nonsense. It doesn't duplicate anything ALSA does. ALSA provides the low-level hardware access; PulseAudio makes it usable. You have no idea what you are talking about. And before you say that PA can do software mixing, don't kid yourself -- dmix is NOT a viable option. dmix is a nasty hack. It has 100 times more bugs than PA; it doesn't even work with half of the ALSA apps let alone anything else! And it has a fixed (high) amount of latency and does not handle dropouts (whole-system / kernel lags) well at all. I've also noticed that dmix tends to interfere with some applications because it does so much "in-process". It basically just tickles a shared memory segment and you'd be lucky if a bunch of applications can "cooperate" on this. Easy to screw it up.

    Quote Originally Posted by Ragas View Post
    Pulseaudio should focus on being just an audio server with per application sound levels and network transparency. Also it shouldn't try try manage "every" sound output. Programs that don't directly support it shouldn't be touched by it, that is what creates this mess in the first place.
    It doesn't try to manage anything. It's up to the app if it wants to connect to PA or not. PulseAudio can't help it that ALSA doesn't have built-in software mixing; apps that want to hook into hw:0 are broken by design (not only PA authors agree with this, also the ALSA developers agree with this) because direct hardware access is supposed to be reserved for infrastructure such as PA itself.

    Oh, and most users will want the exact opposite than you: they want all their apps to route through PA so that they can control all the volumes in the same place, and only have to deal with one set of configuration: PA's, which is in a real nice GUI. So distros configure apps so that most apps will play through PA out of the box. This is the right approach IMHO.

    Quote Originally Posted by Ragas View Post
    While at the same time ALSA should make its advanced settings more easily available. Normalizing, noise cancellation, surround sound, all this is already possible with ALSA it is only hard to write into your .asoundrc we actually need a program that is able to create this file automatically depending on the users preferences.
    Most of ALSA's "support" for these features is a joke. This code is not really maintained and doesn't work with software mixing, well or at all. Also, in case you didn't notice, having to manage configuration files that are touched by lots of programs is an absolute nightmare. Why do you think X.Org is trying to get people to stop using xorg.conf ? Because it's a mess and it's much easier to auto-detect the right settings and let the user change them at runtime with a GUI. This is why it's very easy to write a GUI to configure your monitors with xrandr, but very hard to write a GUI to configure your screens with xorg.conf (iirc only SUSE still supports that and I think they even deprecated YaST's support for xorg.conf recently... it was called SaX2 iirc).

    Quote Originally Posted by Ragas View Post
    I would actually love to have a good sound-server on my Linux boxes, but every time I try Pulseaudio it only creates a mess.
    Only someone who runs an app that is poorly coded to force initializing hw:0 would say something like this. If all you use are apps that are compatible with PA by either using the "Safe ALSA Subset" or PA directly or any of its downstream consumers (openal-soft, SDL, wine, etc), then you have no reason to complain about PA because it "just works".

    If you're still running an app like this, well, stop it! Or tell it to use OSS and install OSS Proxy, which routes through the kernel (CUSE) and back to PA in userspace. But the number of apps that do this is rapidly decreasing these days, and I've stopped needing to do this at all since about 2010.

    Old unmaintained apps need to be dead and buried. The stack is a moving target and the only apps that deserve to be run are those that are maintained and continue to evolve with the stack. Standing still is for proprietary dinosaurs that will soon be extinct.

  7. #7
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Quote Originally Posted by allquixotic View Post
    don't kid yourself -- dmix is NOT a viable option. dmix is a nasty hack. It has 100 times more bugs than PA; it doesn't even work with half of the ALSA apps let alone anything else! And it has a fixed (high) amount of latency and does not handle dropouts (whole-system / kernel lags) well at all. I've also noticed that dmix tends to interfere with some applications because it does so much "in-process". It basically just tickles a shared memory segment and you'd be lucky if a bunch of applications can "cooperate" on this. Easy to screw it up.
    Very well, but I wonder what your problem with dmix is? It may be a hack but I don't recall having problems with it. It just worked for me, too.

    Quote Originally Posted by allquixotic View Post
    Most of ALSA's "support" for these features is a joke. This code is not really maintained and doesn't work with software mixing, well or at all. Also, in case you didn't notice, having to manage configuration files that are touched by lots of programs is an absolute nightmare. Why do you think X.Org is trying to get people to stop using xorg.conf ? Because it's a mess and it's much easier to auto-detect the right settings and let the user change them at runtime with a GUI. This is why it's very easy to write a GUI to configure your monitors with xrandr, but very hard to write a GUI to configure your screens with xorg.conf (iirc only SUSE still supports that and I think they even deprecated YaST's support for xorg.conf recently... it was called SaX2 iirc).
    I think the better point is that you have to restart the sound output of every application that uses alsa when changing the .asoundrc.

    Also, pulseaudio seems to be able to set LADSPA effects too. At least the latest veromix has a gui for it, but it doesn't work for me yet.

  8. #8
    Join Date
    Jan 2010
    Posts
    160

    Default

    Quote Originally Posted by allquixotic View Post
    Therein lies your problem -- you're "trying" it rather than actually using it. Don't just give it 5 seconds every 3 months and decide you hate it. Confirmation bias: if you go into it disliking it, you're going to hate it no matter what it does.
    I've tried it for one month. There are a lot of workarounds needed to get every application working. And when you look into the ubuntu repositorys, what they have done to gt all this stuff working .... no thanks.

    Quote Originally Posted by allquixotic View Post
    And before you say that PA can do software mixing, don't kid yourself -- dmix is NOT a viable option. dmix is a nasty hack. It has 100 times more bugs than PA; it doesn't even work with half of the ALSA apps let alone anything else!
    It's weird then that dmix works with all applications that I have ever seen and PA does not, isn't it?
    I have a 7.1 surround sound setup with normalization over here.

    I don't know about latency, may be worse than PA but it's certainly not too much.


    Quote Originally Posted by allquixotic View Post
    It doesn't try to manage anything. It's up to the app if it wants to connect to PA or not.
    Nope, it replaces the default pcm of Alsa, so it really does try to manage everything. If you don't want that you will have to start creating workarounds. which can be quite funny considering that it's not that easy for every program to tell it that it shouldn't connect to the default pcm.

    Quote Originally Posted by allquixotic View Post
    PulseAudio can't help it that ALSA doesn't have built-in software mixing; apps that want to hook into hw:0 are broken by design (not only PA authors agree with this, also the ALSA developers agree with this) because direct hardware access is supposed to be reserved for infrastructure such as PA itself.
    O come on you talk about dmix and then you are saying that "ALSA doesn't have built-in software mixing"? Please be reasonable.
    We can agree on the HW:0 thing though.

    Quote Originally Posted by allquixotic View Post
    Oh, and most users will want the exact opposite than you: they want all their apps to route through PA so that they can control all the volumes in the same place, and only have to deal with one set of configuration: PA's, which is in a real nice GUI. So distros configure apps so that most apps will play through PA out of the box. This is the right approach IMHO.
    Please read my post again. I'm explicitly saying that I want that too. An a real nice gui is a real nice thing but it really is not essential. I want that stuff to work and after that we can make the real nice gui. And working it is definitely not with Pulseaudio.

    Quote Originally Posted by allquixotic View Post
    Most of ALSA's "support" for these features is a joke. This code is not really maintained and doesn't work with software mixing, well or at all.
    Actually I've had some problems in the past. But the corresponding bugs are fixed now and it works at least for me.

    Quote Originally Posted by allquixotic View Post
    Also, in case you didn't notice, having to manage configuration files that are touched by lots of programs is an absolute nightmare. Why do you think X.Org is trying to get people to stop using xorg.conf ? Because it's a mess and it's much easier to auto-detect the right settings and let the user change them at runtime with a GUI. This is why it's very easy to write a GUI to configure your monitors with xrandr, but very hard to write a GUI to configure your screens with xorg.conf (iirc only SUSE still supports that and I think they even deprecated YaST's support for xorg.conf recently... it was called SaX2 iirc).
    Well you are probably right with that.


    Quote Originally Posted by allquixotic View Post
    Only someone who runs an app that is poorly coded to force initializing hw:0 would say something like this. If all you use are apps that are compatible with PA by either using the "Safe ALSA Subset" or PA directly or any of its downstream consumers (openal-soft, SDL, wine, etc), then you have no reason to complain about PA because it "just works".
    Nope. I have no such program ... haven't stumbled upon one in a looooooong time. But PA still doesn't "just" work. try looking into some of the distributions repositories for how many workarounds there are in place. Wine is a nice example.

    I probably could also live with it if every application would start using pulseaudio exclusively but we are still not at that point.

  9. #9
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    646

    Default

    Quote Originally Posted by Ragas View Post
    Are you kidding me?! It is still a horrible mess! I've just tried it 3 month ago.

    Pulseaudio is in many parts duplicating work that is already present in ALSA and doing it worse.

    Pulseaudio should focus on being just an audio server with per application sound levels and network transparency. Also it shouldn't try try manage "every" sound output. Programs that don't directly support it shouldn't be touched by it, that is what creates this mess in the first place.

    While at the same time ALSA should make its advanced settings more easily available. Normalizing, noise cancellation, surround sound, all this is already possible with ALSA it is only hard to write into your .asoundrc we actually need a program that is able to create this file automatically depending on the users preferences.

    I would actually love to have a good sound-server on my Linux boxes, but every time I try Pulseaudio it only creates a mess.
    I'm not arguing a point, but keep in mind that other people's experience (E.g. me) is *radically* different that yours and in many cases, issues can be solved or triggered by the distribution itself.
    Case of point: my workstation has 3 sound devices:
    1. Audigy 2SZ connected to 5.1 setup.
    2. On-boad 5.1 HDA care connected to a remote speaker.
    3. USB webcam with built in mike.

    With ALSA trying to get the setup working was a pure mess, dminx, numerous .asoundrc's - and it never really worked right.
    With Pulse, especially in recent Fedora releases everything works *out of the box* with zero configuration on my end.
    I can move audio from one device to another (In reality - from one speaker set to another).
    I can have two active (or actually 3) streams working simultaneously with zero configuration.
    ... And last and not least, I have a *reliable* method to give different volume levels to different streams.

    ... Now, YMMV or actually, your millage may be radically different, but keep in mind that for many people latest revisions of Pulse simply work.

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

  10. #10
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,672

    Default

    Quote Originally Posted by gilboa View Post
    I'm not arguing a point, but keep in mind that other people's experience (E.g. me) is *radically* different that yours and in many cases, issues can be solved or triggered by the distribution itself.
    Indeed. I have 3 machines I tried to use PulseAudio on. My main PC, with two cards, had certain issues. My tablet PC had huge issues (even system sound didn't play correctly out of the box). But the laptop works with it flawlessly, I never had to change a thing to make it work there. And all of these machines use the same distribution.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •