=== eickmeyer[m] is now known as Eickmeyer[m] [15:36] Eickmeyer: Cadence does not seem to do firewire checking... basically if jack doesn't start, Cadence directs the user to look in the jack log file. [15:38] Cadence does the set capture and then set playback kind of thing. I expect controls _never_ to do such a thing :) [15:41] So I will add firewire as a backend (maybe with "Try alsa first" or something) [15:42] The stuff I need to do for the FW backend is mostly the same as what I need to do for any none alsa backend [15:45] OvenWerks: Okay, that makes sense. I didn't think Cadence did much with firewire, but figured you'd find something if it existed, which, as you discovered, it does not. [15:46] But, yeah, setting capture and playback is kinda.. odd. [15:49] setting capture/playback is from internal/older devices that are like hw:0,0 is playback and hw:0,1 is record, btoh with the same clock [15:49] Oh, okay. [15:49] it does not apply to multi channel cards for the most part. [15:50] my opinion is that if they can be both opened at the same time, our normal bridging policy still works. [15:52] For FW I will assume that there is only one device and so the device will be fixed to hw:0 only [15:52] Yeah, that makes sense. [15:53] That's a good assumption. So, from what I'm understanding, FW has to be bound in the same way as internal hardware? [15:54] Cadence is trying to cover everything including macos and windows as well as every linux out there. The elif lines are long ... [15:54] Sheesh [15:54] But, yeah, he does build it for Windows and MacOS. [15:54] Though, not Cadence itself, just the other tools. [15:55] the FW driver has similar hardware nameing to alsa [15:55] RE: FW: If that's the case, if they hotplug a FW device, it won't show up in -controls if it's already running. Might need a "refresh hardware" button. [15:55] This makes sense because the fw kernel drivers were originally written for a FW-jack use [15:56] Eickmeyer: we already do that for alsa :) [15:56] Oh, okay, then we should be good. [15:57] but in this case, using fw driver relies on the user having set thing up the right way already. [15:58] so we accept fw as a driver, set device to hw:0 and go [15:58] the user will not be able to change the device or set up a hotplug USB master device as both of those boxes will be disabled [15:59] hot pluggin USB device as non-master is still ok and adding alsa devices is also ok. [16:00] So, we're talking FW must be master, basically. [16:00] yes, there is no bridge from fw to jack. [16:02] Okay, as long as the user knows that, we're good. [16:04] I am looking at the module blacklisting to see if we can just read that and get a sense what the user's setup is. === Erich is now known as Eickmeyer [18:50] * OvenWerks wonders if looking to see if snd-firewire-lib is loaded would cover all alsa fw modules. [18:52] Decent theory. [18:52] or if checking for raw1394 would be proof the FW drivers are in place. /etc/modprobe.d/blacklist-firewire.conf has this in it. [18:53] * OvenWerks wishes he had a FW device to try it out on. [18:53] looking at: https://www.alsa-project.org/wiki/ALSA_firewire_stack [18:55] So, does that mean it's already in the stack? [18:55] no that means it is prevented from loading. [18:55] Oh, duh. [18:56] the direct fw drivers for jack have to be prevented from loading if alsa is to work... and the alsa modules have to be prevented from loading if the raw fw for jack is to be used. [18:56] So, the raw1394 is blacklisted. Meaning, that the kernel doesn't have direct access to fw devices? [18:56] You just answered my question. [18:57] Is there a way to make a switch or checkbox in -controls to facilitate that module? [18:57] * Eickmeyer is spitballing [18:58] That is what I am thinking... but I am not willing to try that unless I A) have a device to play with or B) we have someone I can talk to and try things with who has one. [18:58] * OvenWerks doesn't really care which [19:00] In some ways I would prefer a FW unit that is supported both ways over one that requires the old way, but I think it is ok to assume that leaving thing stock is going to work for whatever works with alsa. [19:01] Eickmeyer: I would tend to keep two copies of blacklist-firewire.conf in /usr/share/ubuntustudio or /usr/share/ubuntustudio-controls that can be linked to depending on use. [19:02] (or copied either way) [19:03] This is a change that should be done on the system tab because it is a system change that needs root priv. and would have to be done by the same back end as rt setup and would require a reboot to work anyway. [19:05] * OvenWerks notes that some of this stuff may be done from initrd.img and so require copying rather than ln -s [19:05] So we may need to run update-grub as well. [19:05] That's crazy territory. [19:06] no not update grub, but the one that rewrite initrd [19:06] Yeah, that's what I meant. [19:06] Oh. [19:06] Um... [19:06] update-initramfs [19:07] It would probably be better for us to do that than try to write a document. [19:08] If we can incorporate something into -controls rather than write a document, I'm all for it. The less work the user has to do the better. "Teach a man to fish" as they say. [19:09] The command is actually "update-initramfs -u" otherwise it will throw an error. [19:09] details... [19:10] hehehe [19:10] The big detail is access to a box. [19:13] You mentioned something about a guy with a boat anchor? [19:13] I think if I were to create a script (in bash) to switch to the old drivers and recreate the initramfs with the ability to undo the same... I may be able to send it that guy to test. [19:13] I suspect he would be happier getting his box to work over giving to someone else who makes it work for themselves [19:14] Probably. [19:14] The USB replacement is $500ish and I think the one he has cost closer to $1000 [19:16] Considering the price of equivalent tech gets cheaper with time... [19:17] I acn't aford to buy it, Shipping I could probably handle though. I would have to acquire a pcie (or pci) card with FW ports which start at $21 [19:20] Not hard to find the pci cards. I had one I wasn't using a few years ago. [19:20] I thought my laptop had a port (10 year old Dell) but I checked and couldn't find it [19:21] (its slow anyway) [19:21] I had an old Toshiba laptop that had a PCMCIA slot for which I bought a FW card. [19:22] That was about 13-14 years ago. [19:22] I would prefer pcie as the next computer I buy may not have pci slots. It was not easy to find a MB with 3 PCI slots a few years ago when I got this one. [19:22] I'm sure Amazon has something for cheap. [19:23] If I had the FW box and a PCIe card it would mean I wuld still have a working audio inteface if I can't find a slot for my delt66 [19:23] Canadian dollars are only 74.9% of US [19:24] so $21 is like $15 [19:24] Yeah. I just found something for $19US. [19:24] Now one for 17 US. [19:25] So, relatively inexpensive, probably because the peripheral support just isn't what it used to be. [19:25] I use two PCI cards right now, The Delt66 and an AudioPCI for MIDI [19:26] I was able to avoid the pci slot that shares irq with 5 other bits [19:27] I was also able to find a MB with midi din for both keyboard and mouse :) [19:28] I just have my one USB audio interface and one USB MIDI controller. [19:30] I do have a pair of studio monitor speakers on the way. Going to use those to demo Ubuntu Studio at Linux Fest Northwest later this month. [19:34] cool. [20:24] it looks like raw1394 is the module to look for, if it has not been loaded at boot time, I can assume there is not FW device. [20:31] So unblacklist and modprobe? [20:36] Anyway, I sent an email to Rick (I think) [20:36] unload whatever alsa has loaded first [20:37] I don't know if it can be done realtime or needs a reboot. [20:41] If modprobe is involved, no reboot needed. [20:43] ya, in this case it is knowing which all modules to unload first