Tweet
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.
-
-
But this approach is what has largely led to the situation we have now IMHO.Originally posted by deanjo View Post
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.
Comment
-
Originally posted by mugginz View PostBut 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).Comment
-
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.Originally posted by deanjo View Post
And somebody please kill ALSA. Thanks.Comment
-
Well, I do like the feature set of PulseAudio.Originally posted by deanjo View Post
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.Comment
-
Originally posted by RealNC View Post
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.Comment
-
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 implementationOriginally posted by mugginz View PostComment
-
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.Originally posted by deanjo View PostComment
-
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.Comment
-
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.).Originally posted by unix_epoch View PostComment
Comment