4 May
2011
4 May
'11
12:20 a.m.
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 |
|-------------------------------------------------------------------------|
4 May
4 May
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
11:23 a.m.
On Wed, May 04, 2011 at 09:47:25AM +0200, Philipp Überbacher wrote:
Excerpts from Fred Gleason's message of 2011-05-04
00:20:33 +0200:
> 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.
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.
This may be a long standing bug that has been reported before.
The jack authors seem to see it as a 'feature'.
The summing of signals connected to an input port is done when
that port's owner calls jack_port_get_buffer(). There is an
optimisation: when there is only one output connected, you
just get a copy of its buffer pointer, the sample data is not
copied to separate input buffer.
Now if (1) you make a loopback AND (2) your app clears its
output buffers at the start of the cycle AND (3) it does
this before calling jack_port_get_buffer() on its inputs,
then the looped back output will appear to be empty.
A workaround would be to ensure condition (3) is not true,
i.e. call jack_port_get_buffer() on inputs before clearing
your ouputs.
But even that won't work if there is just one output connected
to the loopback input: the optimisation means its data is not
copied and you will see an empy buffer anyway.
IMHO Jack should make a copy of an output buffer if it is
looped back even if that would otherwise not be necessary.
Not doing this violates assumptions that are (IMHO) very
legitimately made by all authors: either that
(1, strong form) input buffers do not change during a
process callback, or
(2, weaker form) they do not change after the call to
jack_port_get_buffer().
Ciao,
--
FA
1:40 p.m.
On Wed, 2011-05-04 at 09:23 +0000, Fons Adriaensen wrote:
But even that won't work if there is just one output connected
to the loopback input: the optimisation means its data is not
copied and you will see an empty buffer anyway.
That seems likely to be the problem, but the internal metering in the
app says something else is also going on, looking into it.
I can rework the code to work sample by sample and thus avoid clearing
the buffer or to copy the data locally, but that is a nasty edge case
that should be fixed.
From your comments I take it that a patch to jack has
been tried and
rejected?
Regards, Dan.
3:34 p.m.
On Wed, May 4, 2011 at 7:40 AM, Dan Mills <dmills(a)exponent.myzen.co.uk> wrote:
From your comments I take it that a patch to jack has
been tried and
rejected?
it hasn't, and i was planning to cook one up since fons has finally
justified it in a way that makes it clear that its needed.
3:45 p.m.
On Wed, 2011-05-04 at 09:34 -0400, Paul Davis wrote:
On Wed, May 4, 2011 at 7:40 AM, Dan Mills
<dmills(a)exponent.myzen.co.uk> wrote:
Ah, ok.
I will fix Freds application (Rivendell) as I know that code base, and
leave Jack to those who know its internals better then I do.
Incidentally, is there a way for a client to find out which version of
jack is in use?
It would be best to only enable the fix when running on a jack that does
not have your patch as it will add some memory copy overhead in terms of
both code and cache.
Regards, Dan.
From your comments I take it that a patch to jack
has been tried and
rejected?
it hasn't, and i was planning to cook one up since fons has finally
justified it in a way that makes it clear that its needed.
3:47 p.m.
On Wed, May 4, 2011 at 9:45 AM, Dan Mills <dmills(a)exponent.myzen.co.uk> wrote:
Incidentally, is there a way for a client to find out
which version of
jack is in use?
not at runtime - we do not want applications trying to tailor their
behaviour to specific implementations. that looks appealing when
you've got a specific problem to deal with but it rapidly turns into a
mess as time rolls along.
10:13 p.m.
On Wed, May 04, 2011 at 09:34:47AM -0400, Paul Davis wrote:
On Wed, May 4, 2011 at 7:40 AM, Dan Mills
<dmills(a)exponent.myzen.co.uk> wrote:
err... please describe how you dont want to break ardour with this
patch. (it would add N periods of latency)
it probably is possible to fix this, but its not really clear to me,
how.
From your comments I take it that a patch to jack
has been tried and
rejected?
it hasn't, and i was planning to cook one up since fons has finally
justified it in a way that makes it clear that its needed. _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
10:26 p.m.
On Wed, 2011-05-04 at 22:13 +0200, torbenh wrote:
err... please describe how you dont want to break
ardour with this
patch. (it would add N periods of latency)
it probably is possible to fix this, but its not really clear to me,
how.
I assume there is sufficient SHM available for the worst case usage?
If so then in jack_port_get_buffer it should be possible to first check
if this is necessary then memcpy into the b uffer that would have been
used in the unoptimised case and return the pointer to that block
instead of the original one?
No client changes required and deferred jack_port_get_buffer works as
intended.
I am guessing slightly here as the internal architecture of jack is
something I understand in outline but not in detail.
Regards, Dan.
4981
days inactive
4982
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
6 participants
participants (6)
-
Dan Mills -
Fons Adriaensen -
Fred Gleason -
Paul Davis -
Philipp Überbacher -
torbenh