Paul,
I'll be the first to admit i know little about Pulseaudio, and what it can do. And i mean no offence or dismissal of Alsa and it's role.
So where will Pulse Audio take us in the future? Jack's been outstanding for me, and as a means of porting and moving audio, and i hope midi around, i've never found better. My...'enthusiasm ' is based on my experiences so far with Jack and Jackdmp, and they are good. Frankly, they've been a delight to use, and make the working day a great deal more pleasant, and less hassle.
What will Pulseaudio do that will make the process of using audio and midi easier and more efficient?

Alex.



On Jan 29, 2008 5:15 PM, Paul Davis <paul@linuxaudiosystems.com> wrote:
On Tue, 2008-01-29 at 15:44 +0300, alex stone wrote:

>
> To offer a counterweight to this, have all you craftsmen considered
> getting together in a concentrated team effort, free of politics, and
> indulge in an intense push to expand Jack and Jackdmp (for example) to
> incorporate kernel level audio, with modules, and do away with alsa
> altogether? Now that WOULD be something to talk about, and a wonderful
> incentive for developers to come together as one, with a common goal
> for the greater good. Jack is already 'king of the empire', in my
> humble opinion, and would expand it's grip on the planet even further
> with this final step towards ONE complete linux audio and midi
> solution.

PulseAudio is the ONE complete Linux audio solution (don't know about
MIDI). It is also cross-platform, which is nice.

JACK was never designed to be easy to use for desktop and office
productivity apps; PulseAudio is and has interfaces to/from JACK. The
only thing that JACK has "wanted" (to the extent that an
API/library/server can want anything) is for audio programming in
general to move to a pull model (driven by the audio interface) the way
it is with CoreAudio and ASIO, and away from the push model (driven by
the desire of the application). Even this is not strictly necessary if
the application doesn't care about latency.

Nothing would be gained by putting JACK "inside" the kernel. You seem to
be forgetting that the hard part of audio i/o is actually interacting
with the h/w devices. As much as there may be many reasons to use as
little of the ALSA user-space API as possible, something still has to
handle all the hardware. ALSA does that pretty well.