[15:24] Eickmeyer: I have jack detection working nicely with no extra threading of GUI delay. [15:26] Eickmeyer: I am working on adding backends (firewire and dummy) but could really do much better with a firewire device to play with. I think no one has a device we can test with for example. [15:28] with the backend switch, if the driver is not alsa, I pretty much have to set device to default (this assumes anyone has only one FW device hooked up) and the usb master has to be disabled as well. There are some other things that have to change such as the extra devices have to include whatever just was the alsa jack master. This may be a bigger change than I thought :P [15:30] The other problem is that in order for the FW backend to even work, kernel modules need to be changed. That is the user has to do so system work to even get that far. [15:30] The alsa fw module needs to be removed/blacklisted and the fw modules need to be loaded at boot too. [15:32] I am wondering if we should be worrying about backends at all. FW is for most purposes legacy at best while still being supported by alsa these days. [15:35] However, the few people who do use them have paid a significant amount for them (likewise for my delta66) and would like to keep using them till they croak. The alsa fw experience is not always great, mostly because the code from the FW project was ported into the alsa code without having the various boxes available for testing. So people still want to use the old drivers :P [15:38] So backend support will be rudimentry at best. Mostly an I hope it works solution. AVB may help me get it better, I don't know. [15:44] After more thought... I think I am trying to do the same thing in too many places. I think I will break the device list stuff out of init into it's own call so it can be called any time something changes in that regard. Those times are: at init. if the driver changes, if the master device changes, if the default output changes, if other devices are connected or disconnected. [15:45] I am working on the GUI first... I still have the daemon to do after that. [15:47] Oh, one more thing I don't know how to do (maybe cadence code will help?) is to check if the fw drivers are even there before allowing fw to be selected as backend [17:09] * Eickmeyer wakes up and reads the backlock [17:09] *lgo [17:09] *log [17:09] * Eickmeyer gets coffee [17:10] OvenWerks: Is there a specific config file we can make and throw into -default-settings? [17:10] kernel module blacklisting is pretty easy from that perspective. [21:37] Ya blacklisting easy enough, but should we? My thought is that I hope for most people the alsa fw mod just works. The problem is that when it does just work, we don't hear about it. We only hear about the ones that don't. [21:46] Then perhaps some documentation might be in order. [22:05] OvenWerks: Do you think that's worth something in the release notes? [23:21] Not for 19.04 I think. To be honest do any of us know enough to to make a note that is worth while? [23:24] OvenWerks: Probably not. If it's for legacy hardware, I imagine they would find a way to make it work. If they do, then they just need to blacklist the fw modules themselves. [23:25] fw has never been plug and play I think. [23:25] It has always been a tinker's interface. [23:26] on the other hand, to get really good performance from USB interfaces takes some work too. [23:27] Also, fw is dead anyhow, considering USB has far surpassed it. Despite Apple's best efforts, they eventually caved too. [23:28] USB takes time, but the key is with the 1ms multiple. [23:28] aka 3 buffers per period. [23:28] I think AVB/aes67 will be the same [23:28] So then, we just need to pour our efforts into USB & AVB/AES67.