[17:53] <Eickmeyer> OvenWerks: studio-controls crashes in the live session if it has no config file. I'll throw a bug report as soon as I can.'
[17:54] <OvenWerks> Eickmeyer: can anything write to the home directory when running this way?
[17:54] <Eickmeyer> Yes, we should be able to.
[17:55] <Eickmeyer> Granted, it gets erased on reboot (goes to ram).
[17:55] <OvenWerks> ram is fine
[17:56] <Eickmeyer> I'm filing a bug report because we're beyond beta freeze.
[17:56] <Eickmeyer> Beta is tomorrow.
[17:56] <OvenWerks> on the iso does .config exist? I am guessing ./config/autojack does not but it should be created in convert
[17:57] <Eickmeyer> ~/.config does exist for any and all users.
[17:57] <Eickmeyer> mkdir -p (or equivalent) is good for this use case.
[17:57] <OvenWerks> I am wondering if running convert on startup before autojack runs would help.
[17:58] <Eickmeyer> You mean, put it in the autojack-start I made?
[18:02] <OvenWerks> yes, if it runs before anything else, it checks to make sure ~/.config/autojack exists and creats it if not.
[18:02] <OvenWerks> then it writes a config file
[18:04] <Eickmeyer> That would work. Bug is filed, bug 1944607
[18:11] <OvenWerks> Eickmeyer: pushed, do you want to look at autojack-start to make sure it makes sense?
[18:17] <Eickmeyer> I'll take a look at it in a sec.
[18:18] <OvenWerks> release as 2.2.3 if it looks right
[18:21] <Eickmeyer> OvenWerks: It didn't work.
[18:22] <OvenWerks> can you run convert from commandline?
[18:22] <Eickmeyer> Yep. Let me get you the output.
[18:24] <Eickmeyer[m]> $ convert-studio-controls... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a7ed038ab80a8c516ce2efeac4b11af3d33e3af1)
[18:24] <Eickmeyer> OvenWerks: ^
[18:25] <Eickmeyer> (Matrix makes for a good pastebin)
[18:25] <OvenWerks> I am just looking at the autojack code and it looks like we log stdout but not stderr
[18:26] <Eickmeyer> Interesting.
[18:26] <OvenWerks> this has been why pastes people have left in issues have not shown the error
[18:27] <Eickmeyer> That makes sense.
[18:33] <OvenWerks> This is tricky. The obvious fix is to test for 'none' at that line... but there should never be a device called none and to get to that line there would have to be
[18:34] <OvenWerks> Eickmeyer: if there is a USB device plugged in at boot and no config file, that USB device will become jack master by default.
[18:34] <OvenWerks> is that good or bad?
[18:35] <Eickmeyer> Shouldn't it be internal audio as master by default?
[18:35] <Eickmeyer> I mean, unless that's too complicated to do.
[18:39] <OvenWerks> Eickmeyer: sorry, it only does that if it can't find anythng else to use as default
[18:39] <OvenWerks> So that is fine
[18:39] <Eickmeyer> Yes, that's 100% OK.
[18:40] <OvenWerks> so if someone has their on board audio disabled in bios...
[18:40] <Eickmeyer> Imagine...
[18:40] <OvenWerks> But it looks like we add the usbdev even if it is 'none'
[18:41] <OvenWerks> I actually used to disable the internal audio... I only turned it back on so I could test things.
[18:41] <Eickmeyer> Well, I mean, if that's what it takes and doesn't fundamentally break anything.
[18:43] <OvenWerks> Eickmeyer:  I have: if def_config['USBDEV'] not in devicelist and def_config['USBDEV'] != 'none':
[18:43] <Eickmeyer> That *should* work.
[18:44] <OvenWerks> I am wondering if that is effectively: if def_config['USBDEV'] not (in devicelist and def_config['USBDEV'] != 'none'):
[18:45] <OvenWerks> changing to: if def_config['USBDEV'] != 'none' and def_config['USBDEV'] not in devicelist:
[18:55] <OvenWerks> Eickmeyer: it works as is in 20.04 :P
[18:55]  * OvenWerks thinks python may have changed
[18:56] <Eickmeyer[m]> I'm talking about the live session prior to any config being made.
[18:56] <OvenWerks> that is what I am testing
[19:01] <Eickmeyer[m]> That's very possible. We've got 3.9 in Impish.
[19:04] <OvenWerks> Ok braces to check coming up :P
[19:09] <Eickmeyer[m]> Sounds good.
[19:10] <OvenWerks> uploaded can you try that one?
[19:11] <OvenWerks> Eickmeyer: ^^
[19:13] <Eickmeyer[m]> OvenWerks: Working on it now.
[19:18] <Eickmeyer[m]> OvenWerks: I directly ran it, no good. Same issue.
[19:18] <Eickmeyer[m]> $ convert-studio-controls... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/73a602032dcd8d7ac51069ebaa4cf19033e16bd6)
[19:21] <OvenWerks> ok. so something else is adding a 'none' device
[19:28] <OvenWerks> Eickmeyer[m]: another try.
[19:28] <Eickmeyer> Ok
[19:31] <Eickmeyer[m]> OvenWerks: Still no good.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/cbbd2f5720c4fac429d420d8c5c08816d6a53bc6)
[19:48] <OvenWerks> Eickmeyer[m]: something is happening I don't understand, I have added some debugging lines
[19:49] <OvenWerks> Eickmeyer[m]: do you actually have a device called none,0,0?
[19:49] <Eickmeyer[m]> OvenWerks: Looking. What command would show that?
[19:49] <Eickmeyer[m]> (I'm running it in a VM)
[19:50] <OvenWerks> aplay -l
[19:50] <Eickmeyer[m]> **** List of PLAYBACK Hardware Devices ****
[19:50] <Eickmeyer[m]> card 0: I82801AAICH [Intel 82801AA-ICH], device 0: Intel ICH [Intel 82801AA-ICH]
[19:50] <Eickmeyer[m]>   Subdevices: 1/1
[19:50] <Eickmeyer[m]>   Subdevice #0: subdevice #0
[19:51] <OvenWerks> That should be ok
[19:53] <OvenWerks> however, on the off chance there is such a thing, I guess I should check for that. But before that. I would like to see the output of what I just did
[19:53] <Eickmeyer[m]> Ok. I'll look at your latest commit.
[19:56] <Eickmeyer[m]> OvenWerks: Using what you did:
[19:56] <Eickmeyer[m]> $ convert-studio-controls... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a3ffccf88d14b3d6cec8a7314ad61d9642bd53ac)
[19:59] <OvenWerks> it says it think you have a device named none... I need to check that more. another upload coming soon
[20:00] <Eickmeyer[m]> Ok.
[20:00] <Eickmeyer[m]> I've got this one as release blocking. The release team wasn't happy when I told them that.
[20:06] <OvenWerks> Eickmeyer[m]: what does tyhis get? cat /proc/asound/card*/id
[20:07] <Eickmeyer[m]> I82801AAICH
[20:08] <OvenWerks> that should give I82801AAICH,0,0 as default device
[20:09] <Eickmeyer[m]> Right.
[20:18] <OvenWerks> Eickmeyer[m]: another one to test (bug should be gone but printout is still needed
[20:25] <OvenWerks> Also a paste of: ls /proc/asound/I82801AAICH or /proc/asound/card0
[20:26] <OvenWerks> if either of those error, maybe: ls /proc/asound
[20:29] <Eickmeyer[m]> OvenWerks: Ok. Sorry, had a phone call.
[20:32] <Eickmeyer[m]> OvenWerks: $ ls /proc/asound/I82801AAICH
[20:32] <Eickmeyer[m]> codec97#0  id  intel8x0  pcm0c  pcm0p  pcm1c
[20:32] <Eickmeyer[m]> card0 returns same
[20:32] <OvenWerks> that is different
[20:32] <OvenWerks> Is that an AC97 card then?
[20:33] <OvenWerks> If so, alsa has changed the way they deal with them
[20:33] <Eickmeyer[m]> Well, it's virtual.
[20:34] <OvenWerks> even virtual that would be a change
[20:34] <Eickmeyer[m]> It's basically a Virtualbox passthrough masquerading as an Intel chipset.
[20:35] <OvenWerks> But that is ok. it should still be treated the same as a PCI audio device
[20:38] <Eickmeyer[m]> Agreed. Pulseaudio is OK, so perhaps some changes kept up with Alsa there. The question then is, how do we solve this in studio-controls?
[20:39] <OvenWerks> I need a new paste of my latest upload
[20:41] <Eickmeyer[m]> Ok
[20:41] <OvenWerks> I have fixed two things and need to know which one fixed your error
[20:41] <OvenWerks> (or if both failed ... sigh)
[20:42] <Eickmeyer[m]> I think it worked this time:
[20:42] <Eickmeyer[m]> convert-studio-controls... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4a27b7d6d68028fecaade375ebf0d2e848c9ac1c)
[20:42] <Eickmeyer[m]> Trying one more time for good measure.
[20:43] <Eickmeyer[m]> We're good. \o/
[20:43] <Eickmeyer[m]> $ convert-studio-controls... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0634de3e1806233c8d8604cc4534a6a42865e633)
[20:43] <OvenWerks> I have also fixed things for an audio card with the id 'none'
[20:43] <Eickmeyer[m]> Sweet.
[20:43] <OvenWerks> ok, I should remove some of the debug messages
[20:44] <Eickmeyer[m]> Feel free to tag/release when ready, I'll get this uploaded and tell the release team we need it expedited.
[20:53] <OvenWerks> Eickmeyer[m]: released
[20:54] <Eickmeyer[m]> OvenWerks: On it.
[20:57] <OvenWerks> Eickmeyer[m]: that would have effected anyone without a standard hda device (if those are still shown the same way in 21.10)
[20:57] <Eickmeyer[m]> OvenWerks: Either way, it will prevent an embarrassing situation where one of our core components is utterly broken for people trying it.
[20:58] <OvenWerks> it did not help that I can not reproduce on this machine
[20:59] <Eickmeyer[m]> Yeah, I get that. This is why it's useful to have people like me around to do these smoke tests.
[21:00] <OvenWerks> I had switched two operations around and only when there is an HDA device does it work.
[21:01] <OvenWerks> It is what comes from adding complexity to existing code
[21:01] <OvenWerks> anyway, I am likely not available for the rest of the day to more than answer
[21:15] <Eickmeyer[m]> OvenWerks: Ok, sounds good. I think I've got it from here.
[21:34] <Eickmeyer> OvenWerks: Uploaded, once I get the migration email from proposed I'll be able to respin the iso.
[21:40] <OvenWerks> Eickmeyer: I have heard some good talk about PW on Ardour lately. It seems latencies are much closer to expected.
[21:40] <Eickmeyer> Oh, that's great!
[21:42] <OvenWerks> BTW, 21.10 kernel seems to actually load the alsa module for the fireworks chip again, though performance is still unacceptable
[21:42] <Eickmeyer> That's disappointing.
[21:44] <OvenWerks> So far as I can tell, PW still only conects to jack if jack asks for device access, so using jack for ffado and pw for everything else doesn't work
[21:46] <OvenWerks> wtay says the jack bridge can't be added manually but I would guess it can be just looking at some of the cli options for it's controller utility
[21:47] <Eickmeyer> Possibly. Sounds like he's got some feature completeness to work on.