PipeWire 0.3.43 Released With Many Fixes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bug77
    replied
    Originally posted by RahulSundaram View Post

    I would urge you to not repeat things others said without some informed understanding of the situation. For example, Jack advertises the capability to change buffer size on demand. Some applications including Ardour cannot handle this robustly always and can crash if you do this while the application is running. Does that mean Jack developers are advertising things incorrectly or lied about it? The more reasonable conclusion is the advertised capability isn't universally supported at the application level or entirely bug free.
    Trust me, I haven't said this lightly. In fact it's the first time I've mentioned it since my friend told me years ago.
    I also don't have a bone to pick with Mr. Pottering either. He makes stuff (and free stuff at that) and that's to be appreciated.

    Leave a comment:


  • mether
    replied
    Originally posted by bug77 View Post

    It wasn't about benchmarks, just basic capabilities. It seems the author has a thing about advertising things before they're actually implemented properly. This isn't first hand knowledge, but from a friend that was working in that area at the time. Make of it what you want.
    I would urge you to not repeat things others said without some informed understanding of the situation. For example, Jack advertises the capability to change buffer size on demand. Some applications including Ardour cannot handle this robustly always and can crash if you do this while the application is running. Does that mean Jack developers are advertising things incorrectly or lied about it? The more reasonable conclusion is the advertised capability isn't universally supported at the application level or entirely bug free.

    Leave a comment:


  • mether
    replied
    Originally posted by rabcor View Post

    How many of those features do you actually use regularly?
    You originally claimed the PulseAudio was just ALSA with more steps. Now you admit PulseAudio has more features but want to debate the feature usage. This is a different point but I will address it as well. The ones I listed are the ones I use regularly. Desktop users don't think the switching between say a speaker and a bluetooth headphone automatically is some sort of obscure feature. This is the reason why many major distributions (with millions of users easily) default to using PulseAudio or PireWire (which has even more features). Features you don't want, you don't use and it doesn't concern you. If distributions found it so buggy, they wouldn't keep continuing to use it for years with so many applications depending on it. The adoption is so entrenched that any Linux audio system in the future including PipeWire basically have to be PulseAudio compatible to gain any traction at all. So calling features not useful or the software very buggy strains credulity.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by rabcor View Post
    Then we do not need pulseaudio, we just need a very small improvement over alsa, it could be done in a very small program with very few points of failure instead of the huge clunky horror show that pulseaudio's codebase is.
    Yet no one ever wrote that in all the years that preceded pulse. And no one did that because it would not replace esound or dsound and thus zero (or close to zero) people would move over to this software, in any case it would never make the default.

    Leave a comment:


  • pal666
    replied
    Originally posted by rabcor View Post
    How many of those features do you actually use regularly? Sure, the per-application volume control is a feature that's very welcome, but the rest is stuff most people don't even know about, let alone use, and if it's just for per-application volume control at the expense of a buggy horrible mess that is likelier to break your sound than improve it (everytime i tested audio on just about any machine I have ever installed linux on ALSA always just worked when correctly configured but pulseaudio was a fucking mess that typically caused at the very least crackling noises in your audio streams which is not very nice.)
    If all the user really wants from pulse is dmixing and per application volume control, which would be what the vast 99% majority or so of just about every computer user would want (audio over network? really?) I remember actually trying to use pulseaudio for that once, and guess what, it didn't fucking work in the first place even if it's one of it's main advertised features, I looked all over for how to set it up but it just wasn't gonna happen!)

    Then we do not need pulseaudio, we just need a very small improvement over alsa, it could be done in a very small program with very few points of failure instead of the huge clunky horror show that pulseaudio's codebase is.
    how many clueless people like you can't use pulseaudio properly? almost nobody, therefore we don't need alsa and can ignore your noise

    Leave a comment:


  • pal666
    replied
    Originally posted by bug77 View Post
    This isn't first hand knowledge, but from a friend that was working in that area at the time. Make of it what you want.
    like your friend was lying or incompetent?

    Leave a comment:


  • pal666
    replied
    Originally posted by bug77 View Post
    Ubuntu didn't do a shitty job out of Pulse, Pulse was actually in a sorry state at first.
    pulse was in perfect state for pulse, ubuntu did a shitty job of switching to badly configured untested software

    Leave a comment:


  • pal666
    replied
    Originally posted by Alexmitter View Post
    I wonder when the counter-pipewire movement comes to life. What could it be, people favouring Pulse for arbitrary and mostly wrong reasons, a resurgence of directly using Also or maybe even a come back of OSS.
    artsd obviously

    Leave a comment:


  • pal666
    replied
    Originally posted by birdie View Post
    Blame me for pestering PW developers
    we probably also should blame people who opened 1839 prior issues

    Leave a comment:


  • rabcor
    replied
    Originally posted by RahulSundaram View Post

    PulseAudio has several improvements over plain ALSA and this is the reason major distributions use it by default and applications depend on it. These include per application volume control, rerouting audio over a network, moving sound streams between devices automatically and so forth. Calling it ALSA with extra steps is silly. PipeWire builds on this work because the PulseAudio already exercised more of the API and driver capabilities which have become more robust over the years.
    How many of those features do you actually use regularly? Sure, the per-application volume control is a feature that's very welcome, but the rest is stuff most people don't even know about, let alone use, and if it's just for per-application volume control at the expense of a buggy horrible mess that is likelier to break your sound than improve it (everytime i tested audio on just about any machine I have ever installed linux on ALSA always just worked when correctly configured but pulseaudio was a fucking mess that typically caused at the very least crackling noises in your audio streams which is not very nice.)
    If all the user really wants from pulse is dmixing and per application volume control, which would be what the vast 99% majority or so of just about every computer user would want (audio over network? really?) I remember actually trying to use pulseaudio for that once, and guess what, it didn't fucking work in the first place even if it's one of it's main advertised features, I looked all over for how to set it up but it just wasn't gonna happen!)

    Then we do not need pulseaudio, we just need a very small improvement over alsa, it could be done in a very small program with very few points of failure instead of the huge clunky horror show that pulseaudio's codebase is.

    Leave a comment:

Working...
X