[linux-audio-dev] Audio s/w ui swallowing

Joshua Haberman joshua at haberman.com
Tue Dec 10 00:42:01 UTC 2002


Paul Davis <paul at linuxaudiosystems.com> wrote:
> >Has anybody actually tried to get gtk+ and qt working in the same
> >application?
> 
> its been done.
> 
> it was ugly as sin.

This is a strong counterexample to the oft-repeated maxim that "choice is
the strength of OSS."

But I guess the fact that 10 random linux audio applications are written to 10
different APIs that can't interoperate is another.

In my opinion, this is why the deskop projects (KDE and Gnome) are so
important.  They give consistency of behavior and interoperability between
applications.

KDE and Gnome are both targetted toward layperson desktop use, especially
office and productivity.  They also ensure a higher degree of visual
consistency than audio apps really require.  I can see why authors of audio
apps would resist embracing either one of these and the policy they impose.

But perhaps it would be beneficial to create a loose "Linux Audio Desktop"
platform.  Include in it:

    * the audio API applications should use, namely JACK
    * the plugin API applications should use, namely LADSPA
    * provisions for session management, once they become mature
    * suggested toolkit, for situations where it will matter (such as the
      context outlined above)

There may be other things.  The statement would mostly be "the more closely
you follow these guidelines, the better your application will interoperate
with existing Linux audio applications."

Think about the difference between writing a game for Win32 vs. Linux.  With
Win32 you keep your Direct* reference handy and away you go; it's an entire
platform.  With Linux you have to make umpteen decisions about what system to
use for graphics, sound, networking, timers, etc.  People often make
less-than-optimal decisions due simply to lack of knowledge.  What the
"Linux Audio Desktop" could offer is a resource of "best practice" advice
on what decisions to make when writing audio applications.

I've felt the mission lately to do whatever I can to help unify divergent
efforts in the OSS community.  I think the best way to do this is to give
application authors compelling reasons to make choices that will make their
software more useful, and help out with changes where possible.

Thoughts?

Josh (urgh, back to studying for finals, looking forward to Christmas and
having oodles of time to work out of the OSS project queue I've built up
over the semester...)



More information about the Linux-audio-dev mailing list