Announcement

Collapse
No announcement yet.

PipeWire 0.3.31 Released With Better JACK Support, More Crash Fixes

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

  • jo-erlend
    replied
    Originally posted by nadro View Post
    Sorry for very delayed replay, I didn't noticed notification. I think that PipeWire may solve this issue, because my SSL2+ (it's class compliant device, so I don't need dedicated drivers) works great with PipeWire (2 mic / 2 line in inputs), but never worked fine with Audacity + PulseAudio.
    Thanks for your reply! I'm very much looking forward to testing this now.

    Leave a comment:


  • nadro
    replied
    Originally posted by jo-erlend View Post

    I have a Zoom H6 recorder, which has multiple inputs and I've tried to use it with Audacity, but only got one input. Do you think this might solve that? That would be so very cool! You really got my pulse going now.
    Sorry for very delayed replay, I didn't noticed notification. I think that PipeWire may solve this issue, because my SSL2+ (it's class compliant device, so I don't need dedicated drivers) works great with PipeWire (2 mic / 2 line in inputs), but never worked fine with Audacity + PulseAudio.

    Leave a comment:


  • rabcor
    replied
    Originally posted by oiaohm View Post

    https://github.com/PipeWire/pipewire...le-echo-cancel
    rabcor yes there is a early implementation. How to use it is critically missing documentation. Cancellation modes are still kind of limited.
    interesting, well, I can wait a bit longer, good to see it's being worked on

    Leave a comment:


  • oiaohm
    replied
    Originally posted by rabcor View Post
    I am just waiting for the echo cancellation module before switching to pipewire.
    https://github.com/PipeWire/pipewire...le-echo-cancel
    rabcor yes there is a early implementation. How to use it is critically missing documentation. Cancellation modes are still kind of limited.

    Leave a comment:


  • rabcor
    replied
    I am just waiting for the echo cancellation module before switching to pipewire.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mppix View Post
    @oiaohm
    @
    ssokolow
    The bug report mentions a 'flatpak alias' function. AFAIK, this is not done yet but it would get us at least halfway there.
    Now if the aliases would have an option to use both, the flatpak default reverse DNS or 'regular' DNS (to simplify auto-completion), this would be essentially done..
    After that, it would just be a ton of bug reports to solve the command line bugs as people would start using it..
    Just my 2c.
    That flatpak alias is not in fact what bug #1188 starting objective was.
    https://github.com/flatpak/flatpak/issues/1565
    It is 1565 but that is flatpak alias thing that is not implemented yet.

    The reality here is the refi64 commented on Oct 8, 2019 should have been a different bug report. The flatpak alias as not in fact addressing the problem listed at the start of bug. Please note 1565 was opened in Apr 10, 2018 so reli64 comment in 1188 is in fact duplication of existing feature not implemented. Yes if feli64 had created a new bug in 2019 it would have most likely been closed as a duplicate of 1565.

    Sorry this miss use of a bug system is abuse of the bug system. It also the bug system does not guide people hands well to show them they can open a new bug and link it to existing. So in case that you have a different idea that may solve the problem the smart and correct thing is in fact open new bug with the different solution and ask if this solution would fix problem.

    mppix sorry to say as you look at 1188 I understand why the person managing the bug system would just say its abused and close the bug due to it becoming a managed mess. The item you pulled is one of the abused cases where its not what the bug was about and there was existing bug open for that feature. The deep you dig into 1188 bug the more of these rabbit holes you find of existing open bug solutions being duplicated in 1188. This is not like please look at X bug to see if this solution will solve this problem but instead reduplication with no link to existing.

    I know its horrible the problem with bug triage at times you do have to be a total ass because like this 1188 the bug has gone off the rails best solution close the bug. Hopefully users will search the existing open and join the existing that match what they want or open a new bug that objective is clear not a muddled mess of different objectives.
    Last edited by oiaohm; 03 July 2021, 06:11 AM.

    Leave a comment:


  • mppix
    replied
    @oiaohm
    @
    ssokolow
    The bug report mentions a 'flatpak alias' function. AFAIK, this is not done yet but it would get us at least halfway there.
    Now if the aliases would have an option to use both, the flatpak default reverse DNS or 'regular' DNS (to simplify auto-completion), this would be essentially done..
    After that, it would just be a ton of bug reports to solve the command line bugs as people would start using it..
    Just my 2c.

    PS. yes, the behavior of some in the bug tracker is not acceptable. However, I can certainly understand the increasing frustration if this remains a wontfix.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    I know it's a hard problem... which is why the people who know Flatpak the best (the people who develop it) should be trying to solve it, rather than WONTFIXing it and calling "Flatpak still doesn't meet my needs with what you've done " abusive.

    There's a reason there's a difference between a feature request and a pull request. Something that's claiming its intent is to support end-users who aren't hardcore programmers can't then turn around and demand that real end-users of competing solutions must deliver a perfect pitch and proof of concept to have their use case accepted as valid.
    But you also have problem there that the bug report has tons of people pushing paths that can never work.

    Problem here the people who know Flatpak best being the developers don't have a good solution. The developer of flatpak solution is create a alias on need. Debian alternative system did not come from core debian developers at first. Debian alternative system came from a person building a stack of hacks that worked for most of the problem cases. This include what GUI the users would need.

    Just look over that bug report what was closed and the following abusive. Start of that bug report there is nothing mentioned about how to pass files into the sandbox safely for the command line. You might want some form of specialist command wrapper so user can pass any file into the flatpak without needing the file to be on a accessible path.

    The reality here not all bugs on open source applications are closed for fair reason. This case the bug has no sign that it will make any progress. The users wanting this feature are not providing any clear clarifications of what they are attempt to-do.

    https://github.com/flatpak/flatpak/issues/1188 if you go submit by submit on this bug carefully people are asking for 5 totally different things. One ask for that flatpak run lastbitafterdot works.

    The reality there the developers are not mind readers. Some of bugs you need to close why because they have become what called abusive/abused. Lot of people thing this abusive/abused means bad language it also means the ideal is muddled to the point that could not be sure of they have solved the issue of the bug or not. In case that it has muddled the correct thing is close the bug and hope another user opens a new bug with a lot clearer define of what they want.

    ssokolow something to be also be aware of they have the wontfix flag. This bug they closed and did not apply the wontfix flag. The reason closed being abusive is common miss read. Wine project changed to muddled a long time ago or closed requires splitting.

    ssokolow do read over 1188 and try to clear list of what everyone in fact wants that does not end up conflicting. There are just cases where a bug need to be closed because its no longer a useful for development. No longer useful for development does not mean the problems in the bug report are solved.

    Key point a bug report is meant to be a single definable problem 1188 is not that like it or not. If a bug is not a single definable problem its normally a bug being used to report multi issues in a single issue that is really attempting to abuse the bug system.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    Take a closer look at that bug report and the other bug reports opened over the CLI issue. There is a repeating fault that nothing being suggested is allowing of the complexity that flatpak is.

    I hope one day someone opens a CLI bug fix issue with flatpak that is properly considered.
    I know it's a hard problem... which is why the people who know Flatpak the best (the people who develop it) should be trying to solve it, rather than WONTFIXing it and calling "Flatpak still doesn't meet my needs with what you've done " abusive.

    There's a reason there's a difference between a feature request and a pull request. Something that's claiming its intent is to support end-users who aren't hardcore programmers can't then turn around and demand that real end-users of competing solutions must deliver a perfect pitch and proof of concept to have their use case accepted as valid.
    Last edited by ssokolow; 02 July 2021, 03:53 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    I'm well aware of the complexity involved in doing it properly. That's why I called what I did a hack.

    That doesn't change the fact that, as an end user, it's an uphill battle to make Flatpak-installed applications suitable for some uses and I only have so much time to spare.
    Take a closer look at that bug report and the other bug reports opened over the CLI issue. There is a repeating fault that nothing being suggested is allowing of the complexity that flatpak is.

    I hope one day someone opens a CLI bug fix issue with flatpak that is properly considered.

    Leave a comment:

Working...
X