Announcement

Collapse
No announcement yet.

"PulseAudio Is Still Awesome"

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mdias
    replied
    Originally posted by Azrael5 View Post

    Couldn't be use hardware mixing? Pulse audio take advntage from HARDWARE ACCELERATION?
    Most people nowadays use hardware that don't support multiple voices; therefore you can't do the mixing in hardware. The most probable cause that in ALSA you have low CPU overhead is because you're probably using dmix, which uses a low-quality-low-overhead resampler.

    Try to use the "trivial" resample method in PA and see if it helps. If CPU usage is still too high, file a bug report.

    Note that hardware mixing is (almost?) always inferior in quality than software mixing. Depending on your audio needs that might be irrelevant though.

    Leave a comment:


  • Azrael5
    replied
    Originally posted by alaviss View Post

    High CPU usage is normal since PA has to do software mixing. You can choose the most simple mixer to reduce PA CPU usage
    Couldn't be use hardware mixing? Pulse audio take advntage from HARDWARE ACCELERATION?

    Leave a comment:


  • rabcor
    replied
    I wonder how something that has not once since it's conception been awesome, can "still be" awesome. I think he means "just as awesome as always" which would be a sarcastic way of saying that pulseaudio still sucks just as much as ever.

    It's not people ranting and spreading FUD, it's people ranting and complaining about a product that has done nothing but get in their way and kill their audio quality. Sure, for some users pulse works fine, Paul Frields is clearly one of these people. But everytime I have personally tried to use pulseaudio, it has met me with high latency issues (sound lag) and in some slightly rarer cases, heavily reduced sound quality and/or buzzing sounds where there should be no sounds at all. Not to mention it is a nightmare to configure it, especially since some configuration options don't always work (and I'm talking about configuring it by editing the settings files, not using some GUI).

    And it doesn't take a smart person to see that overall, pulseaudio is a terrible sound server design, it's slow, it's fat, it's heavy and it really doesn't do anything in the long run, the only real use case I see for pulseaudio is streaming audio over network, that's it, that's the only thing I see it do that ALSA can't do on it's own, better than how Pulse does it. That's not FUD, that's just my factual experiences with sound on Linux. I'm not a huge fan of ALSA, but I really, really hate pulse.

    Leave a comment:


  • alaviss
    replied
    Originally posted by Azrael5 View Post
    I've noted, using Lubuntu some years ago, that implementing PULASE AUDIO, CPu usage increases considerably. What about KLANG development?
    High CPU usage is normal since PA has to do software mixing. You can choose the most simple mixer to reduce PA CPU usage

    Leave a comment:


  • Azrael5
    replied
    I've noted, using Lubuntu some years ago, that implementing PULSE AUDIO, CPu usage increases considerably. What about KLANG development?
    Last edited by Azrael5; 07 June 2015, 03:05 AM.

    Leave a comment:


  • LightBit
    replied
    Originally posted by fritsch View Post
    Please have a look here: http://kodi.wiki/view/PulseAudio - if it still does not work, drop me a message.
    Thanks for your concern, but currently pure ALSA works fine for my HTPC.

    Leave a comment:


  • Licaon
    replied
    and http://www.lwks.com/index.php?option...temid=81#93822

    Anyway, I heard you guys/gals, I'll reinstall PA and try again, with the Arch conf even. I'll report back.

    Leave a comment:


  • TeamBlackFox
    replied
    Originally posted by mdias View Post

    I don't really think it's a question of you being welcome or not. You are just complaining about something that looks to me like a somewhat easily solved problem by using an abstraction interface. Maybe PortAudio would suit you well; hard to tell without knowing the specifics of the problem you're solving in your apps.
    My applications aren't targeting Linux anymore, so the point is moot. I'd probably just run them through SDL if I needed more than the BSDs and commercial UNIX.

    Originally posted by mdias View Post
    I'll be honest and say I don't really see the purpose of the "Slave Sound Service" you describe, or how multithreading would help things here since it seems like all it does is pass the buffer to the "Master Sound Service". Seems like you have more layers in the system you thought up than what we currently have with App->PA--->ALSA->HW.

    No matter what you come up with, you will always have to implement a way to resample client streams to whatever your HW supports and is set to output.
    Most people also use onboard audio these days, and you don't get multiple voices/channels on those. And even if you did, the fact is that a software mixing+resampling solution is, most of the time, vastly superior to whatever resampling capabilities your multi-voice-multi-sample-rate sound card has. The only advantage of HW is speed, and thus low latency. That said my ALC889 can reach low latency with Jack and enabling rtirq.

    There really is no escape to separating normal users from pro users when it comes to audio.
    Normal users want it to just work, and for things to just work you need at least a system in place ready to resample your audio comming from multiple clients; they don't care about buffer sizes, periods or sample rate/format or who's mixing the audio. If you're a pro-audio user you'll just have to live with the current situation and use Jack; your software should work great with it too!

    ASIO also has limitations on windows, and it seems to be good enough for professionals...
    Sound in general isn't something I'm the most skilled with, so yeah, I'm not exactly the authority here, I'll be honest, that just was my brief, 15-minute solution I drew up. Mixing/resampling capabilities in software aren't my problem, its the fact that PA/ALSA isn't sufficient for the one-solution ideal at all.

    Redesigning a sound system to work quickly in userland with a fast, well documented protocol like STREAMS would be my ideal, including a real time sound latency guarantee from the system. In any case, as much as OSS is imperfect, it is a much, much simpler solution that is somewhat closer to an ideal vs Pulseaudio/ALSA.

    Leave a comment:


  • fritsch
    replied
    Originally posted by LightBit View Post
    Of course I prefer PCM over proprietary crap, however S/PDIF only supports stereo PCM and my amp doesn't have HDMI.
    Well, when I tried DTS(without MA) on Kodi with PulseAudio it sent stereo PCM over S/PDIF on amp and I thought this also applies for DTS. Maybe configuration was a problem. After removing PulseAudio DTS and Dolby Digital just works.
    Please have a look here: http://kodi.wiki/view/PulseAudio - if it still does not work, drop me a message.

    Leave a comment:


  • Ancurio
    replied
    It's funny how people are getting so up in arms about PA grabbing the ALSA device when that's exactly the same thing Xorg does with the DRI device =P Nobody seems to be complaining that only one process can claim and own a graphics card device at a time..

    Leave a comment:

Working...
X