We could always buy some different adapters to try if anyone thinks that would help.
Hi Connor & Mark,
We tested the build you sent, and as you expected it does output “transportType: ‘hdmi’” it also appropriately outputs ‘bltn’ when I switch. FYI it displays the message twice every switching instance after the initial start-up.
Great, thanks!
We could always buy some different adapters to try if anyone thinks that would help.
I guess it’s possible that the adapter is the issue, but I also see no reason to think so.
On the other hand, I’ve always found HDMI on Mac’s to be fussy and annoying. For example, on my one test machine that has a display connected via HDMI, every time I wake the displays from sleep, the HDMI display turns on, goes blank after a second or two, and then turns back on, as if it’s reconfiguring itself or something. I think I had a similar problem with my old 2013 Mac Pro, and it was annoying enough that I abandoned HDMI and switched to the display’s DVI output (via a DVI-to-DisplayPort adapter). I’ve never had a display that could output audio via HDMI, but I wouldn’t be surprised if that were flaky, too.
In any case, now that we’ve confirmed that the OS does indeed consider the audio output transport to be HDMI, we should be able to eliminate the problem by not running the start-up latency reduction code for HDMI devices. I will try to get that change in to the nightly build soon.
Thanks,
Chris
Thanks Chris and everyone!!
Hi Nina & Connor,
The change that will (hopefully) fix HDMI audio output is now in the MWorks nightly build. When you have a chance, please try it out and see if it resolves your audio issues.
Note that, when using an HDMI audio output device, you’ll now see the following warnings in the MWorks console:
Audio I/O buffer duration configuration is disabled for HDMI audio output devices
Cannot set audio I/O buffer duration; sounds may start later than requested
You can ignore these, as they’re just telling you that MWorks is handling HDMI audio as intended.
On the assumption that this build will fix your problem, I’ve created a persistent copy of it. Even though the MWorks version number on it is 0.14.dev, it’s really just MWorks 0.13, plus the audio fixes resulting from this discussion and the (unrelated) read_inputs_while_stopped parameter on LabJack LJM devices. Hence, this should be a good build to deploy in your lab (again, assuming that the audio issues are really fixed).
Thanks,
Chris
Hi Chris!
I tested the most recent nightly build using FindTheCircle and it seems the audio is back to normal. We still need to push the new version out to all of our rigs, but I am tentatively assuming all is working as it should! Thank you for your help with this!
Best,
Connor
Great! Thanks for letting me know.
Chris