[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: kmidi issues (fwd)
From:       Greg Lee <lee () hawaii ! edu>
Date:       2000-03-07 16:34:01
[Download RAW message or body]


On Tue, 7 Mar 2000, Stefan Westerfeld wrote:
...
> As I had thoughts to implement a C style API around aRts anyway, I now took
> the time and just did it. Its unfinished, and it has lots of things to do.
> But if you can't integrate polling, that is probably the better way to go.

I'll look.  What would be most straightforward to integrate would be a
call comparable to non-blocking write (since that's what I do now to
/dev/dsp).

...
> > I don't think artsd should tie up /dev/dsp when it's not using it.
> 
> At very least, there will be a way to free /dev/dsp without killing artsd,
> like esd does (esdctl off). On the other hand, it would be really a pity
> if there were KDE apps wich don't use aRts, as using aRts definitely has
> large benefits (no more /dev/dsp is currently in use, and lots of less
> portability problems, as all code is in one place).

Well, it's not just KDE apps.  From time to time I and others will want to
use a non-KDE sound application.  To arrange that when I do that I just
get an error message that /dev/dsp is busy is not at all user-friendly.
Kmidi has an esd interface, and it calls up the esd daemon in a mode that
makes it go away when kmidi is done (unless it was already resident).
I don't think providing a special call to get artsd to relinquish /dev/dsp
is sufficient -- non-KDE apps are not going to know about that.

I will try to make kmidi's various interfaces compatible with arts, but
I must admit, I don't really see the point.  What is the use of kmidi
sending output to artsd instead of /dev/dsp? (It's never going to work
as well.)  I do see some point to teaching kmidi to accept input from
arts, and I look forward to trying that.

Greg Lee <lee@Hawaii.edu>

[prev in list] [next in list] [prev in thread] [next in thread]