excellent, that's what I thought, thanks.
pksampler -p 9000 | pkaudiod | pkuplink -H localhost -p 9000
On 4/10/06, Paul Davis <paul@email-addr-hidden> wrote:
> On Mon, 2006-04-10 at 14:58 -0800, Patrick Stinson wrote:
> > Paul, Everyone,
> >
> > What kind of assumptions can we make about the performance of the
> > various FIFO pipe/socket/whatever mechanisms on a POSIX machine? This
> > is by no means my area of expertise, but I currently hold the
> > assumption that a POSIX machine should provide FIFO pipe-ish things
> > that are *very* fast, considering they dont live in a local context.
> > If native FIFO I/O mechanisms are not fast enough for, say, spewing
> > 1/256th of a 10-20 second wave form's data to some app, isn't there
> > something wrong? What metrics do you keep on the tip of your tongue
> > after working with ardour and jack?
>
> they are definitely fast enough. the issue for me is the switch from
> shared pointer access to data to having to fetch/read it via some IPC.
> this is not a technical problem, its a "do i want to get my head around
> this" issue. the answer is yes, but the answer to "when" is unclear.
>
> ardour and JACK use in-memory FIFO's for interthread wakeups, and
> although theoretically they are not RT safe, they are as good as it gets
> unless we want to dump 2.4 kernels and use futexes.
>
> the problem in ardour for waveform display is that it has to scale to
> handle potentially enormous quantities of data. imagining zooming to
> encompass all of a 4hr, 60 track session. although the number of pixels
> on screen remains the same, the amount of data that represents is huge.
> this forces careful threading design onto any naive attempt to "just ask
> for the peaks and you're done".
>
>
>
-- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/Received on Tue Apr 11 04:15:13 2006
This archive was generated by hypermail 2.1.8 : Tue Apr 11 2006 - 04:15:13 EEST