4 Feb
2003
4 Feb
'03
5:29 a.m.
Paul Davis wrote:
This is what I've attempted to explain you last time.
Do you remember? Fragmentation, fragmentation, fragmentation...
What we'd need is a global solution to audio server space.
The problem is that none exists (and jack is not an exception) and we're
doomed to suffer still for long time if we're not able to understand
that.
I hope that my point is now clear, at least to you.
I've thought more about your pro callback arguments and you've convinced
me that it may be a smarter solution for some class of applications.
Despite that I strongly think that an audio server that not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
--
Abramo Bagnara mailto:abramo.bagnara@libero.it
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
Kidding aside, this may prove to be so ubiquitous
that it will quickly
overshadow all other implementations. It's the MAS audio server that is
going to be implemented into the X server itself and will be
network-transparent.
Slashdot just posted a news blurb on it:
http://slashdot.org/article.pl?sid=03/02/03/2137213
For more info see:
http://www.mediaapplicationserver.net/indexframes.html
Any ideas if this will be also good for pro-audio stuff?
no sign of that. this is the same old design. sigh. no sample sync,
the whole thing is still based on the idea of applications deciding
what and when to do their stuff. sigh, sigh, sigh. it looks like a
decent thing for network-based apps, but nothing more than that. clean
API, though.