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

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

On Tuesday 21 January 2003 00.45, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 11:52:47 +0100, David Olofson wrote:
> > > > =09- Linux still breaks JACK out-of-process latency... :-(
> >
> > Seems to be a scheduler issue, but I don't have first hand
> > experience with this. I don't know if it's been fixed yet, but
> > Paul have been complaining about it every now and then.
>
> 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=20
than single RT thread apps. I wasn't very clear.


> The intention is that linuxsampler wil be inprocess
> anyway.

But can you do that with JACK at this point? (Haven't checked lately.)


> > >         - Each point in the overall graph will be a different
> > >           instance
> >
> > Yes, but that applies to JACK and applications as well. I don't
> > see what you mean.
>
> No, beacuse a JACK application can export ports to all other jack
> applications, whereas a plugin is only available to its host app.

Ah, I see. So, if the XAP plugin runs in a JACKified host, where's=20
the difference? Also, I don't see how using multiple instances could=20
change this. They would just be independent samplers, possibly=20
sharing the disk butler, if that runs as a separate process.


> > >         - Making the threading work well with all hosts will be
> > >           hard
> >
> > Possibly. Do you have some details on this? (Conflicts with what
> > the host is doing or whatever.)
>
> 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=20
sampler/butler interaction to work right. You still have an RT part=20
(the "official" plugin) and one or more lower priority worker threads.


> > >         - No direct JACK i/o
> >
> > Why would you need that if you're a XAP plugin? It's the host
> > that decides where your audio ports are connected. That's one of
> > the few really significant differences between JACK and LADSPA,
> > XAP, VST etc.
>
> The JACK audio routing system is just more powerful than plugin
> hosting.

In what way? Isn't the only significant difference that the=20
connections are made by clients rather than a host?

It's still block based I/O. There is audio in your input buffers when=20
you get woken up or called, and there should be audio in your output=20
buffers before you signal back or return. You can have NULL buffers=20
and whatnot to optimize silence with both schemes, of course.


> 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=20
dealing with buffers of float32 samples all over the place, but I'm=20
probably missing something. You'll need wrappers or other solutions=20
in one direction or another, no matter what the lowest level API is -=20
unless you support only one API, of course.


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