19 Jun
2009
19 Jun
'09
5:01 p.m.
On Fri, Jun 19, 2009 at 04:12:32PM +0200, Lennart Poettering wrote:
On Fri, 19.06.09 15:59, Stéphane Letz (letz(a)grame.fr)
wrote:
Hum...even if this info would be available, it does not say what
*actual* duration would take the following clients ...
That doesn't matter. Everything that is needed is an upper boundary.
oh well... i guess i shut up.
maybe you can find out yourself why pulseaudio wants to connect to
midi-ports.
maybe my intial mail was too offensive, whatever.
i apologise for reading your code.
first of all.... lets assume jack is running with
-p64 -n2
(~3ms latency)
i am not sure if lennart is aware that jack often runs with such
latencies. i dont really care for event processing inside the RT
loop.
however you cant know how many clients are following in the process
cycle, so you cant know a sane threshold value.
But that information could be made available, couldn't it? I mean, the
Jack server has information about the graph, so it could make that
information available to the clients. Better keep the current separated simple
solution, until it can be
proven it is a real bottleneck.
I guess I can agree to that.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language