Open NexAdn opened 1 year ago
Regarding the display issues: I was just able to fix that by using a different audio interface. But I guess that's is unrelated to the original issue that this PR fixes.
Any updates on this?
@NexAdn Thanks for the PR. Sorry was very loaded the last time. This issue requires a more detailed investigation and the solution also.
Well, from what the name suggests, m_deviceListMutex
is responsible for handling access to m_devices
,
so passing the mutex on to the AlsaPCMDevice is not a good idea in the first place.
Otherwise, I'd consider this variable poorly named as it seems to cover things beyond its name, while the name is pretty specific in that the mutex is there to serialize access to the device list, not the devices.
Another thing to consider is that keeping a mutex for longer than it's actually needed (which normally boils down to accessing a shared resource) is almost always a bad idea as it leads to problems like this.
I've now been using this fix for quite a while without any problems. The semantics of your code seem work out perfectly fine to ensure your devices aren't deleted before they are finished doing their things. Thus, I don't think there is any reason to keep any locks for a long time.
If you think that my understanding of your locking mechanism here is wrong, please let me know. Then I can have a fresh look at it, if you lack the time or resources to do so.
This PR doesn't solve the issue, I'll need more time to investigate the real reason for this deadlock and apply changes to this PR or I'll make a new fix for this issue. AudioPlugin tells the application what devices are now available, that's why it requires this mutex.
To mitigate deadlock issues on switching the audio input device, this commit reduces the time
m_deviceListMutex
is locked by switchingstd::lock_guard
and manual locking forstd::unique_lock
and deferring locking only to places where access to the device list is needed.Important note: During testing I sometimes had issues where the RTA and sidebar level meter didn't work correctly with some input configurations (especially the time window and input source settings). But since I am unfamiliar with the codebase, I can't tell if this issue is related.
Closes: https://github.com/psmokotnin/osm/issues/56