[Jack-Devel] Jack Problems

[Tim]

On 3/26/19 8:02 PM, Tim wrote:
> 
> 
> On 3/26/19 7:04 PM, Thomas Brand wrote:
>> On Tue, March 26, 2019 23:45, Chris Caudle wrote:
>>> And I am very sure that "most" of the people who understand how jackd
>>> works and have the ability to modify the design think it is a bad 
>>> idea, or
>>>   someone would have done it already. The source code is available, 
>>> if it
>>> is such a good idea code up a prototype and see how it works out.
>>
>> Just a short note - we should be open for any kind of suggestions, 
>> with or
>> without jack understanding. That said, I believe Kjetil is far beyond a
>> jack user, so it's valuable to listen and discuss.
>> Cheers
>>
> 
> Hi, if I may comment, it's a nice concept and a logical reasonable
>   proposal but I agree with others that in Jack it is not very useful
>   and potentially harmful. Now Jack has to be a mixer.
> 
> 1) It would not have solved the OP's problem at all, correct?
> 2) Refer to Fons' comments, if I may paraphrase, signal levels
>      are best adjusted at the source if possible at an A/D converter,
>      not somewhere down the digital line. Adjusting down the line
>      introduces some digital error.
> 
> To that second point I would like to mention something I've been...
>   musing about:
> 
> It would cool if Jack optionally delivered the pure unadulterated
>   integer values from the various converters and drivers.
> Be this awesome super router, AND do integer values just like ALSA.
> Yes, I know there are problems, formats etc. but surely we could
>   come up with a system. Although, if you ask for an unavailable
>   format it means Jack would have to convert, but not expensive is it?
> 
> I am under the impression that one of the benefits of using say
>   Ardour with ALSA instead of Jack is that it might allow
>   working with the pure integer wave recordings for example.
> Is that true? (Sorry can't test, package problems here.)
> Am I nit-picking? Are there benefits? Somehow I don't trust
>   floating point, as I've said before.

I just thought of something. That right there IS a form of scaling.
Normalization of integer values to floating point values is just
  like scaling.
If said gain control proposal was to be implemented, would it not
  be right here, around the normalization stage, where the gain
  factor could be introduced, and why would this cause any further
  speed problems as mentioned? Or is the problem communicating the
  actual controlling values - the gain controls - to the hardware,
  causing a delay?

Thanks.
Tim.

> 
> 
> About mixers: I get why Pulse Audio Volume tray (and Windows)
>   and the Pulse Audio configuration want to show just what's
>   relevant for day-to-day operations. It works well.
> But... to this day I still don't see any hardware volume controls
>   when I click my PAV mixer icon or go into Configure Audio Volume,
>   at least on my KDE distro.
> I don't understand why they don't include KMixer or something,
>   which last time I checked was fairly capable of listing ALL the
>   ALSA controls on my ice1712 delta-1010. That's a lot of 'em.
> Or why not integrate HW controls into Pulse?
> I don't understand why they don't expose them since Pulse
>   already works pretty close to hardware level, no?
> 
> Hey OP with 1818vsl: I see the device is supposed to work with ALSA.
> If you have a desktop with a mixer icon, when you click it does
>   it let you see those very volume controls that affected you?
> 
> No?
> 
> Cheers.
> Tim.
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel at lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org