Linked by Thom Holwerda on Sat 27th Sep 2008 22:14 UTC, submitted by diegocg
Lennart Poettering, main programmer of the PulseAudio project, has written a 'Guide Through The Linux Sound API Jungle': "At the Audio MC at the Linux Plumbers Conference one thing became very clear: it is very difficult for programmers to figure out which audio API to use for which purpose and which API not to use when doing audio programming on Linux. So here's my try to guide you through this jungle."
Thread beginning with comment 331921
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-06-28
Well, nobody is recommending to "load Qt just for Phonon", that wouldn't make any sense.
But claiming there is an extra Qt overhead for Phonon when already using Phonon is quite imaginative.
And your original psot had at least this part of inaccuracy: "... pointless extra overhead if you're not running KDE."
But claiming there is an extra Qt overhead for Phonon when already using Phonon is quite imaginative.
And your original psot had at least this part of inaccuracy: "... pointless extra overhead if you're not running KDE."
you obviously have a language comprehension problem. i did NOT in any way say anything inaccurate. you're simply twisting my words to fit your twisted logic. i said nothing about extra "QT overhead for Phonon when already using Phonon". the exact opposite is true. i made it very clear that neither QT or Phonon are being used to any great extent in professional audio applications. pro audio applications on linux tend to rely on ALSA + JACK + a light widget toolkit. this simplicity improves responsiveness and latency in the recording studio. adding another heavy toolkit or sound api will only eat CPU cycles and RAM, which is never good for a studio. that is extremely accurate.
the reason why i said that it's pointless extra overhead if you're not running KDE is because right now, the KDE project is the only project using phonon! therefore, unless some developer is targeting KDE as their platform of choice for a pro audio app (which, trust me, they probably AREN'T) there is no incentive to deviate from the ALSA + JACK stack. doing so would only suck down resources for the end-user.
i have never put down phonon, or QT, in the many pages of this thread. my comments have been very specifically centered around a very particular niche: pro audio. phonon is NOT the perfect fit in this scenario. to misrepresent my comments as anything but that is preposterous.
don't twist my words. it really irks me.
Member since:2005-07-06
my comments have been very specifically centered around a very particular niche: pro audio. phonon is NOT the perfect fit in this scenario.
And this is your strawman argument, nobody is suggesting anywhere that you should use Phonon for pro audio(or video) applications.
Quite the opposite in fact, the Phonon developers, Aaron and every other Qt/KDE developer discussing Phonon points this out in a very clear manner. Those applications are the remaining 1% which Phonon was not designed for from the start, but for the remaining 99% Phonon is a very good choice.
Regardles of Phonon, without it Qt(and KDE) are still a very good choice for those pro audio and video applications. As seen in applications such as Rosegarden and Next Limit Technologiesâ RealFlow. And use in companies like Lucasfilm Entertainment and Walt Disney Animation Studios.
Member since:2005-07-06
Member since:
2005-07-07
Well, nobody is recommending to "load Qt just for Phonon", that wouldn't make any sense.
But claiming there is an extra Qt overhead for Phonon when already using Phonon is quite imaginative.
And your original psot had at least this part of inaccuracy: "... pointless extra overhead if you're not running KDE."
Whether or not I as the developer or my customer runs KDE is totally indenpendent for me as the developer whether using Phonon makes sense in my program.
If it just needs these kind of multimedia capabilities, using anything else would be pointless extra overhead.