[05:30] <Eickmeyer[m]> OvenWerks: This came up in #lad. https://linuxmusicians.com/viewtopic.php?f=4&t=21728
[05:30] <Eickmeyer[m]> What are your thoughts about adding that to the kernel command line for lowlatency?
[06:57] <OvenWerks> That is something we can try ... the threadirqa, not the mitigations=off
[06:58] <OvenWerks> The second would be ok for studio only machines.... don't use it when connected for sw updates.
[07:00] <OvenWerks> but I wouldn't want it baked in to an ISO or package
[07:01] <OvenWerks> I don't think I would even want it in a wiki or other docs
[16:05] <Eickmeyer[m]> I was referring to threadirqs. I wouldn't want mitigations=off under any circumstances.
[16:07] <OvenWerks> Eickmeyer[m]: to be honest, I have not done any latency testing for some time now.
[16:07] <OvenWerks> I don't really have time...
[16:07] <Eickmeyer[m]> It's all good. I was just curious what your thoughts were about making it a default.
[16:07] <Eickmeyer[m]> I mean, I could probably handle that much.
[16:09] <OvenWerks> Certainly the D66 is a great device for testing this as it is known to be able to run at jack with 16/2 and so shows latency problems better than other devices
[16:11] <OvenWerks> I don't know where we would put that to get it on the command line without trampling on top of other packages.
[16:11] <OvenWerks> and without making it so the user could not find it.
[16:14] <Eickmeyer[m]> It'd just go in lowlatency settings. It's just a kernel command that belongs in grub.
[16:15] <Eickmeyer[m]> Either that or I can ask the kernel team to enable the threadirqs flag.
[22:30] <OvenWerks> yuck!... ok headphone plugged in can be found with:
[22:30] <OvenWerks> amixer -D hw:PCH cget iface=CARD,name='Front Headphone Jack'
[22:31] <OvenWerks> The answer is:
[22:31] <OvenWerks> numid=40,iface=CARD,name='Front Headphone Jack'
[22:31] <OvenWerks>   ; type=BOOLEAN,access=r-------,values=1
[22:31] <OvenWerks>   : values=on
[22:34] <OvenWerks> My python alsa binding does not have that one, so read in the values from the command.
[22:35] <OvenWerks> Eickmeyer[m]: can you run the above command on your machine?
[22:36] <Eickmeyer[m]> Oh boy... uh.... I could but it wouldn't be effective as the machine I'm on doesn't exactly do headphone recognition to begin with.
[22:36] <Eickmeyer[m]> It's a desktop system.
[22:36] <OvenWerks> :)
[22:37] <OvenWerks> Imjuust ran upstairs to the old (32 bit) laptop... it says:
[22:37] <OvenWerks> amixer: Control hw:PCH open error: No such device
[22:37] <Eickmeyer[m]> Oof.
[22:38] <OvenWerks> Which is not too bad... as the phone switching is hw based anyway.
[22:39] <Eickmeyer[m]> At some level there's a software switch. I'd have to dig-out my laptop to experiment.
[22:41] <OvenWerks> AH, but amixer -D hw:0 cget iface=CARD,name='Headphone Jack' works
[22:42] <OvenWerks> So, there seem to be two variants... those that use Front and those that do not
[22:43] <OvenWerks> The jack is front headphone and the speaker is speaker or front.
[22:44] <OvenWerks> but this laptop does not have a HP level control. So make sure a headphone level exists before muting line out.
[22:44] <OvenWerks> or speakers
[22:45] <OvenWerks> this one has line out so it is safe... all control changes fail :)
[22:46] <OvenWerks> Eickmeyer[m]: if you are experimenting... alsactl monitor
[22:46] <OvenWerks> will show changes and give the name.
[22:47] <Eickmeyer[m]> Ok. One problem: ERR:WifeOnVacation
[22:47] <Eickmeyer[m]> Trying to spend some time with her and my son and less time doing dev work this week. :)
[22:48] <OvenWerks> Thats ok. I think I can figure it out
[22:48] <Eickmeyer[m]> OK. Sorry I can't be of much help right now.