mirror of
https://github.com/yusufipk/dikte.git
synced 2026-09-11 10:56:10 +00:00
yusufipek
8c62795b8b
Three things about the dshow backend, all of them found by reading rather than by running, so all three want checking on a real Windows machine. The device listing is parsed in both of the shapes ffmpeg has printed it in: newer builds mark every device `(audio)` or `(video)`, older ones print a heading and no marks, and only the first was read. Each pattern is anchored at both ends now, so the error lines the command ends with, which quote the device name it was told to look for, are no longer read as a device of that name. What is stored for a device is the alternative name under it rather than the friendly one. A laptop with a headset plugged in has two microphones called the same thing, and `audio=Microphone` reaches the first of them whichever one was picked; the alternative name is unique. The friendly name stays what is shown, which is what the (id, description) pair in these lists has always been for. An unset microphone meant "the first one listed", and the listing costs an ffmpeg of its own, so every press of the key paid for a process before the recording started. The last listing is remembered instead, and opening Settings or running `dikte devices` takes a fresh one. And a fourth thing, which is about what the interface says rather than what it does: whether the far side of a meeting can be captured at all is now an entry in `audio.Sound` instead of being read off an empty device list. The two are not the same answer. An empty list on Linux means pactl is not installed, which a user can go and fix; False on Windows means there is no such device and no driver that would add one. The Meeting tab says so under the empty box, and starting a meeting says it instead of sending somebody to Settings to pick from a list that will never have anything in it.