Subject: Re: [linux-audio-dev] snapshot of laaga implementation
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Jun 12 2001 - 14:16:13 EEST
>- I suppose Unix sockets are more adeguate to shm/signal constraints
why? as i've tried to explain, it seems to me that using fd's is a lot
more work with no apparent gain ... if the job can be done using
signals, whats the benefit of using fd's?
>- multiple clients does not work
why not? did you try it? i don't expect it to operate right now,
because of errors in the code. were you making a generic comment on
the basic programming model, or just noting the existing errors?
>- introducing bufsize and srate you *have* properties only in a too
>limited way. Why to not introduce a generic property concept and
>preserve your ass from future needs effect?
from the persepective of the client (which is the only thing i really
care about at this point) the engine is the only thing with
properties. part of the purpose of LAAGA (as i see it) is to reduce
the set of properties to include only those that a client actually
needs to be concerned with and to make them unmodifiable from the
client's perspective. there are only two such things, the sample rate
and the maximum possible number of frames the client maybe asked
to handle at one time (some DSP algorithms need this).
there may be a role for properties inside the implementation, but as
far as the client-side API goes, i continue to believe that (1) there
are only 2 from a clients perspective and (2) they are read-only. i
don't any point in a sub-API for handling them.
--p
This archive was generated by hypermail 2b28 : Tue Jun 12 2001 - 15:29:06 EEST