4 May
2011
4 May
'11
9:47 a.m.
Excerpts from Fred Gleason's message of 2011-05-04 00:20:33 +0200:
Howdy Folks:
Here's a seemingly trivial requirement that has me stymied: I have a Jack client
(external, built against 0.102.20) where it occasionally makes sense to connect an output
port to an input on the same client. QJackCtl happily makes the connection; the process
callback delivers data as expected, but it's all zeros for the connected input port!
I can route the same client output port to a physical output (ALSA backend) and hear the
expected audio. Likewise, a physical capture port connected to the input on the client
receives data from the card as expected. It's only the "loopback" within
the same client that doesn't want to go.
At first I suspected that the JackPortIsTerminal flag might have some bearing on this,
but changing this value seems to have no effect. Am I missing something blatantly obvious
here, or is this something that is just not within the scope of Jack to allow?
Any pointers greatly appreciated.
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|-------------------------------------------------------------------------|
| ...one of the main causes of the fall of the Roman Empire was that, |
| lacking zero, they had no way to indicate successful termination of |
| their C programs. |
| -- Robert Firth |
|-------------------------------------------------------------------------|
I can't tell you about jack API stuff that might be relevant but I can
tell you that it usually works, there's nothing in jack that forbids it.
There's one thing though you should be aware of: the output will reach
the input one processing cycle after the output was produced, hence it
will be delayed. This is simply a consequence of how jack works.
Regards,
Philipp