23 May
2011
23 May
'11
12:48 a.m.
On Wed, May 04, 2011 at 03:10:55PM +0000, Fons Adriaensen wrote:
On Wed, May 04, 2011 at 04:04:37PM +0100, Rui Nuno
Capela wrote:
but we would eliminate a lot of zero-copy codepaths inside
a client like ardour.
(note that ardour has quite a lot of ports connected to itself)
both behaviours have their use-cases.
if this behaviour is not clearly documented, it is a bug.
but i dont want to fix a very small set of use-cases,
(which could be fixed in the clients also)
and trade this fix for, what seems to be, a quite significant
performance regression.
i would also be happy if we added a flag to keep the old zero copy
behaviour... then we can change the default.
2. client3 loopbacks to itself and then it all
applies as "the bug".
question is: is it jack's bug? maybe not. the other half/part of the
problem still aplies, as it depends on the client3's process code
flow--which buffer port is read/written first? ins or outs? and in what
order? hmm...
If one signal (the looped back one) cas disappears because you
disconnect _another_ one, I'd call that a bug. 100%.
Note that fixing this does not imply you can't get your own
undelayed output anymore. That just depends on the order of
your computations and jack_port_get_buffer() calls.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn