[pulseaudio-discuss] [RFC] Dynamically created PCM devices for HDMI/DisplayPort

[Tanu Kaskinen]

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?

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.

-- 
Tanu