I'm using AudioKit (4.11.2) in my app to replay audio files.
When try to start a player after connecting/disconnecting audio hardware, there is often a deadlock in main thread. The same also happens when loading or unloading a player after connecting/disconnecting audio hardware.
Especially, when the connected/disconnected device is an Apple AirPod Pro headset, then it's reproducible by 100%.
See image with call stack on deadlock.
Image with call stack of deadlocks
I know that AudioKit 4.11.2 is not the latest, but it is the latest 4.x release. I cannot yet switch to 5.x due to the breaking change of missing AKPlayer class.
Is there any known issue with deadlocks after connecting/disconnecting audio hardware?
I already switched off AKSettings.enableCategoryChangeHandling and AKSettings.enableRouteChangeHandling, but that didn't help.
P.S:
In the mean time I migrated to AudioKit 5.3.2 and use the class AudioPlayer instead of AKPlayer and the issue is still the same.
After many hours and hours of debugging I found that it must be an Apple bug.
Reading lastRenderTime (AKManager.engine.outputNode.lastRenderTime on AudioKit 4 or avEngine.outputNode.lastRenderTime on an instance of AudioEngine on AudioKit 5) causes the problem.
As long as I never read lastRenderTime, I can connect/disconnect the AirPod Pro headset and play the audio file without any problems.
Once I read lastRenderTime, after next connect/disconnect of the AirPod Pro headset the main thread freezes when trying to start the player.
(lastRenderTime on AVAudioNode is an Apple function, not an AudioKit function.)
Related
If you've got the Qt 5.12.8 (the version that ships with Ubuntu 20.04) examples installed + built, start playing a video with it, switch virtual desktops and the video stops (you can't hear it). Come back, and the widget is white, in some sense it forgot the video. The example's 'brother', multimediawidgets/videowidget, works as you'd expect: start playing a video, go to another virtual desktop, you can hear it still playing, come back, and it's carried on as you'd expect. Interestingly, if you first pause the video in the videographicsitem example, do the switch-and-back, the video correctly still shows and is resumable when you come back, so, it's just if you switch while playing. I presume it's a bug - can anyone think of a workaround? Thanks.
edit: This is the same for Qt 5.15.2, the latest Qt 5.x as I write. As for Qt 6.2.x (latest as I write), it didn't have that example - I've read that totally new versions of Qt take a while to get the multimedia stuff.
I have a usb driver with multiple IOKitPersonalities each with a IOMediaIcon entry. all works fine if the usb devices are plugged in after the kext has been loaded (kext loads fine, is signed, etc.). but after reboot of the computer, only ONE of the usb devices shows the standard orange default usb image. if I unplug/reload kext/replug the usb device in, the image gets corrected.
Any thoughts?
(Details:
running Mac OS X 10.10.1 (I don't think I saw this problem before Yosemite, definitely not a problem on 10.6.8), all the Personalities are the same (except for the IDs (which are correct I think since the usb device loads correctly if I plug in after the kext is loaded) so it isn't mistake with the personality...)
I don't know how to fix your specific problem, but I can give you some pointers which may or may not be helpful (sorry, a bit too big for a comment, but not a proper answer):
The icon stuff is handled in user space, the only thing that the kernel should have to do in theory is set the IOMediaIcon before registering the service. Setting it in the personality should be fine.
In user space, Disk Arbitration takes over. You can download (most of?) the source code for it from Apple's Open Source Site.
A quick search reveals that the diskarbitrationd source code does indeed reference the IOMediaIcon, in DADisk.c
I don't know how well it works to recompile diskarbitrationd and substitute Apple's binary with your own, but if that works, maybe you can modify it to log output from the icon code, and get closer to your answer that way?
The other source of error I can possibly think of is that although the system gets the correct icon information, it can't actually find the icon file? I've heard about various bugs related to bundles and resources in the context of /System/Library/Extensions vs /Library/Extensions since they added the latter. If your icons are in your kext bundle, and you've switched to /Library/Extensions, try switching back to SLE.
I hope that helps your debugging efforts!
this is a more unusual question so give me a hint when stack overflow isn't the right place for it. ;)
I have a problem with Visualstion 2012 where it freezes every so often when I compile my project.
I am currently working on a Qt project so the Qt add-in is installed. I am sure you can't remote-fix my problem but I would like to ask what could cause such freezes.
Here are some important infos:
the PC doens't freeze every time I compile (seems to be a bit random)
the freeze takes from 5 to 15 minutes. In most cases, it ends with the screen switching to black and then back to "normal"
I often try to open the task manager which returns an exit code after the freeze which says that the task manager couldn't start
the PC comes back to life after 5-15 minutes but many applications (incl VS) aren't responding for additional ~5 minutes.
the hardware components are fine for what I can tell. (I tested HDD and RAM, temps are fine)
I hope you can give me a hint where the cause of the freezes could be hiding. ;)
You could start by analyzing what is unique about your system.
Perhaps you are using an unusual source control system, anti-virus, network connections, mapped drives or some weird form of integration that nobody else uses. My guess is that this may be your source control integration or some server connection that is triggering an unusual locking condition.
I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
The idea is download a video in parts (from different servers) but starting to play before video file is complete.
The issue is that VideoDisplay component doesn't read the video file if it is opened for writing and vice-versa: writing is impossible if VideoDisplay plays the video...
I know I may sound totally off-topic, but you should make sure you've properly considered video streaming thru Flash Media Server, Wowza or Red5 before you put that much effort in downloading a file in chunks. Just a thought..
What about having multiple parts of the video, so playing can begin as soon as first part gets downloaded. So the parts have to be concatenated somehow at client side.
(Additionally, if one's connection is insufficient, showing a loading symbol is fine.)
Open the file in Shared mode, if that is possible with Air. Mainstream OS's (Windows, Linux, MacOS) have this functionality built in.
Use two threads:
In thread 1 (the downloader thread) open the file in Shared mode to allow reading from other threads and processes.
In thread 2 (the player thread) open the file in Shared mode to allow reading and writing from other threads and processes.
Be sure to buffer the beginning of the file so your player will always have something to play and won't choke while playing an incomplete file.