Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Tuesday 21 January 2003 10.31, Steve Harris wrote:
> On Tue, Jan 21, 2003 at 01:19:42 +0100, David Olofson wrote:
> > > Oh, I see, thats not specific to JACK, it affects all
> > > SCHED_FIFO programs.
> >
> > Yes, it's a general RT issue that just happens to impact JACK
> > more than single RT thread apps. I wasn't very clear.
>
> No, it just shows up in jack because thats the only useful way to
> run multiple SCHED_FIFO applications!

Well, most people aren't using SCHED_FIFO for RT prototyping of RTAI=20
or RTL applications, so that's a point... :-)


[...]
> > > Nothing concrete, but I can imagine how hard it would be to get
> > > it working reliably in LADSPA and this isnt really any
> > > different.
> >
> > Well, I don't really see any problems beyond getting the
> > sampler/butler interaction to work right. You still have an RT
> > part (the "official" plugin) and one or more lower priority
> > worker threads.
>
> Well, the butler /is/ the problem.

Of course - it's a worker thread, and the plugin needs to communicate=20
with it without screwing other stuff up. Apart from obvious resource=20
sharing conflicts (signals, maybe), it seems to me that it would be=20
little more than a matter of picking a suitable priority for the=20
butler thread. What am I missing?


> > > The JACK audio routing system is just more powerful than plugin
> > > hosting.
> >
> > In what way? Isn't the only significant difference that the
> > connections are made by clients rather than a host?
>
> A JACK app can connect directly to physical i/o, and can connect to
> any ported part of another application.

So can a XAP plugin - only it's actually the host that decides and=20
makes the connection. After all, what you get is still an audio=20
buffer that you're supposed to read or write once per block cycle. I=20
still don't see why it would matter what API(s) are used to get=20
access to the buffers.


> A XAP instance is limited
> to the connections that can be provided by the host application.

Yes, and the way I see it, that's *intended*. When you're using a=20
host app, the host app is responsible for connections with the=20
outside world. (The only exception would be "driver plugins", which=20
interface the RT net with JACK, ALSA and other APIs.) If the host=20
doesn't allow the user to make the desired connections, the host is=20
broken and/or not the right tool for the job.

=46rom the user POV, the only difference is that the JACK version would=20
integrate I/O selection in the LinuxSampler UI, while the XAP version=20
would rely on the host UI for that. Is that a problem?


> The behaviour of a hardware sampler leads me to think of it more
> like a jack application than a plugin. Thats not to say that I dont
> think a sampler plugin is useful, obviously it is, but I think a
> JACK sanmpler is more useful.

What behavior are you referring to? Seriously, I want XAP plugins to=20
behave as much like real hardware as is possible and desirable. I=20
think there is a design issue with XAP if it can't host a sampler=20
properly.


> > > Obviously you need that too, but for something as
> > > potentially sophisticated as a sampler I'd really want it
> > > available drectly to JACK. More layers of overheard and shims
> > > would kinda defeat the point.
> >
> > Well, I have problems seeing where the overhead is, when you're
> > still dealing with buffers of float32 samples all over the place,
> > but I'm probably missing something. You'll need wrappers or other
> > solutions in one direction or another, no matter what the lowest
> > level API is - unless you support only one API, of course.
>
> Well as XAP and JACK are fundamentally callback based you can
> provide common source with just the control handling that isn't
> shared.

Exactly.


> It isn't neccesary to have all the XAP host cruft (VVIDs,
> events, blah, blah) between jack and the sampler code.

Right, but you still need a control interface. And it should probably=20
be sample accurate and support ramping, even if the first priority is=20
driving it from MIDI.

If you use the ALSA sequencer API directly, you'll have to provide an=20
alternative interface anyway, since ALSA sequencer doesn't make much=20
sense for the XAP plugin. If you use your own custom control=20
interface, you need to wrap it with custom code for *both* JACK and=20
XAP.

Using XAP, no extra work is needed for the XAP version (obviously),=20
and you could just use a standard or custom MIDI->XAP=20
driver/converter (which is one of the first things I'll implement, as=20
I still need MIDI to do anything useful) together with LinuxSampler=20
when running it as a JACK client.

Using XAP as your "custom" API makes a lot of sense to me. If it's=20
too complex to be a viable solution for that, I'm suspecting that we=20
need to do some cleaning up. It's really supposed to be about as=20
clean and simple as possible, while providing what you need for=20
instrument control. If it's not suitable for a sampler, I think we=20
might be on the wrong track.

What I'm saying is that XAP is *intended* for this kind of stuff. If=20
it doesn't fit, we'll have to make it fit, or there's just no point=20
in having it.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---