Page 3 of 10 FirstFirst 12345 ... LastLast
Results 21 to 30 of 93

Thread: Wine Developers Fight Over PulseAudio Driver

  1. #21
    Join Date
    Jan 2009
    Posts
    464

    Default

    Can someone correct my understanding?

    Also provides the driver to the hardware. The result is that you get a device to which only a single application can connect. Example "Card 0"
    Also provides the ability to define multiple 'virtual' devices via the .asoundrc which attach to the card via dmix (Example vcard0, vcard1, vcard2)
    Each application needs to communicate with it's own individual VCard.
    Pulse creates a single interface (PVcard0) to which all applications can connect. It does it's own mixing, sample rate conversion, and sends it to Alsa's "Card 0"

    Is this correct?

    F

  2. #22
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by russofris View Post
    Can someone correct my understanding?

    Also provides the driver to the hardware. The result is that you get a device to which only a single application can connect. Example "Card 0"
    Also provides the ability to define multiple 'virtual' devices via the .asoundrc which attach to the card via dmix (Example vcard0, vcard1, vcard2)
    Each application needs to communicate with it's own individual VCard.
    Nope. All applications open a single device. Output to that device is then mixed together by dmix.

  3. #23
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by asdx View Post
    So Wayland should not exist because there is X and Wayland is trying to replace X' API?
    X isn't getting fixed because of all the legacy stuff in it. ALSA doesn't have that problem.

    Your analysis is shit. PA has fixed most of ALSA and works really well for most people so shut the fuck up.
    PA doesn't fix ALSA, it replaces it, so blow me and go fuck yourself, you piece of shit.

    PS:
    Apologies to the other readers for having to read this. I always respond in kind.
    Last edited by RealNC; 06-27-2012 at 04:23 PM.

  4. #24
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by RealNC View Post
    It matters because now it's not guaranteed that PA is installed. So developers need to implement ALSA as well as PA support.
    No they don't. PulseAudio is installed by default on every distribution that matters and you can simply depend libpulse and then even setups that do not have PulseAudio should work.


    Quote Originally Posted by RealNC View Post
    No, ALSA also does the mixing (dmix) and provides lots of plugins in libalsa. PA tries to fix the problems in those parts of ALSA, problems that should not exist to begin with. PA exists because of problems in ALSA.
    Dmix is a dirty hack that doesn't work well in multichannel setups for example. PulseAudio does the mixing like it should be done and it also supports numerous features that are not available for any other audio server for Linux. There's a reason why it's used by default in just about every single Linux distribution and mobile operating system (maemo, webOS, Mer, MeeGO, Tizen...) out there. It's simply the superior solution.

    Quote Originally Posted by RealNC View Post
    All stuff that ALSA should be handling to begin with.
    Having all these features in kernel would make no sense what-so-ever and if they are implemented in user space they can as well be in PulseAudio.

    Quote Originally Posted by RealNC View Post
    Applications don't have to deal with it. Whatever it does, it does it transparently.
    So does PulseAudio... seriously what are you talking about?

    Quote Originally Posted by RealNC View Post
    PA is not ASIO or ReWire. PA is trying to be the new ALSA. Which is wrong.
    The developement of PulseAudio started in year 2004 and it has been used exlusively for the past five years. ALSA has established itself as userspace interface for kernel drivers for other audio servers like PulseAudio and Jack to use. You subjective opinion of something being wrong doesn't really hold much value in this case and seriously what is your point here? Should we just throw away all the developement that has happenend in Linux audio stack for the past years and go back fixing some unfixable mess that isn't even used anymore?

  5. #25
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by Teho View Post
    No they don't. PulseAudio is installed by default on every distribution that matters and you can simply depend libpulse and then even setups that do not have PulseAudio should work.
    Yes, though many users remove it. And since now you can create a setup where ALSA applications can be redirected seamlessly to PulseAudio, it makes more sense to support ALSA only. The PA API makes less sense now.

    Dmix is a dirty hack that doesn't work well in multichannel setups for example. PulseAudio does the mixing like it should be done
    But dmix should have done that to begin with.

    and it also supports numerous features that are not available for any other audio server for Linux. There's a reason why it's used by default in just about every single Linux distribution and mobile operating system (maemo, webOS, Mer, MeeGO, Tizen...) out there. It's simply the superior solution.
    It does solve a whole lot of problems. But it does that using the wrong approach. The userspace part of ALSA should be doing that. Everything should be nicely integrated using a single API instead of two.

    Having all these features in kernel would make no sense what-so-ever and if they are implemented in user space they can as well be in PulseAudio.
    I do agree. But you're forgetting that ALSA-lib was created to handle all the userspace stuff. ALSA has two parts, one in kernel space, one in user space. PA is trying to replace the user space part of ALSA. It would make more sense to enhance user space ALSA instead of replacing it.

    So does PulseAudio... seriously what are you talking about?
    I am talking about an unneeded API.

    The developement of PulseAudio started in year 2004 and it has been used exlusively for the past five years. ALSA has established itself as userspace interface for kernel drivers for other audio servers like PulseAudio and Jack to use. You subjective opinion of something being wrong doesn't really hold much value in this case and seriously what is your point here? Should we just throw away all the developement that has happenend in Linux audio stack for the past years and go back fixing some unfixable mess that isn't even used anymore?
    There's two approaches to fixing something. a) try to fix the existing code and b) rewrite the existing code. PA did neither. It just threw another API in there. So when something turns up in PulseAudio that doesn't work well in the future, let's create yet another one. We'll call it NewAwesomeAudio which replaces PulseAudio. And later, when problems with that turn up, we'll go for yet another new API.

    No. If there's a problem, fix it.

  6. #26
    Join Date
    Jan 2009
    Posts
    464

    Default

    Lol, Safari auto corrected "Alsa" to "Also".

  7. #27
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by asdx View Post
    YOU are the piece of shit. Nobody would blow you anything, since you probably have a 1-inch penis.

    Go fuck yourself and kill yourself or die in a fire you pathetic, piece of shit loser.
    Can't we all just hug and get along?

  8. #28
    Join Date
    Dec 2010
    Location
    milky way
    Posts
    1

    Default

    Quote Originally Posted by asdx View Post
    YOU are the piece of shit. Nobody would blow you anything, since you probably have a 1-inch penis.

    Go fuck yourself and kill yourself or die in a fire you pathetic, piece of shit loser.
    hey guys come down and don't talk like winDOS people. !rolleyes!

  9. #29
    Join Date
    Jan 2009
    Posts
    464

    Default

    Quote Originally Posted by RealNC View Post
    Nope. All applications open a single device. Output to that device is then mixed together by dmix.
    Are you certain? Then why does PA exist? I was under the impression that this was the major obstacle that PA was created to overcome. I distinctly recall having to mess around with my .asoundrc and creating multiple virtual cards in order to get two applications to playback simultaneously under Alsa, and to assign a volume to each individual application. This was some time ago though (2006-ish).

    F

  10. #30
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by RealNC View Post
    Yes, though many users remove it. And since now you can create a setup where ALSA applications can be redirected seamlessly to PulseAudio, it makes more sense to support ALSA only. The PA API makes less sense now.
    I don't think so. PulseAudio is still the de facto audio server so supporting it as well as possible should be the top priority.

    Quote Originally Posted by RealNC View Post
    There's two approaches to fixing something. a) try to fix the existing code and b) rewrite the existing code. PA did neither. It just threw another API in there. So when something turns up in PulseAudio that doesn't work well in the future, let's create yet another one. We'll call it NewAwesomeAudio which replaces PulseAudio. And later, when problems with that turn up, we'll go for yet another new API.
    PulseAudio takes radically different approach to the problem than ALSA so just rewriting stuff isn't possible. I still don't understand why you think that ALSA API is the end of all Linux audio APIs. I mean seriously even if ALSA was extended so far that it would resemble the PulseAudio we have now its APIs would have probably changed completely anyway.

    Quote Originally Posted by RealNC View Post
    No. If there's a problem, fix it.
    PulseAudio did just that.

Posting Permissions

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