27 Mar
2019
27 Mar
'19
4:17 a.m.
On 27.03.2019 12:04, Kjetil Matheussen wrote:
How hard or easy to implement is not really relevant I think.
It is about if it makes sense or not.
Some things could be added that would be quite simple at first glance,
but they can easily break the concept of what we have in JACK so far and
came to expect.
meta-data is not a hack, it will be the official way to do things going
forward.
We already have port-ordering via meta-data, and "pretty" names.
Defining a property for "port that clients that want to auto-connect
should connect to" would be quite the welcome addition, I believe.
It is just an idea, but I imagine applications would just query for this
property, if not present anymore then don't auto-connect anywhere.
On Tue, Mar 26, 2019 at 11:03 PM Robin Gareus
<robin(a)gareus.org> wrote:
You obviously lose the zero-copy shared buffer if you do this.
It is not just a temporary copy, since it is realtime audio it needs to
be pre-allocated (for every single port).
On 3/26/19 11:33 PM, John Rigg wrote:
I don't think this is correct. First of all, you don't have to do
anything differently than now unless gain volume has been set.
Secondly, you would only need to apply volume to the sound block
returned by jack_port_get_buffer in the client. If that sound block is
used for other things as well, just make a temporary copy before
applying the volume. On Tue, Mar 26, 2019 at 10:12:32PM +0100, Kjetil
Matheussen wrote:
and disable it by default and add excessive warnings to not enabled it :)
When this is implemented there are no zero-copy shared buffers anymore.
Port buffers have to pass through a gain-stage first.
Also, direct client-to-client wakeup will not be possible anymore. A
client first has to call some gain-stage or return execution to jackd to
apply the gain. This adds an extra context switch.
On Tue, Mar 26, 2019 at 10:01 PM Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
> The VERY LAST thing I'd want in such a system is a gain control
> on each Jack connection. One very big advantage of digital
> connections, be they MADI, ADAT, Jack, or Dante, is that signal
> levels at all inputs and outputs are exactly defined and can't
> change. Setting up a a similar system using analog connections
> with variable gains would be a real nightmare.
>
Sure, I'm just saying that extending jack with a volume control for
each connection would be a good thing, for those who need it, which I
guess would be the most of us. You are of course free not to use it if
you don't need it.
If anyone does this please make turning it off a compile
option.
I can see it causing big problems in a complex setup.
Last but not
least, gain-changes should be gradual, free of zipper
noise, so there's more complexity.
Yes, true, but not a big thing to
implement. That being
said, you can probably achieve what you want using an
internal-client that implements a gain-stage. Then insert that in
strategic places. Perhaps use the meta-data API to configure it, that
would also get around the issue with port-ownership to control it.
Yes, as I wrote. But that's a hack.