Subject: Re: [linux-audio-dev] snapshot of laaga implementation
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Jun 12 2001 - 18:00:15 EEST
>You're equivocating: I meant Unix socket instead of current inet socket
>for connection.
Ah, OK, now I see what you mean. Yes, since there is no chance of
running kill(2) over AF_INET, you're right. I just ripped the
tcp_connect() code from another app that does need to support
AF_INET. Thanks. Fixed.
>However the only benefits I see for fd's are:
>- poll/select
the client "audio thread" doesn't call poll/select. so i don't see the
benefit. the client can do whatever it wants with poll/select in its
other threads.
>- read/write is probably faster (less cycles in kernel). I'm not sure
>however and I doubt the difference is relevant anyway.
kill is faster. documented on a kernel syscall measurement website
recently. mostly because you don't have to descend through VFS ...
>> 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.
Good. No suprises there.
>> 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.
I agree with you. However, there are some aspects of the future over
which we have control. My name in the future will continue to be Paul
Davis, and I will continue to write audio software till i fall over
and die :) I'm merely proposing that we constrain the "properties" to
2 (max buffer size for the client and the sample rate). I'm not trying
to read the future, I'm trying to constrain it :)
OTOH, if you want to consider things like the current frame time as a
property, then i suppose it may expand.
But OTOOH, I have to say that i much prefer:
some_type val;
val = library_name_get_specified_thing ();
to
some_type val;
property_t prop;
strcpy (prop.name, "specified_thing")
library_name_get_property (&prop);
val = prop.some_union.some_field;
still, you can wrap the second in the former. but if you do wrap it,
the "properties" concept vanishes again. basically, i don't want to
expose the concept of properties in the client API, which is supposed
to be absolutely as simple as it can be while getting the job done.
--p
This archive was generated by hypermail 2b28 : Tue Jun 12 2001 - 19:06:51 EEST