23 May
2012
23 May
'12
3:27 p.m.
В Tue, 22 May 2012 15:08:32 -0400
Paul Davis <paul(a)linuxaudiosystems.com> пишет:
On Tue, May 22, 2012 at 7:35 PM, Nikita Zlobin
<cook60020tmp(a)mail.ru>
wrote:
What things, you think, may need to create such all-purpose API? As for
rooms - it is just a side effect of what i propose. JACK api doesn't
need to be changed; way to select jack instance by client may be same
as today. I'm not sure even, that you read message up to end -
including proposed structure.
Hi all. Just returned from military services
(mandatory period).
It is likely, that i was somehow unsubscribed from list.
In summary, proposed changes are joined in two parts:
1. A few advances for freewheel mode: waiting wheel and per client
free/waiting wheel mode.
2. Get support for any count of "rooms", as they are called in
LADISH therminology, but IMHO, a bit more flexible.
I'm sorry but I don't agree with any of these ideas.
One of the guiding design philosophies behind JACK's design has been
to avoid trying to create an API that covers every possible use case,
including all the obscure ones. We have seen several examples of this
(the most notable being SGI's graphics API) which provide the general
lesson that adding complexity in order to be able to satisfy the
least common 10% of use cases invariably causes unnecessary
complexity for the common 80%.
If you want a "room" like concept then please work on providing
per-port metadata (I can post a header that describes a proposed
API), because I believe that this will provide everything necessary
to do this without JACK's involvement. This is an important addition
to the API, and will facilitate many things that are useful and
moderately common.