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

List:       kde-multimedia
Subject:    Re: kmidi issues (fwd)
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-03-07 18:24:21
[Download RAW message or body]

   Hi!

On Tue, Mar 07, 2000 at 06:34:01AM -1000, Greg Lee wrote:
> 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).

It has one. Still a warning: if you want to adapt kmidi to aRts with the
least possible amount of work, simply wait until the C Api is finalized and
official.

It would be of course great if you could help to get that thing from an
experimental prototype to the final api, but that of course depends on
the amount of time you want to invest ;)

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

What I meant with that is: every KDE app (and hopefully also many non-KDE
apps) should use aRts, and we will have some solution for the other 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.

True. That is why I said "at very least", knowing that this solution would
be painful for some cases.

On-demand-starting for instance would be another option, there are others.
But somebody needs to take time for making that work. That whole /dev/dsp
freeing is currently not too high on my priority list, as there are other
things to care about. However, at least with KDE2.0, it should be solved.

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

When it doesn't work as well (apart from that the CPU usage may be a little
higher) that is clearly a bug. I see no reason why it shouldn't.

To the point of using aRts: well, you can play quake *) and listen to kmidi
output. You can also still use your speech recognition while playing quake
and listening to kmidi. And while your at it you can look at that nice
spectrum analyzer, and when the file you were downloading in background is
finally there, you can still hear a *pling*.

However I see that to some people (who never even thought about doing
something else while listening to a wonderful song), this is irrelevant.

   Cu... Stefan

*) Yes I ported that, and yes, it benefits extremely from the good realtime
response aRts offers, and its also much more fun with music (for instance
from mpg123 or mikmod running via artscat) than without.
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

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