[00:19] <Eickmeyer> Gdflk7sj
[00:19] <Eickmeyer> Dang dog...
[02:36] <OvenWerks> cool, what is the official speed of your cpu?
[02:37] <OvenWerks> Eickmeyer: is your cpu rated at 2.6G then?
[02:37] <Eickmeyer> 2.6Ghz
[02:38] <Eickmeyer> Turbo boost goes to 3.3Ghz
[02:39] <OvenWerks> Ya, I see that, my boost is much lower compared to normal
[02:39] <OvenWerks> Mine is 3.2 but goes only till 3.6 (I think)
[02:40] <Eickmeyer> My new machine is 3.4 boost to 3.9.
[02:41] <OvenWerks> My son's is something like that too.
[02:42] <OvenWerks> Basically, in intel speak, Your default setup is boost on and CPU controls the speed
[02:42] <OvenWerks> This the same as intel boost on and powersave.
[02:43] <Eickmeyer> Soooooo... basically, AMD controls everything, including the governor.
[02:44] <OvenWerks> It looks like we can turn turbo boost off, but not set governor to OS control... with the kernel you have
[02:44] <Eickmeyer> Strange, used to be able to do that. I wonder what changed.
[02:46] <OvenWerks> First of all, a scaling driver has to be registered for CPUFreq to work. It is only possible to register one scaling driver at a time, so the scaling driver is expected to be able to handle all CPUs in the system.
[02:47] <Eickmeyer> Gotcha. I might check a different install to see if there's an issue. If not, then it's likely my install got borked somehow.
[02:47] <OvenWerks> Al,ost like the module that got loaded was the wrong one for the cpu
[02:49] <OvenWerks> The page I am reading is for kernel 4.15... which happens to be what we have in 18.04. My liquerix is a 5.4
[02:51] <Eickmeyer> Clean install has same issue. I'm guessing the module got removed from Ubuntu or the kernel.
[02:55] <OvenWerks> If you encounter a problem while using this driver, add intel_pstate=disable to your kernel line. 
[02:58] <OvenWerks> The module you should find is acpi-cpufreq
[03:00] <OvenWerks> So far as I can tell we don't ship that... I see: amd_freq_sensitivity.ko  p4-clockmod.ko  speedstep-lib.ko
[03:00] <Eickmeyer> Just modprobed that and no response, so assuming OK. intel_pstate=disable was added to the command line. Still showing  'no or unknown cpufreq driver is active on this CPU'.
[03:01] <OvenWerks> does lsmod |grep amd
[03:01] <OvenWerks> show anything
[03:01] <Eickmeyer> https://paste.ubuntu.com/p/Dcx5jyDDDk/
[03:03] <OvenWerks> so modprobe amd_freq_sensitivity does that help or work?
[03:03] <Eickmeyer> still no or unknown cpufreq driver
[03:04] <OvenWerks> does lsmod |grep amd show it loaded?
[03:07] <Eickmeyer> Yep, shows loaded.
[03:10] <OvenWerks> and the first line of cpupower frequency-info
[03:10] <OvenWerks> doesn't show that as the driver?
[03:10] <OvenWerks> (mine says: driver: intel_pstate
[03:11] <Eickmeyer> https://paste.ubuntu.com/p/4kGwVJwrwZ/
[03:11] <Eickmeyer> That's exactly what it shows.
[03:12] <OvenWerks> no driver
[03:12] <Eickmeyer> Exactly. Something in 19.10 got screwed up.
[03:13] <Eickmeyer> Confirmed with two different installations. I might up this one to 20.04 to see if that changes anything.
[03:13] <OvenWerks> sounds like a kernel bug
[03:13] <Eickmeyer> Right.
[03:13] <OvenWerks> which release did it last work with?
[03:14] <Eickmeyer> It definitely worked in 19.04.
[03:15] <OvenWerks> liquerix includes acpi-cpufreq.ko
[03:16] <OvenWerks> *liquorix
[03:17] <OvenWerks> Eickmeyer: for the generic kernel maybe this is not a problem but for lowlatency work it matters
[03:27] <Eickmeyer> OvenWerks: Agreed.
[03:28] <Eickmeyer> I'm prepping my machine to upgrade to Focal.
[03:29] <OvenWerks> I may do that as well
[03:29] <Eickmeyer> I'm also opening autobuilds for focal.
[04:09] <OvenWerks> Ok, controls bug 1 and two fixed (pulseout remove button works now, displaying no bridge works and does not error.
[04:10] <OvenWerks> :) thankyou ubottu
[04:12] <OvenWerks> Eickmeyer: With regard to connections for pulse. A simple number still works. For example 1 is the same as system:capture_1 (and _2) (or playback)
[04:12] <Eickmeyer> OvenWerks: That's still not intuitive.
[04:12] <OvenWerks> :) no
[04:13] <OvenWerks> but it is there. I an thinking that for the first bridge set up that should be the default
[04:13] <Eickmeyer> Agreed.
[04:13] <OvenWerks> to be honest, I am not sure what would be intuitive
[04:14] <OvenWerks> (that is at the same time reasonably easy to do)
[04:15] <Eickmeyer> A drop-down with only hardware connections. No software, let patchbay software handle that.
[04:17] <OvenWerks> And not midi
[04:17] <Eickmeyer> Right.
[04:18] <OvenWerks> That would mean it could only be set if jack is actually running
[04:20] <Eickmeyer> Well, you could also make that a process where it sets right after Jack is started.
[04:21] <Eickmeyer> However it was being done before was perfect.
[04:21] <OvenWerks> Yes but... many people would expect to be able to set this before starting jack.
[04:23] <OvenWerks> The way it was done before only dealt with the default output which was expected to go to jack master. It also used two entries
[04:23] <OvenWerks> This will need some thought
[04:24] <OvenWerks> There are people who want more than what we had before
[04:24] <Eickmeyer> Then they need to use a patchbay. There's a reason we have a shortcut to Carla.
[04:25] <OvenWerks> Eickmeyer: Not the connection so much as number of bridges and naming
[04:26] <Eickmeyer> The bridges and the naming is going in a good direction. Just the default connections? That needs to be intuitive.
[04:26] <OvenWerks> Ya, I know.
[04:26] <Eickmeyer> Naming can be arbitrary. But the default connections cannot.
[04:28] <OvenWerks> Anyway, There are a few things to fix first
[04:28] <Eickmeyer> Yep.
[04:29] <Eickmeyer> I do like where it is going. It looks good, things are categorized... it's looking good.
[04:37] <OvenWerks> I think I might just do system:* and have a drop down that goes from 1-2 to 15-16 or 31-32. I will make the system:capture part of the label
[04:37] <Eickmeyer> That might work.
[04:38] <OvenWerks> (when jack is not running) when jack is running we can rebuild to the actual number the device has.
[04:38] <Eickmeyer> Not a bad idea!
[04:41] <OvenWerks> BTW, I am not going to worry about AMD cpu speeds at this point. I think it is straight driver problems and not something I can really work on.
[04:42] <Eickmeyer> Yeah, I agree.
[04:42] <Eickmeyer> Just updated to Focal, we'll see what's going on.
[04:50] <Eickmeyer> Nope, same issue.
[04:51] <OvenWerks> two bug reports? or one
[04:51] <Eickmeyer> Just the cpufreq issue
[04:51] <OvenWerks> Should be a bug report agaist 19.10 that is still there in 20.04
[04:53] <Eickmeyer> I'm not even looking at -controls right now. No cpufreq driver still in 20.04.
[04:53] <OvenWerks> right, that is where the bug should be
[04:54] <OvenWerks> -controls just deals with what the os gives it.... which is nothing in this case
[05:17] <Eickmeyer> OvenWerks: Just filed bug 1856440 against the kernel in 20.04. I doubt any bug will get fixed and backported for 19.10.
[05:45] <OvenWerks> Eickmeyer: I have fixed the errors with no pulse bridges on one side or the other
[05:46] <OvenWerks> I have not yet fixed the connection display. but I need to do other things so I pushed what I have.
[05:47] <Eickmeyer> OvenWerks: Cool