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 <[EMAIL PROTECTED]> 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. > > > >
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev