03.07.2015 22:26, Tanu Kaskinen wrote: > On Thu, 2015-07-02 at 22:07 +0500, Alexander E. Patrakov wrote: >> 02.07.2015 20:13, Tanu Kaskinen wrote: >>> On Tue, 2015-06-30 at 22:29 +0500, Alexander E. Patrakov wrote: >>>> 30.06.2015 20:08, Tanu Kaskinen wrote: >>>>> Event: monitor gets unplugged >>>>> ----------------------------- >>>>> >>>>> When a monitor gets unplugged, module-udev-detect gets a notified, and >>>>> it should figure out that a PCM device has disappeared. It should then >>>>> call pa_alsa_card_pcm_removed(), which is a new function that needs to >>>>> be implemented. >>>> >>>> Again, the case of manually loaded module-alsa-sink is not considered. >>> >>> For simplicity, I propose that no special handling is added to >>> module-alsa-sink. If the module is loaded for a dynamic PCM that goes >>> away, that presumably will cause the IO thread to fail. The module then >>> unloads itself. >> >> Yes, that would work. OTOH, I think that the IO thread would notice the >> error before module-udev-detect gets the notification. So I am not sure >> whether any special handling of unplug events is needed in >> module-udev-detect. It would be needed if we wanted to distinguish >> between "card failed" and "card no longer exists" (like the kernel keeps >> dead /dev/sd* devices for USB flash drives that were yanked while mounted). > > If a single sink fails due to unplugged monitor, the card as whole > should not be considered "failed". Maybe you meant the mapping object > corresponding to the PCM device, not the card object? Yes. > Anyway, I think we can't just rely on the IO thread failures, because > the set of available profiles of a card has to be updated also if the > unplugged monitor isn't currently in active use. If it's not in use, > there won't be any IO thread that could report the removal event. Of course, you are right! -- Alexander E. Patrakov
