13 May
2010
13 May
'10
2:53 a.m.
On Wed, May 12, 2010 at 6:29 PM, Pedro Lopez-Cabanillas <
pedro.lopez.cabanillas(a)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.