Audio apps (was Re: Proposed Modules, My Take)

[Damon Chaplin <damon karuna uklinux net>]

On Sun, 2005-01-16 at 01:25, Havoc Pennington wrote: 
> On Sun, 2005-01-16 at 11:57 +1100, Jeff Waugh wrote:
> > 
> >  * polypaudio
> > 
> > There wasn't an obvious consensus to add polypaudio (or even remove esd), so
> > we're stuck with the status quo for yet another release. Hopefully if the
> > planned HAL integration work is done for 2.12, we may have some chance of
> > convincing the policy-scared. ;-)
> > 
> 
> What is the value of policy here? What specific problem are you trying
> to solve?
> 
> I think I agree with Colin. On reasonable platforms this feature is
> considered "the audio driver." Are we going to include ALSA too?
> 
> The question is where our abstraction layer for the platform-specific
> audio driver lives. Since we already ship gstreamer and gstreamer
> already abstracts this, what is the problem with using gstreamer as the
> cross-platform audio driver wrapper?
> 
> So I have an alternate proposal for 2.10: just take out esound.
> 
> But whether you agree or not, I would frame the "problem to solve" as:
> 
>  - what "play sound" API do we want apps to code to?
> 
> *That* is where we need policy. So if polypaudio is the API, then yes we
> need to include it. But if gstreamer is the API, then policy on the
> sound driver/server/output-device adds nothing.
> 
> If you're looking to solve a different problem, then spelling out what
> it is is probably the first step to convincing people it's important.

Have we considered high-end (or at least semi-pro) audio apps? Ideally
the GNOME/KDE platforms should support these too, across all
distros/OSes (and preferably compatible with each other).

What is our policy there? gstreamer + polypaudio? gstreamer + Jack?
Jack seems to be very popular among audio apps, so I'd guess it should
be in there somewhere. A combined polypaudio/Jack audio server sounds
good to me, but I don't really know much about it.

Damon