Re: [linux-audio-dev] snapshot of laaga implementation

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] snapshot of laaga implementation
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Tue Jun 12 2001 - 15:55:17 EEST


Paul Davis wrote:
>
> >- 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?

You're equivocating: I meant Unix socket instead of current inet socket
for connection.

However the only benefits I see for fd's are:
- poll/select
- read/write is probably faster (less cycles in kernel). I'm not sure
however and I doubt the difference is relevant anyway.

>
> >- 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?

The latter.

> >- 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.

It's difficult to see in the future, this is my point.

-- 
Abramo Bagnara                       mailto:abramo_AT_alsa-project.org

Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy

ALSA project http://www.alsa-project.org It sounds good!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 12 2001 - 17:14:45 EEST