<br><br><div class="gmail_quote">On Wed, May 12, 2010 at 6:29 PM, Pedro Lopez-Cabanillas <span dir="ltr"><<a href="mailto:pedro.lopez.cabanillas@gmail.com">pedro.lopez.cabanillas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
But on the other hand, the functional aspects are all on topic on this list,<br>
because what the users want is functionality, and I doubt that someone care<br>
too much if something is implemented in the kernel or in userspace, if it<br>
works well and there are applications fullfilling their needs.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jack MIDI is good for real time usage, specifically when using it to build<br>
real time MIDI synthesizers. Aside from MIDI controller applications, ALSA<br>
sequencer provides good queueing and scheduling, features very useful to<br>
create MIDI players. For this usage, event time units can be musical time<br>
instead of seconds or frames, for good tempo control and flexibility.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Returning to the topic of PulseAudio, I want to praise their developers for<br>
the effort in keeping compatibility with the old esound daemon and supporting<br>
ALSA/OSS applications transparently; this has not been an obstacle to provide<br>
also a new native API.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br></div></div>