Page 6 of 8 FirstFirst ... 45678 LastLast
Results 51 to 60 of 75

Thread: Adobe's Linux Video API Rant Extended

  1. #51
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Other notable missing items are phonon, AOSS, xine, mplayer backend, vlc backend, etc. That diagram is basically a promo advertisement for pulseaudio (which still has a loooooooooong ways to go). There is no denying that audio really is a mess in linux with so many duplicated efforts with many overlapping projects. There really should be no reason why kernels have to be recompiled for example when a low latency connection is warranted. Quicktime, AISO, kernel streaming for example don't require a different kernel for the other OS's. I have thought many times that the COMPLETE audio has to be redone in linux scrapping legacy compatibility to get it up to the competitions capability. One of the most frustrating things about linux and other free OS's is their insistent wanting of maintaining compatibility no matter the cost to end performance.

  2. #52
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by deanjo View Post
    I have thought many times that the COMPLETE audio has to be redone in linux scrapping legacy compatibility to get it up to the competitions capability. One of the most frustrating things about linux and other free OS's is their insistent wanting of maintaining compatibility no matter the cost to end performance.
    But this approach is what has largely led to the situation we have now IMHO.

    The unwillingness to properly fleshout a current implementation of something, and instead re-invent the wheel with yet another half-arsed implementation which also doesn't get properly finished before yet another "new from scratch" attempt is taken.

    If Linux audio is to get to a "finished" state, maybe new blood needs to be added to some of the current "solutions"(lol) that are already in place.

  3. #53
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by mugginz View Post
    But this approach is what has largely led to the situation we have now IMHO.

    The unwillingness to properly fleshout a current implementation of something, and instead re-invent the wheel with yet another half-arsed implementation which also doesn't get properly finished before yet another "new from scratch" attempt is taken.

    If Linux audio is to get to a "finished" state, maybe new blood needs to be added to some of the current "solutions"(lol) that are already in place.

    As far as I've seen over the many years there has been only "bandaid" solutions presented (PulseAudio being the bandaid of all bandaids).

  4. #54
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

    Quote Originally Posted by deanjo View Post
    I have thought many times that the COMPLETE audio has to be redone in linux scrapping legacy compatibility to get it up to the competitions capability. One of the most frustrating things about linux and other free OS's is their insistent wanting of maintaining compatibility no matter the cost to end performance.
    There's nothing wrong with *some* of the current API's (with ALSA being the ugly exception). Instead of re-inventing something again, you should whine about the broken implementations instead. For example, the OSS4 and PulseAudio APIs are just fine. Problem is, they're anything but rock-solid software. Instead of coming up with yet another API that looks sweet and nice but comes with a sucks-ass implementation of it, better fix what's there.

    And somebody please kill ALSA. Thanks.

  5. #55
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by deanjo View Post
    As far as I've seen over the many years there has been only "bandaid" solutions presented (PulseAudio being the bandaid of all bandaids).
    Well, I do like the feature set of PulseAudio.

    I've found it to be the only workable solution with regard to bluetooth headsets. It now nicely auto configs a newly turned on headset into the audio system, and am now very happy skype supports Pulse directly. Being able to dynamically route audio around via a GUI is also very nice. As far as dmix functionality is concerned, I've found ALSA and PulseAudio mostly on par with each other.

    It's the feature set of PulseAudio I want, not necessarily the current implementation. If it is to be re-factored, it needs to be done in a digestible way that doesn't go and rebreak everything again. I think that would be the last straw for a lot of Linux users.


    When Pulse works it's a thing of beauty. When it doesn't, it sh*ts me but that's mostly an implementation quality proposition from what I can tell. I think they need to finish Pulse, as in get it completely debugged for all common use cases and normal system environments.

    I do wonder about your point about low-latency drivers and the need to flip and flop between kernels in order to create a particular environment though. In my view you have a very valid point but it's one I hope that can be solved without requiring app developers to come to grips with another sound API.

  6. #56
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by RealNC View Post
    There's nothing wrong with *some* of the current API's (with ALSA being the ugly exception). Instead of re-inventing something again, you should whine about the broken implementations instead. For example, the OSS4 and PulseAudio APIs are just fine. Problem is, they're anything but rock-solid software. Instead of coming up with yet another API that looks sweet and nice but comes with a sucks-ass implementation of it, better fix what's there.

    And somebody please kill ALSA. Thanks.

    Well I have to respectfully disagree on you there, ALSA has been kind to me over the years where as OSS has not. Although I do admit that OSS has a simplicity about it development wise but once it starts to get into the advanced specific features of a card it leaves much to be desired.

  7. #57
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by mugginz View Post
    It's the feature set of PulseAudio I want, not necessarily the current implementation. If it is to be re-factored, it needs to be done in a digestible way that doesn't go and rebreak everything again. I think that would be the last straw for a lot of Linux users.
    Pulse is a great idea, just poorly implemented. Their efforts IMHO would have been better off put towards improving ALSA's weak points on a low level implementation

  8. #58
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by deanjo View Post
    Pulse is a great idea, just poorly implemented. Their efforts IMHO would have been better off put towards improving ALSA's weak points on a low level implementation
    Must agree with you there. When I heard what they were doing with Pulse instead of fixing ALSA I was a bit disappointed but now we're here with respect to PulseAudio over ALSA as the chosen one, I guess I'm just hoping they will eventually correct the flaws in the current implementation and then maybe people can worry less about Linux audio and focus on areas that are yet to be solved.

  9. #59
    Join Date
    Aug 2008
    Posts
    99

    Default

    What's with the hatred toward ALSA? It's a decent low-level API on which someone could implement a user-friendly GUI.

    My main complaints with the current state of things:

    PulseAudio and JACK are completely separate projects, so I have to kill pulse and start jackd when I want to have low-latency audio.

    PulseAudio keeps screwing up the low-level mixer settings on my emu10k1 without exposing those settings through the GUI.

    PulseAudio doesn't appear to take advantage of hardware mixing on cards that support it.

  10. #60
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by unix_epoch View Post
    What's with the hatred toward ALSA? It's a decent low-level API on which someone could implement a user-friendly GUI.
    I don't think most people hate ALSA per se, but rather that ALSA turned into a practical requirement when neither the in-kernel OSS emulation nor the major DEs' sound servers provided decent support for OSS apps (e.g. noticeable latency, only one OSS app at a time, requiring OSS apps to be launched with a wrapper program, etc.).

Tags for this Thread

Posting Permissions

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