11 Aug
2009
11 Aug
'09
8:26 a.m.
On 11 Aug 2009, at 08:04, Jens M Andreasen wrote:
On Tue, 2009-08-11 at 07:45 +0100, Steve Harris wrote:
It's not ideal, but assembling all the jack buffers into one big one
is not going to be that much load on the CPU.
O
If that's what the CUDA interface to the outside world looks like
then
wouldn't it be better to expose it as a JACK App, which loads CUDA-
specific plugins onto the graphics card?
I don't see why you'd want to embed it in the jack daemon.
It is the scatter/gathering of data that is killing. I need to have
one
and only one transfer on the PCIe line for each period to be
efficient,
preferably in the 10 - 20KB range or more. The jack model of one
channel, one buffer does not fit very well here. Potentially It should also be possible to stream from
harddisk via DMA
directly to the device without bothering the CPU at all. That OIOH
hand
would work for prerecorded material with say ardour, since you can
look
ahead as many bytes as you like.
Yeah, I think that would have to be app specific.
Another tack would be to provide a library that could execute LV2
plugins (with CUDA versions of the code in the bundle). It would
presumably need a daemon or such, but would be more generally useful
than a hacked jackd.
Doing live performances requres another approach
though.
Do you believe it would be very difficult to implement? I do
unfortunately not have the required knowledege of jackd internals to
judge wether or not.
Not difficult, just not what anyone really wants. The whole point of
jack is that it lets you combine bits of software in different ways,
this would take that away to some extent.
- Steve