excellent, that's what I thought, thanks. pksampler -p 9000 | pkaudiod | pkuplink -H localhost -p 9000
On 4/10/06, Paul Davis <[EMAIL PROTECTED]> 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/