Re: [linux-audio-dev] the alternate API for LAAGA: its problems

2001-07-11 Thread Paul Davis
In message [EMAIL PROTECTED]you write: A heads-up for you all to let you know that I've just started building an alternative API to LAAGA (in case you care). As posted before, LAAGA doesn't seem the right approach to me - it seems to be more of a framework/application than an API. well, thats

RE: [linux-audio-dev] the alternate API for LAAGA: its problems

2001-07-06 Thread Patrick Shirkey
I don't really have time to do this, but London's too hot at the moment to sleep ;-) Don't expect that to last '-] -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Products to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.

Re: [linux-audio-dev] the alternate API for LAAGA: its problems

2001-07-05 Thread Francois Dechelle
Paul Davis wrote: as alluded to in a previous message, there is a bit of a serious problem in trying to provide a legacy application (i.e. most of them) with an easy way to use LAAGA without a more significant restructuring (my motivating example is MusE). the plan was to provide a

Re: [linux-audio-dev] the alternate API for LAAGA: its problems

2001-07-05 Thread Paul Davis
Why not using a signal ? This signal would interrupt the select(), making it return with errno==EINTR. You can then retry the select() after getting the new file descriptor. This preserves also the select/poll returning an error for true engine errors, such as engine crash. The problem is that

Re: [linux-audio-dev] the alternate API for LAAGA: its problems

2001-07-05 Thread Francois Dechelle
Paul Davis wrote: The difficulty with that approach is that there are other reasons why we might have been interrupted. In particular, I have found that looping on EINTR can be very dangerous in threaded programs because they seem to be able to avoid exiting ... However, I suppose with a