Adobe's Linux Video API Rant Extended

[mugginz]

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.

[RealNC]

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.

[deanjo]

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).

[mugginz]

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.

[deanjo]

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.

[deanjo]

As well as the direct connections from audio libraries to Alsa

[deanjo]

Why on earth did you gray-out OSS there? If you're gonna correct the original "messed-up" diagram, at least don't cheat.

Seems to be missing a few connections as well such as Jack--->ALSA and the loopbacks of course.

[RealNC]

Why on earth did you gray-out OSS there? If you're gonna correct the original "messed-up" diagram, at least don't cheat.

[Remco]

Decided to pay absolutely zero attention to that guy after his "Welcome to the jungle" post where he showed himself to be completely ignorant / disingenuous (see: http://blogs.adobe.com/penguin.swf/linuxaudio.png).

That diagram is intentionally complicated. It's easy to create a much clearer diagram with few modifications:


It's all about layout and not trying to show everything.

[unix_epoch]

Mike's rant refers to "other stuff" that has to be done to the video on the CPU. The only thing Flash does out of the ordinary that I'm aware of, is its ability to encode a video alpha channel separately from the main video stream, and use that alpha channel to composite the video with whatever's behind it. Is there an OpenGL texture format that allows a separate alpha channel to be used? Or, if not, I'm sure a pixel shader could do it.