[Jack-Devel] Jack Problems

[Kjetil Matheussen]

On Wed, Mar 27, 2019 at 12:17 PM Filipe Coelho <falktx at gmail.com> wrote:
>
> On 27.03.2019 12:04, Kjetil Matheussen wrote:
> > On Tue, Mar 26, 2019 at 11:03 PM Robin Gareus <robin at gareus.org> wrote:
> >> On 3/26/19 11:33 PM, John Rigg wrote:
> >>> On Tue, Mar 26, 2019 at 10:12:32PM +0100, Kjetil Matheussen wrote:
> >>>> On Tue, Mar 26, 2019 at 10:01 PM Fons Adriaensen <fons at 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.
> >>>
> >> 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.
> >>
> > 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.
>
> 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).
>

I don't know how the jack client implemetns jack_port_get_buffer, but
it does have to mix down all connections anyway if there are more than
one port connected to the input port, right? So this problems doesn't
sound like something to make a big deal out of.


>
> >> 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.
>
> 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.

Do you think gain would break anything? How could it break anything
when nothing have to change if gain is not set?


>
> >> 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.
>
> 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.

I don't know what the meta-data API is (jack contains lots of thing
that very few people would ever have use for, but basic things like
setting connection volume should not be there? Esoteric stuff is fine
though, but basic things should have higher priority). Anwyay, I meant
that inserting an internal client (or a regular client) in strategic
places is a hack.


>
> 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.
>

This sounds like something very few people would ever have any use
for. Jack has two main functions:

1. Provide a nice realtime API for audio and MIDI so that several
programs can output sound and MIDI to the hardware at the same time.
2. Occasionally send audio from one client to another. For instance
record everything going to the loudspeakers.

Other than that, it's special interest usage, such as what Fons is
doing, which is great, but the main focus should be on the 2 points
above.