[00:41] s/in/unin/ [12:28] Heh, i wish. Sadly I'll never get the native instruments stuff to work on Linux. Got close, but they use bome midi wish installs a driver so no wine. [12:29] Also, until proton fully supports DXR 1.1 i still need Windows for Cyberpunk. [12:35] s/wish/which/ [12:36] If you ever do have audio software that does run under wine WineASIO is awesome. [12:44] Oh, damn, this FW card is even better than expected. [12:44] looking for it after popping it in I it shows up as two devices. [12:44] 08:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) [12:44] 09:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) [12:45] So, I wondered and.... [12:45] IOMMU Group 27:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/119d23a3f94dbc9cabf29c2d44c1bf02969e11b3) [12:45] each fw chip (there are two on the card) is in its own IOMMU group. Which means one can be passed through to windows. :-D [13:53] BrianHechinger[m: the distribution of WineASIO as a binary is illegal, but is fine if compiled as a source. See https://wiki.ubuntu.com/wineasio [13:54] Hence, we can never carry it. [13:54] winetricks installs it so that's good enough I guess? [13:55] I mean, sure. [13:56] The source itself is fine to distribute since the sources are redistributable. The binary is made from incompatible licenses and is not redistributable, so it's a mess. [13:58] That does sound like a mess. And kinda pointless if your ask me. [14:03] It is, but a lot of it is because Steinberg doesn't understand the meaning of open source. [14:08] Ugh. What a hassle. Time for some self building binary technology. 😜 [14:10] They also licensed the VST3 SDK as non-redistributable without express permission from them OR if licensed as GPL3, developer discretion. Debian took the stance of "You can't do that", so we can't have VST3 plugins in the repos. [14:11] In all honesty, Steinberg can't do that, they needed to pick one route or the other, they can't have their cake and eat it too. [14:13] Right? [14:15] Tons of discussion on this has happened at #lad:libera.chat, so falktx in all his wisdom reverse-engineered the vst3 SDK (clever, eh?) [15:12] Yeah, that was a good way to handle it [15:13] Ok, so now I have two firewire devices on my computer up to the point where the VM starts. Is there a way to get jack (via studio controls) to use only one of them or am I best off setting the VM to start and boot so the second device is captured by the VM before jack starts so it's not visible to jack? [15:14] Oh, I can blacklist it in studio-controls. Is that good enough? [15:15] Should be, but I'm no expert on FW. OvenWerks, if you're around ^ ? [15:15] nope, doesn't look like that does the right thing. [15:16] jack came up with the audiofire4 instead of the saffire pro [15:16] I wonder if it just picks the first one from the list [15:17] because the AF4 is on port 0 and the saffire on port 1 [15:18] Ah ha! [15:18] that does indeed appear to be the case [16:24] BrianHechinger[m: Huh, well that explains things maybe. [16:25] BrianHechinger[m: I note that I have /dev/fw0 and /dev/fw1 [16:26] You may recall, I had no luck getting one of my cables to work and got another. The difference being That the first was 6pin and the second 8pin. [16:28] Right now with the way jackdbus is called, it just uses the default fw device (/dev/fw0) [16:28] Explains what things? [16:28] It could well be that the 6pin jack is connected to /dev/fw1 [16:29] This new card only has 8 pin connectors [16:29] So maybe if I had set jackdbus to to use fw1 my 6pin cable would have worked [16:29] Oh [16:29] I don't think so [16:29] Mine has two 8pin and one 6 pin [16:29] There are 4 ports [16:30] And I'm plugged into the middle two [16:30] So it's signing fw0 to the first device it finds and few to the second [16:31] s/signing/assigning/ [16:31] s/signing/assigning/, s/few/fw1/ [16:31] Which is typical Linux behavior [16:32] Studio-controls is not set up to handle any fw device exceopt fw0 (or rather it doesn't pick any device) [16:32] Ok, that tracks with what i saw then. Whichever device is fw0 is what controls attaches jack to [16:33] Which is perfectly acceptable behavior for my needs [16:34] I did think at the time I would like to be able to pick which device to use but, not having two devices to play with, wasn't sure how to go about that or how to test it. [16:35] However, if my card actually puts the 6pin plug on fw1, I may be able to test that. [16:35] It's only going to do that if there is another device getting assigned to fw0 [16:36] At least now that the alsa fw module seems to work(ish), it should show up there. [16:36] huh [16:36] not helpful then [16:37] ffado-test ListDevices (or whatever it's called I'm in my phone) should list the devices it sees without the need for Jack or ALSA talking to the device. [16:37] s/in/on/ [16:45] https://paste.ubuntu.com/p/CWBdHqPgxh/ [16:45] it doesn't matter which ports they're plugged into, at the firewire layer it instantiates them in the order it finds them. [16:45] so it's always Port 0 and Port 1 [17:12] when I use ffado-test ListDevices I only see one device but I still see fw0 and fw1. That is whay I am wondering if the fw0 and 1 are a part of the PCIe card rather than the devices. [17:13] Or it may be that fw0 is the card and fw1 is the device... [17:13] what do you see for ls /dev/fw* [17:14] Hmm, it appears I've forgotten to enable the ssh server on my desktop so I'll have to check later. [17:14] No worries. [17:14] I could have sworn i enabled that. Weird. [17:15] Haha, nevermind. I just haven't connected from my phone since before we moved so it still had the old IP. 🤣 [17:16] ➜ ls /dev/fw*  /dev/fw2 /dev/fw3 [17:17] That makes sense because they other two ports are currently passed through to the VM so they "don't exist" from Linux's point of view currently [17:18] Ah, ok so one for the card and one for the device [17:18] But, that tells me that all physical ports on the card get a fw device no matter if something is connected [17:18] Which makes sense for a bus device [17:18] No, those are for the card [17:18] Not the device [17:18] I wonder what happens when they are chained. [17:19] I don't have any 6 to 6 cables handy so unfortunately i can't check [17:21] Anyone else kept their 20.04 install and tried updating themselves to 22.04 and kde? I'd like to adjust my sources and keep my install if I can pull it off. Switching away from Ubuntu studio specific repos is fine if that helps. Thoughts appreciated. [17:21] the ffado backend is supposed to be able to handle chains of up to three devices I think. [17:22] sunjam[m]: [17:22] sunjam: upgrading felt like a bad idea so i did a fresh install [17:22] But I'm setup to do that easily [17:23] sorry I think going from 20.04 to 22.04 is not recomended because of the DE change [17:23] Oh, yeah, i was on 21.10 (which had the new DE) and still felt like upgrading was a bad idea. 😜 [17:26] OvenWerks: I just powered down the VM so the other two ports came back: [17:27] ls /dev/fw* [17:27]  /dev/fw0  /dev/fw1  /dev/fw2  /dev/fw3 [17:28] "sorry I think going from 20.04..." <- I understand. That is why I'm asking [17:29] OvenWerks: is enabling backports a reasonably idea? [17:29] BrianHechinger[m: Thanks. Not sure what I can do with that [17:29] BrianHechinger[m: in what context? [17:30] OvenWerks: Basically, I think what I'm getting at is using /dev/fw* as the options in studio-controls isn't going to work. those aren't the actual devices. [17:30] OvenWerks: in the context of am I going to suffer for it or will it just be good getting newer stuff if possible? [17:30] sunjam[m]: If I was going to try it, I would tend to copy my working partition to a second partition and try with that [17:32] BrianHechinger[m: backports is recomended. There are many times where bugs are fixed in new versions but because there are more than bug fixes they can't be SRUed [17:32] ok [17:32] (studio-controls is one of them) [17:33] It is always possible to go back to the release version with muon if you have trouble [17:35] weird, I enabled backports but I don't have the new version of controls available [17:36] sunjam[m]: I think the best way is to have more than one partition, One for your home directory, one for the the current system and one for the new system. [17:38] sunjam[m]: I use 40G partitions for the system and everything else for home. (actually it is more complex than that in my case) [17:44] In my case, I keep my home directory quite small and have links to working directories (software, audio projects, documents, etc.) Then after a new install, I copy the home directory (cp -a) into the new partiton and do a double move: mv user user.inst then mv user.old user (I do the move with the DE logged out from a terminal ctr/alt/F2) [17:45] Like I said, more complex and maybe not needed. [18:14] OvenWerks: 40G is enough? I've been meaning to do that [19:31] cfdisk says 39.1g ;) [19:32] but I am pretty sure when I made them with the partition manager I used 40000 Mb [19:34] BrianHechinger[m: also note that I have added the whole ubuntu build stack and all the extra libs and dev files to build ardour and other stuff but the build directories themselves are on a different partition [19:41] not many years ago I used 20g [19:41] The extra 20g is mostly to deal with the extra stuff I install. [20:03] I'll have to check and see what my issue is [20:03] I really miss ZFS [20:03] But I'm not thrilled with ZFS on Linux [20:04] You could use it for the system and use something else for home