=== cpaelzer__ is now known as cpaelzer [06:06] good morning [06:07] * didrocks reboot in a single monitor for Trevinho [06:14] duflu: FYI, I rebooted without drm modeset=1 for nvidia. Let's see if I trigger slowness/freeze, but for now, nothing [06:14] the scaling issue is still here though [06:15] didrocks, please also check you don't have something busily writing to the journal. Because journal flushing also happens every 5 seconds and will freeze a program [06:15] Morning didrocks :) [06:16] duflu: hey! Well, possibly related to io. It's mostly when I'm opening/closing apps [06:17] (most of the time, not necessary a rule) [06:17] didrocks, If you have a HDD LED to look at then that helps :) [06:17] Also strace [06:17] duflu: unsure what to strace? [06:17] didrocks, write or fsync calls etc [06:17] yeah, but which prog? [06:18] didrocks, gnome-shell maybe? But yeah it could be anything if kernel journal flushing is the issue [06:18] and the question, is why it started for RAOF and I when it was ok beforehand and it seems it doesn't happen without drm modeset=1 [06:18] but my journal doesn't file up [06:19] like, nothing is spamming it [06:19] didrocks: Nah, it happens for me with nvidia_drm.modeset=0 [06:19] RAOF: argh, maybe it sounded only better here :/ [06:19] That's fine. Unfortunately I'm being harassed in upstream work so I'll have to get to this bug next week [06:19] final freeze is next Thursday [06:19] Unless I have a particularly lucky Friday [06:20] I don't think we can release with this, with a very small portion of testing, we have already 2 users with it [06:20] Yeah, no disc IO for me. [06:20] so I don't want to imagine at scale :/ [06:20] RAOF: just got one without disc IO? [06:20] Still, it involves me changing and configuring new hardware. I will get to it ASAP [06:21] didrocks: Mine have *never* involved disc IO, as far as I can tell. [06:21] RAOF: I didn't look at that really hard, I was used to disc IO issue at unity times, but that was another machinie [06:21] machine* [06:22] ``` [06:22] Apr 05 17:21:32 Behemoth gnome-shell[2390]: Couldn’t parse steam.desktop as a desktop file, will treat it as a regular file. [06:22] Apr 05 17:21:33 Behemoth gnome-shell[2390]: Couldn’t parse examples.desktop as a desktop file, will treat it as a regular file. [06:22] ``` [06:22] That's rather interesting, though. [06:22] I get those two lines each time I hit enter in the terminal. [06:22] terminal, like alt+F2? or gnome-terminal? [06:23] Or, rather, each time I cause a zsh prompt to be displayed. [06:23] (nothing here, all my desktop files should be correct) [06:23] waow [06:23] don't know why it makes the shell reloading the desktop files [06:23] So, for some reason, displaying a zsh prompt triggers gnome-shell to try and reparse a bunch of desktop files? [06:23] I guess you have those 2 in your favorite-apps gsettings key? ^ [06:23] I shouldn't? [06:24] just to know if it tries to parse the content of favorites-apps or all desktop files [06:24] (examples.desktop is weird, I don't think we ever supported it in the shell) [06:24] but I may be wrong [06:26] RAOF: so, if your steam.desktop is the upstream one, I just added it to favorites-apps and have bash displaying the login prompt multiples times [06:26] no spam for me in the journal [06:26] In case you guys have different bugs I will focus on RAOF's descriptions for now [06:27] Yeah, it's only in zsh. [06:27] Only in zsh. [06:27] RAOF: do you have the slowness only when you press enter in zsh? [06:27] like, it never happened when you started an app from the launcher? [06:28] (that was my main use-case, start an app, everything frozen but a duplicated cursor that I can move for 5 s) [06:30] I do not see the problem when launching an app from the launcher. [06:30] argh, so maybe different issues… [06:31] I *do* recall having the pauses trigger from ways other than having a zsh prompt displayed (not just , but returning from a nvim session, ctrl-C, starting a terminal) but the pause-on-zsh is just *so* obvious and easy to trigger it rather overwhelms everything else. [06:31] good morning desktoppers [06:31] and happy Friday! [06:31] RAOF: I have this happening mostly on cold session boot [06:31] like the first apps I'm launching [06:31] then, it's at $RANDOM time [06:31] happy Friday oSoMoN [06:35] salut didrocks [06:36] Morning oSoMoN [06:37] RAOF: I can only think of title bar text that the text shell can affect in the graphical shell [06:38] afk for a bit [06:38] Removing examples.desktop and steam.desktop (from ~, which for some reason gnome-shell is scanning for desktop files?!) does not eliminate the pauses (but does eliminate the journal entries, funnily enough ☺) [06:41] hey duflu === pstolowski|afk is now known as pstolowski [07:08] RAOF: Is the bug still Nvidia-specific? [07:08] Can you tell? [07:10] Yes [07:11] duflu: I guess it might just be specific to my NVIDIA machine. [07:11] Yeah [07:12] RAOF: Also what driver version are you on now? [07:12] I could try turning on hybrid in the BIOS and seeing if it also happens with Intel if I can get it to use the Intel card. [07:13] 418. It doesn't help ☹️ [07:13] I think mutter likes that... providing the LCD is connected to Intel [07:13] 418 [07:14] Heh. Gitlab is dead. I can definitely ignore upstream issues now [07:16] The LCD is connected to the Intel in hybrid mode. [07:16] The trick is getting things to use mesa 😀 [07:21] RAOF: Do you have a custom prompt at all? [07:21] Yes, but I've tried it without and it still triggers. [07:22] * RAOF is still unclear how the zsh prompt can hang gnome-shell [07:22] RAOF: You're sure it happens with gnome-terminal too? Not just qterminal? [07:24] Yes. I usuallyuse gnome-terminal;I just tested in qterminal to work out if it was a gnome-terminal bug. [07:26] One slight problem with testing video cards now; my desktop is too small to close if one is installed :) [07:30] RAOF: I have one remaining concern before you fade into the night -- the assumption that poor performance is related to the memory usage. Sounds plausible but I also know of other serious Nvidia performance issues that appear over time. I wonder if we can make the bug just about memory to clarify that? [07:32] Sure, feel free to split of the “gnome-shell hangs for 5s each time I got enter in a terminal” bug 😀 [07:32] RAOF: No that's the third problem you reported in the same bug :) [07:32] I was already going to split that [07:34] There being performance problems are a concern, but if we were to fix the memory usage and not fix the performance problems, I don't want that to block the bug, waiting on multiple fixes [07:34] Oh, I think that is the performance problem. [07:35] Yes, probably. But the first problem you reported was memory usage [07:35] Right [07:35] I completely agree some part of 10GB RSS would hurt the system but it might not be the only hurt [07:36] I'm working on a few serious Nvidia performance issues upstream [07:36] To be clear, I think the “general sluggishness” I reported is the “press enter and wait 5s”. [07:36] OK [07:36] So we hope that is related to the memory usage, but if not then the bug needs splitting [07:37] I am now back on Nvidia. [07:38] It's definitely started bigger [07:38] But that's nothing new [07:39] Yes. [07:42] So far my gnome-shell on Nvidia with zsh has only shrunken and 1% CPU when busy :/ [07:55] morning all, happy Friday! [07:58] Morning willcooke [08:02] RAOF: In case you're still around... it appears the desktop-icons gnome-shell extension actively monitors all desktop files. Can you tell if any are changing? [08:02] Even in metadata? [08:02] hi [08:03] Hi Laney [08:03] afternoon duflu, morning Laney [08:06] duflu: I don't know why any would be changing. Nothing I'm doing *should* be modifying desktop files. [08:06] RAOF: Possibly even the metadata of ~ ? [08:07] good morning desktopers [08:07] happy friday! [08:08] There will be frequent writes to a file in ~ [08:08] Morning seb128 [08:09] hi duflu willcooke seb128 [08:09] RAOF: How about this?; gnome-shell-extension-desktop-icons reacts to all metadata changes. That includes to your home directory. And the home directory's metadata changes every time zsh writes to ~/.zsh_history [08:09] hey RAOF duflu Laney [08:09] ups [08:10] We missed you [08:10] duflu, why is it not monitoring ~/Desktop only? bug? [08:10] :) [08:10] duflu: that's quite plausible [08:10] seb128, because ~ is visible on the desktop :) [08:10] The icon with your name on it [08:11] well that doesn't require monitor tis content though? [08:11] I guess it would easy enough to disable that extension and see if that makes a performance difference [08:11] hey seb128, willcooke, Laney [08:11] lut didrocks, bon vendredi à toi! :) [08:11] merci, toi aussi :p [08:15] seb128, we can't disable or uninstall it :( [08:15] Only turn off some icons [08:15] well you can install gnome-session and log into a GNOME vanilla session to see if it's an issue there [08:15] Also I can't reproduce the bug still, so testing is still hard [08:15] and even enable the ubuntu launcher there [08:16] It appears indeed only zsh commands trigger changes to the ~ metadata [08:17] so, sounds like my perf issue is unrelated [08:17] didrocks, yeah but please do open a bug. I might know it already [08:18] duflu: I want to confirm that I don't have it anymore without drm modeset [08:18] which sounds to be the case so far [08:18] Oh, actually I still have that OFF [08:18] * duflu enables it [08:18] I got it so often (like every 10 minutes) that not having it in ~2h is weird [08:19] ah ofc, can't open the bug with ubuntu-bug right now as I'm running the scaling factor debug mutter version which isn't the one in the archive… [08:20] didrocks, please open a new bug. Even RAOF is reporting potentially multiple different issues in that one bug [08:20] yep [08:21] good morning willcooke, seb128 [08:21] Weird. My Xorg sessions can't start with nvidia-drm.modeset=1. Only Wayland works [08:21] lut oSoMoN, happy friday! how are you? [08:21] didrocks, when did the issue start for you? [08:22] seb128, I'm good (although a bit tired, but hey, it's Friday!), you? [08:22] same! :) [08:23] seb128: hard to say, it became more and more important (like it was once a day before) [08:23] seb128: I bet with the new GNOME stack, but I would need to bisect if we can't find it anymore [08:23] duflu: yeah, this is another upstream bug [08:24] duflu: which was investigated but never resolved [08:24] you have to blacklist their blacklist [08:24] Ugh. And moving the mouse on nvidia requires 45% CPU. It's only 10% on Intel [08:24] is the picker mp going anywhere or still more discussions/arguing? [08:25] we might want to distro patch that next cycle if that doesn't land upstream [08:25] seb128, it's bug free and all discussions resolved. But no current activity [08:25] Interesting Nvidia is so much worse. I might need to profile that for new problems [08:26] Oh. No I don't need to. It's the software cursor. That's the difference. So 45% CPU is about expected [08:26] Not good, but not surprising [08:27] duflu: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1823301 [08:27] Ubuntu bug 1823301 in mutter (Ubuntu) "Shell hangs up at random times" [Undecided,New] [08:27] Yay [08:27] I'll update the bug if I get it again with drm modeset=1 [08:27] oupss [08:27] modeset=0 [08:27] I meant [08:28] Thanks [08:32] didrocks, did Trevinho email you about sponsoring his recent fixes today btw? [08:45] seb128: you meant "fix" not "fixes"? [08:45] seb128: I was wondering if that worth it, it's only rotating the screen, which is less important than the other fixes, correct? [08:45] like not having a proper scaling on boot, which he's going to work on [08:45] so I guess aiming an upload on Monday with both? [08:46] https://code.launchpad.net/~3v1n0/ubuntu/+source/mutter/+git/mutter/+merge/365502 [08:46] yeah, monday is probably fine [08:46] didrocks, unfortunately rotating the screen is the most popular duplicate reported [08:46] in the xrandr-scaling tagged bugs [08:46] duflu: 2 duplicates? [08:47] Yeah still true :) [08:47] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=xrandr-scaling [08:47] sounds less a main use case that not having the correct scaling at boot? [08:48] That's very true. Might not be statistically significant numbers yet [08:49] let's see… [08:49] I had the impression that Marco said that the fix could resolve some other problems [08:49] also unsure he's able to reproduce/going to fix the on-boot issue by monday [08:49] Yeah the number of fixes required is definitely going to be shorter than the above bug list [08:50] but we can still upload what we have on monday [08:50] seb128: do we consider releasing disco without fixing that bug? [08:50] I've no idea how many users are impacted [08:50] that some nvidia only right? [08:50] right [08:51] it would be best to fix but I wouldn't consider it as a blocker [08:51] ok, so I'll have to reinstall bionic [08:51] it get less reports that the screen rotate one :p [08:51] I thought the FFe was under the consideration that no obvious regression? [08:51] for scaling factor [08:51] sounds crazy to have to argue on that, shrugh [08:51] seems like you are strongly in favor of considering it as a blocker [08:52] I thought the "high" importance reflected it? [08:52] was anyone able to reproduce [08:52] there are not enough users of disco to get lot of report about the nvidia issue [08:52] or are the only one who saw the issue so far? [08:52] it's critical to me [08:52] seb128: at least 2 persons [08:52] the system is unusable [08:52] which is 2 less than rotating the screen, agreed :p [08:52] :) [08:52] still 50% [08:53] did you try if the screen rotate one helps? [08:53] Aha! I wonder if that explains why I can't log into Xorg sessions now I use Nvidia-DRM [08:53] I think Marco said it could impact on other problems [08:53] seb128: I didn't, Marco didn't tell this could be related [08:53] but as I have to reboot, not before EOD [08:53] I'm not sure if it is [08:53] k [08:53] let's wait for him to be online [08:53] yeah [08:54] but yeah, I think either we consider a blocker or not depends of who is impacted [08:54] if it's all nvidia users it's one for sure [08:54] but I was under the impression that Daniel and Marco couldn't reproduce [08:54] which hints it's not all nvidia [08:54] nvidia + multiple monitors maybe [08:54] we are missing data at this point [08:54] one monitor is ok [08:55] which was another test I spent time on [08:55] k [08:55] and there is an easy workaround iirc? [08:55] alt-f2 + r [08:55] or go to g-c-c [08:55] change the scaling to 200% [08:55] k [08:55] and revert [08:56] on each boot [08:56] which I guess most users won't be able to spot [08:56] Is this issue only when you enable the gsettings key, or all the time? [08:56] all the time [08:56] without the gsettings key enabled [08:56] got it [08:56] and drm-modeset makes a difference? [08:56] nope [08:56] it seems to only benefits on the hang up for me [08:56] k, weird that Marco doesn't reproduce [08:56] I guess he didn't try with 2 monitors ? [08:57] duflu, did you try nvidia on dual monitor? do you see that scaling issue? [08:57] I've no nvidia hardware so I can't test [08:57] I guess we can script to alt-f2 +r unconditionnally on user login :p [08:57] I should maybe get some at some point, testing on nvidia keeps being an issue [08:58] seb128, not there yet but I have the hardware in hand to test all today [08:58] I'll see if I can bring something back from Taipei [08:58] willcooke, thx [08:58] didrocks, but yeah, let's try to get it fixed anyway, would be best [08:59] I hope so, at least, it's not a LTS but I guess if we confirm that it's for all nvidia users with multiple monitors, it's bad [08:59] especially as the FFe was acked on the fact that there is no regression spotted [08:59] yes, as said if that's the case then yes I agree it's a rls bug [08:59] but we got few reports so far, we lack data... [09:00] I don't think comparing 2 vs 4 reporters when the dataset is so small makes one one rls bug and one not [09:00] I would say that's a lot of bug reports, given how few users to early testing, and how few of them are inclined to report problems at all [09:00] when we go to so few reports [09:00] -to +do [09:02] didrocks, well, you use the dataset to argue the rotation fix is not important enough to warrant an upload :p [09:02] no warrant an upload today [09:02] (half trolling there, but yeah I agree, that's what I said we need to confirm) [09:02] without waiting for more fixes [09:02] why* [09:03] we are also due GNOME .1 next week [09:03] which fixes a bunch of launchpad milestoned other problems [09:03] yeah, so that can be uploaded at the same time [09:03] including the touch coordinate being off on x11 [09:03] when I do an upload, I test it throughfully ;) [09:03] that's the spirit :) [09:03] I hope they do release a tarball on time though [09:03] we need it next week [09:05] seb128, probably not complete but https://bugs.launchpad.net/ubuntu/+bugs?field.tag=fixed-in-3.32.1 [09:05] nice, thanks duflu [09:09] andyrock, looks like you need to follow up on https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/423 ? [09:10] GNOME issue (Merge request) 423 in gnome-control-center "online-accounts: Don't segfault if get_all_providers_cb is called during init" [1. Crash, 6. Component: Online Accounts, Opened] [09:10] willcooke, your touch bug is now there too (hit refresh) [09:12] duflu, ha! I was in the process of adding it, and by the time I'd found it the tag was already there :) [09:25] willcooke, it was there days ago but with a typo [09:25] a day ago? [09:26] The most annoying Nvidia bug right now is with Wayland sessions the monitor goes to sleep forever [09:26] And Xorg sessions never start. I assume something is crashing [09:34] duflu, you should call it a week and go enjoy the w.e, you are not going to debug those issue today now [09:36] Actually I just found my Xorg login failure is one of the xrandr-scaling regressions [09:36] Now updating [09:36] duflu, which one? [09:37] seb128, bug 1822616 [09:37] bug 1822616 in budgie-desktop (Ubuntu) "[nvidia] gnome-shell/budgie-wm crashed with SIGABRT "assertion failed: (width > 0 && height > 0 && scale > 0)" in meta_monitor_manager_xrandr_update_screen_size" [Medium,Incomplete] https://launchpad.net/bugs/1822616 [09:37] is that fixed with the xorg patch uploaded this week? [09:37] I don't think Marco knows about it yet? [09:37] hum, please ping him about those regressions when you find them, he should know about them [09:37] Trevinho, ^ [09:39] And until a minute ago it was not verified [09:41] didrocks, k, so QA has been pinged to know if they can help confirming/verifying if those issues happen on any nvidia config with multimonitor, it should help us to asset priorities hopefully [09:41] ah, great to know! [09:43] Laney, willcooke, do you have any opinion on skipping the ppc64el/s390x webkit2gtk regression to have the current version migrating to disco proper? I doubt we are going to be able to debug on those archs before release (we could try, but it's not easy to have access and webkit is probably not going to be easy to debug) [09:43] I'm leaning toward declaring we don't support desktop/webkitgtk on those archs anyway [09:44] I don't really have opinions [09:44] is this fixed by xnox's sphinx upload in the queue? [09:44] oh, let me look, I didn't notice he had an upload [09:44] lol [09:44] yes, he basically did what I said [09:45] + * Skip sphinx-doc test on obscure arches, as there is no js-capable [09:45] + engine available at the moment to test that js in sphinx generated [09:45] + html docs is good. [09:45] :) [09:45] so no I don't think that's a good approach [09:45] that's somewhat a misleading description [09:45] but I don't insist on things, make them unsupported if you think that's best [09:45] that test worked in .91 [09:46] Laney, well, I just doubt we are going to be able to sort out webkit on those archs by ourselves (and the upstream bug report from j_bicha didn't get any comment) [09:46] so the options are basically to ship wiht .91 on our main archs [09:47] or to ignore the fact that it's buggy on s390x/ppc64el [09:48] ok, your call [09:49] I vote +1 for skipping the error and shipping the stable version, I think it's the better tradeoff if we can't fix the regression on the weird archs [09:49] (which I think we don't have the engineering resources for, or at least it's not the most important thing to work on for us at this point) [09:49] seb128, I think you're right about making a decision on not supporting desktop on those archs. I'd like to hear what xnox thinks about that statement [09:49] I don't have opinions, so fine if you think it's fine [09:49] I've no opinion on the way we skip though [09:50] I'll accept that upload [09:50] I would rather have marked the autopkgtest result to skip [09:50] so we keep a reminder there is an issue [09:50] but I will let you know decide what you prefer between the uploaded workaround and skip [09:50] Laney, thx [09:51] no problem, happy to execute [09:57] seb128, Tidier now: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=xrandr-scaling [09:58] duflu, thx [09:58] Trevinho, ^ [09:58] Those are all bugs which can be avoided by downgrading mutter [09:59] Although my bug has a strange overlay with nvidia-drm [09:59] *overlap [09:59] I need to get answers from Trevinho today [09:59] he said that the changeset would be a no-op if the option was not enabled, which it's clearly not [10:00] I'm still unclear if the fact that it's not is a bug which he's going to fix or if it was a wrong statement, and in which case if we should revisit the decision based on that or just push forward fixing the issues found [10:04] Well it pains me to leave you unhappy, but also this has been a productive afternoon [10:04] if only for triage [10:05] For the record, a _plain_ Nvidia install and Xorg login works fine with the new mutter here [10:06] new being current git? [10:06] without the scaling work from marco? [10:06] do you mean they fixed things? [10:06] seb128, no I mean current disco with scaling installed but not configured [10:09] Here's a shorter list :) https://bugs.launchpad.net/ubuntu/+source/mutter/+bugs?field.tag=xrandr-scaling [10:09] k [10:12] One fix landed. Probably only two more required [10:43] hum, pushing the mutter "rotate screen" fix to a ppa [10:43] as I can't build esaily with my nvidia binary blob due to deps [10:44] and rebooting then multiple times to answer duflu's questions… (could have pinged me rather than treating the bug and set it to incomplete) [10:45] yeah, he tends to do that :/ [10:46] didrocks, do you remember what was the outcome about the transparency-mode (or was that a Marco thing also?) [10:46] just saw bug #1823303 [10:46] bug 1823303 in gnome-shell-extension-ubuntu-dock (Ubuntu) "error in 10_ubuntu-dock.gschema.override" [Undecided,New] https://launchpad.net/bugs/1823303 [10:47] that's just cosmetic because it ignores the value, but basically we just need to drop the override? [10:47] or did we need a different value/default change? === cpaelzer__ is now known as cpaelzer [10:55] seb128: we agreed to have no transparency when the dock was fixed and a slight transparency in intellihide [10:55] but I guess Marco never did it in the end [10:55] on the key [10:55] the value doesn't exist anymore indeed, I mentioned it to him [10:56] (it should have been in the upload dropping those) [10:56] I think depending on if we want to have this ^ behavior or not, the override can still be needed (but set to something else) [10:56] thx [10:59] (I will check with him when he gets online) [10:59] Marrrrrcoooo :) [11:00] ok, rebooting with my tools to log CPU/MEM usages [11:01] let's see if I can spot something for duflu on Wayland or Xorg (as it seems I need to test both…) [11:06] testing on wayland now, brb [11:06] quit [11:12] and finally, rebooting with Marco's rotating patch to see if it fixes the scaling issue on boot for me [11:16] and the bug is still there. [11:45] didrocks, thx for testing [11:47] no pb [11:47] answered on duflu's bug as well [11:48] as the hanging bug (mine) seems to be drm enabled specific, doesn't seem to be a blocker, but as it was working fine for the past year, maybe better to tackle it early… [11:50] yeah [11:50] let's see if daniel has some ideas about that one [11:51] yeah, having the Shell eating 100% CPU alone when nothing is happening is weird… especially as it's like 20 times ~ 10 minutes in the first few minutes when you open apps/start your session [12:05] Odd. seb128,jibel next time you do a fresh install on real hardware.. can you check the sound panel. My test laptop had the balance set so only the left speaker was on?! I'm going to reinstall and see if it happens again. [12:07] yeah, live session is the same [12:17] hm. odd. [12:18] Now I cant make it do it [12:18] ignore. I will do more testing [12:22] jibel, on a different note; have you seen the live session not auto-logging-in often? [12:24] I can reproduce quite often now on the haunted laptop [12:24] willcooke, seb128, Laney - the sphinx packages does generate correct documentation, and it's js works fine. So imho this is not a regression of sphinx on ppc64el/s390x, hence sphinx shouldn't be blocking things. W.r.t. webkit2gtk -> it seems it doesn't have unittests enabled, nor does it have an autopkgtest itself. Imho - it should have those, cause it's a non-trivial package. Even if we remove webkit2gtk on ppc64le/s390x the sphinx patch will [12:24] still need to go in (cause sphinx needs to stay green across the board). As far as I understand webkit2gtk (in some future update) might come back working on s390x/ppc64el but it's a question of timing and noticing it. And it has 74 reverse dependenices on ppc64el/s390x. [12:25] willcooke, seb128, Laney - my preference is to ship a knowngly broken webkit2gtk on ppc64le/s390x cause it seems to be good enough for most packages, based on autopkgtest results. [12:25] (i guess html core/css, but not js-engine) [12:27] willcooke, yes it's an old bug [12:27] jibel, live session one? [12:27] willcooke, gnome-shell fails to start [12:27] yes [12:27] thx [12:27] hahaha, I think I know what's causing the left audio only [12:27] more testing needed [12:28]