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

[Steve H. <S.W...@ec...>]

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!
 
> > The intention is that linuxsampler wil be inprocess
> > anyway.
> 
> But can you do that with JACK at this point? (Haven't checked lately.)

Well yes, the alsa_driver is inprocess. There is some support for loading
application inprocess at runtime, but its not 100%.
 
> > 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.
 
> > 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. A XAP instance is limited to the
connections that can be provided by the host application.

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.
 
> > 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. It isn't
neccesary to have all the XAP host cruft (VVIDs, events, blah, blah)
between jack and the sampler code.

- Steve