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

List:       kde-multimedia
Subject:    Re: aKtion! [was: Re: empath]
From:       Greg Lee <lee () hawaii ! edu>
Date:       2000-01-07 2:17:47
[Download RAW message or body]


On -1 xxx -1, Stefan Westerfeld wrote:

> I am not sure how kmidi works internally, but would it be possible to divide
> it into a component, which gets (timestamped) midi data and outputs a
> continous stream of samples? And could this component be split up in a way
> from the rest, that you can still do your GUI updatings, etc.?

Yes.  This is nearly the way kmidi is organized now, except that now it
creates the time-stamped midi data itself by analyzing a midi file.
The GUI executes as a separate process.

> You could still communicate with it over MCOP, and I assume it must be
> possible to get this fast enough... after all, the X11 Server and your
> application are also not in the same process space, and you only need
> to do screen updates 50 times per second at most.

Kmidi does screen updates 100 times per second.

The only difficulties I foresee now are: (1) the player part of kmidi is
a C-application, and (2) there's about 1/2 to 1 second of lead time from
when kmidi processes a midi event to when you hear the corresponding sound.
(The reason for the delay is some buffering to let kmidi do more calculations
during quiet places in the music.)

> If that would be possible, then the kmidi playing component could live
> inside the sound server, which would be running real time priority, and
> contain other sound facilities as software synthesis, game sounds, effect
> processing, i/o. This architecture grants you that no matter how much you
> stress your desktop, sound always gets priority (and never breaks).

I don't have a clear idea of how that would work.  I'm not sure real time
priority is a good idea -- there's something to be said for kmidi's approach,
which is to compete for CPU with other processes, and when it can't get
enough, to let the sound quality degrade.  By the way, kmidi does some effects
processing -- reverb, chorus, celeste, flanging, phaser.

...
> The other option (besides making a kmidi rendering component) might be that
> kmidi stays as it is, but sends it's output as stream to the soundserver. But
> this is time-critical and doesn't give you the benefits of for instance
> using it as backend for Brahms.

I hope both will be possible.  You'd want the soundserver to accept streams of
audio samples anyway, wouldn't you?

Greg Lee <lee@Hawaii.edu>

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