[15:50] @teward001 I completely forgot about lp:new-session-manager and lp:dragonfly-reverb needing reuploads. [15:51] new-session-manager had a binary namespace issue and dragonfly-reverb had some unused copyright lines (upstream removed a lot of stuff). [16:52] Eickmeyer: sorry for the rant to the rant on the mail list... [16:52] OvenWerks: No, I 100000% agree with you, but not sure about the PC going away. The gaming market is too rich. [16:54] My method was deflection, your method was more pointing-out how myopic his assumptions are. Unfortunately, that's the author of our (now outdated) audio handbook which may end-up disappearing. [16:54] Eickmeyer: those guys: A) don't buy PCs, they make them and B) are willing to spend mac like prices or more. [16:56] Eickmeyer: I do not know of any local computer store where one can go in and buy a game ready PC. [16:56] maybe I am looking on the wrong shelf or something [16:59] Eickmeyer: can I get you to test something? If you have a copy of carla 2.2 around still. [17:00] If you could try the recipe in my last comment at: https://github.com/falkTX/Carla/issues/1237 [17:00] See if either Carla freezes or at least zita-a2j seg faults [17:00] @Eickmeyer [@teward001 I completely forgot about lp:new-session-manager and lp:dragonfly-rev …], ok i'll add it to the list [17:01] OvenWerks: I'll give it a shot. [17:02] I have found the fresh reboot is not needed... untill after :P [17:08] OvenWerks: I don't know how to accomplish step 2. What's the command line for that? [17:09] jack_control start [17:09] studio controls uses jack_control intyernally [17:10] so it is ok to start jack using controls [17:11] Eickmeyer: ^^ [17:13] OvenWerks: I just tried it, and by step 9 could not reproduce. Carla is not frozen for me. [17:13] However, zita-a2j did segfault. [17:13] you will find it does not with carla 2.1 I think [17:14] I'm using Carla 2.2-RC1 in groovy. [17:14] I think carla has a bloated jack callback [17:14] Well, like I said, couldn't reproduce starting at step 9. [17:15] Carla did not freeze for me. [17:15] quite probably a callback for jack graph change or something [17:16] I understand. That may be a difference in usb hardware or cpu or whatever [17:17] That's my guess. In this case, I'm using an old 2010 Mac Mini as the hardware. Didn't test with my main system which uses a USB audio interface (not a cheap one) as its main sound card 90% of the time. [17:17] It is interesting that zita-j2a for me does not freeze Carla but does also segfault [17:18] That tells me there might be an issue with the zita-ajbridge code. [17:19] possibly, but it doesn't matter if it is zita-ajbridge 0.8.2 or 0.8.4. I tried both [17:20] control c is the correct way of stopping zita-ajbridge BTW. anything else leaves a zombie process. [17:20] it is also what the author says. [17:22] Huh. Still, a segfault is pretty bad. [17:23] I think what happens is that zita when it receives the ctrl c: removes it's jack ports and then tries to shut it's client and fails because carla, on getting a graph changed callback is still busy and so the client close segfaults. [17:24] many of the jack callbacks are RT (have to complete within one cycle) and are not supposed to include any call to the jack api. [17:25] in my code I have had to save the callback info, set a flag and then have some other code take care of the info saved. [17:25] Certainly in python but I also do so in c/c++ code [17:28] Gotcha. Ok, then it comes down to that I couldn't duplicate your issue using a USB headset I own. [17:29] My biggest issue, and what is probably bugging me most at the moment, is how the pulse bridge in Studio Controls in Fedora isn't working properly, if at all. [19:18] Eickmeyer: I have a spare partition (20G) I could install if there is an ISO. [19:32] * OvenWerks has some Ardour work to do too... [20:45] Eickmeyer: ok, I was just being dumb and tired as I so rarely do pristine-tar stuff. glad you got redkite done :) [20:55] OvenWerks: Yeah, there's an ISO, let me see if I can get the link for you. [20:56] RikMills: So, what I do is "pristine-tar list" which returns a list of what can be checked out. Then I do "pristine-tar checkout {latest tarball}". Then I "mv {tarball} .." to get it in the parent directory. After that, it's just a matter of "debuild -S (-d)" and an upload. [21:00] OvenWerks: What I have won't represent F33 very well (because it's rawhide, and F33 branched earlier this week): https://kojipkgs.fedoraproject.org//work/tasks/3671/48863671/Fedora-Jam_KDE-Live-x86_64-Rawhide-20200807.n.0.iso [21:19] Eickmeyer: yep, I was just not thinking properly [21:20] RikMills: Happens to all of us. :) [21:23] indeed (insert Teal'c gif) [21:33] Eickmeyer: ok I will check this one first... then maybe upgrade or wait for an iso I can play with. [21:47] Eickmeyer: RE: https://bugs.launchpad.net/ubuntu/+source/jackd-defaults/+bug/1872244 there is no such package that I can see... and it looks like user trouble rather than an actual fault [21:47] Launchpad bug 1872244 in jackd-defaults (Ubuntu) "Jack audio not working on Ubuntu 20.04 running on a Thinkpad Carbon X1 (7th gen)" [Undecided,Confirmed] [21:54] OvenWerks: To be fair, the Rawhide ISO is fairly close. About a week ago they pushed a change to the build system which broke Jam, and they're just now getting it fixed. I use Rawhide because it's developed alongside F33 at this point, and will be until F33 releases. [21:56] OvenWerks: RE bug 18722144, I just invalidated it. You're absolutely right, that was a support request, not a bug. [21:56] Error: Launchpad bug 18722144 could not be found [21:56] er... bug 1872244 [21:56] bug 1872244 in jackd-defaults (Ubuntu) "Jack audio not working on Ubuntu 20.04 running on a Thinkpad Carbon X1 (7th gen)" [Undecided,Invalid] https://launchpad.net/bugs/1872244 [21:58] Eickmeyer: the iso DL keeps dumping out... oh well half way through [21:59] That's very strange. It shouldn't, koji is the "source of truth" for the builds. [22:00] right now it says paused [22:01] must have been a bad keystroke [22:01] bad keystroke? [22:01] That paused it. [22:01] Ah, downloading now? [22:02] but it failed about 20 sec after resume... restarted and quite again. [22:02] Ok, maybe I can get it on my nextcloud. [22:04] Oof, upload is going to take over an hour. Keep trying. [22:05] seems to be stuck at 1.3 Gb [22:06] Might be because Koji isn't mirrored, so you're downloading directly from the datacenter in WA DC. [22:07] Though, I'm experiencing some slowness too. Might just be congestion everywhere. [22:27] my restart from 0 made it past 1.3 this time. [22:27] Oh good. [22:27] My upload still has 39 minutes, so it would be nice if your download finished before my upload. [22:31] now failing at 1.8... [22:38] *sigh* [22:40] made it to 1.9 [22:47] Well, that's progress. [23:02] firefox fails to open a file browser... I think it is hard coded to nautilus :P [23:02] anyway, it finally finished [23:03] It shouldn't. It's hardcoded to xdg-open. [23:07] maybe kubuntu does not have that set up... or maybe I am remembering xfce but that was set with thunar as favoured file manager [23:08] everything else opens the right file browser [23:08] In Groovy xdg-open is set for Dolphin. [23:10] Studio Groovy.