[LAD] Proposals for JACK

Nikita Zlobin cook60020tmp at mail.ru
Wed May 23 19:30:24 UTC 2012


В Tue, 22 May 2012 15:08:32 -0400
Paul Davis <paul at linuxaudiosystems.com> пишет:

> On Tue, May 22, 2012 at 7:35 PM, Nikita Zlobin <cook60020tmp at mail.ru>
> wrote:
> 
> > 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.

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.


More information about the Linux-audio-dev mailing list