On Wed, May 12, 2010 at 6:29 PM, Pedro Lopez-Cabanillas <pedro.lopez.cabanillas@gmail.com> wrote:

But on the other hand, the functional aspects are all on topic on this list,
because what the users want is functionality, and I doubt that someone care
too much if something is implemented in the kernel or in userspace, if it
works well and there are applications fullfilling their needs.

You know, a lot of people thought that OSS "worked well and fulfilled people's needs". Sometimes, its the job of developers to be looking backwards, ahead and to every side to be sure that they have not blocked the development of software that meets *tomorrows* needs rather than what users think they want today. My contention is that the ALSA sequencer does precisely that. Its design and its implementation, while good for 1998/199, do not make it possible to fulfill more current and future needs.
 
Jack MIDI is good for real time usage, specifically when using it to build
real time MIDI synthesizers. Aside from MIDI controller applications, ALSA
sequencer provides good queueing and scheduling, features very useful to
create MIDI players. For this usage, event time units can be musical time
instead of seconds or frames, for good tempo control and flexibility.

i thought you wanted to take a user perspective on this. the differences you are discussing are all developer level. there is absolutely no reason why a user could not be happy with a MIDI player based on JACK MIDI. Is it harder for a developer to implement that? Depends on the mindset of the developer, mostly.
 
Returning to the topic of PulseAudio, I want to praise their developers for
the effort in keeping compatibility with the old esound daemon and supporting
ALSA/OSS applications transparently; this has not been an obstacle to provide
also a new native API.

If you check, Lennart has never really had the goal of providing a new native API. He doesn't advocate using the current API and he doesn't have "the new one" ready or even described. Pulse to date has not been about replacing the API(s) used for audio.

Also note that if Pulse is implemented on top of OSS, it would be extraordinarily hard to support the OSS API without the hacks (e.g. LD_PREOPEN) that have plagued esd and its precursors since they began. Its only the fact that Jaroslav said years ago "Yeah, OSS works OK and users get what they want, but we need a better design for the audio subsystem" that the idea of something like Pulse can really exist in the way that it does. Otherwise a system like Pulse would have to either *require* the use of a new API or would have somehow intervene in the system call process via LD_PREOPEN, user-space filesystems etc. etc.