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 plugged in >>> ------------------------------ >>> >>> The first thing that happens should be that PulseAudio gets a wakeup >>> from the alsa mixer, when a new ELD control for the monitor is added. >>> This is important, because the mixer should be ready when PulseAudio >>> starts to use the new PCM device. It's up to the driver developer to do >>> this right. This wakeup can be ignored, so no code changes are needed in >>> PulseAudio to handle this. >>> >>> The second thing that happens is that udev notifies PulseAudio about a >>> new PCM device. Interfacing with udev is done in >>> src/modules/module-udev-detect.c. Currently PulseAudio only cares about >>> new and removed cards, so module-udev-detect has to be modified to also >>> keep track of what PCM devices each card has, so that new devices can be >>> noticed. >> >> I am not sure whether this "wakeup from alsa mixer first, from udev >> second" ordering is something that can be relied on. But a "ELD control >> exists when udev notifies us" requirement looks sensible. > > Do you mean a case where the mixer control and the PCM device get added > so quickly that when it comes to waking up the pulseaudio process, > pulseaudio notices the PCM device change first? I suppose that could > happen. Luckily that's not an issue. The only thing that matters is that > the mixer control is there when pulseaudio looks for it. Yes, that's what I mean. >>> pa_alsa_card should be defined in src/modules/alsa/alsa-card.[ch] and >>> included in the libalsa-util.la helper library. >>> >>> When moving the code from module-alsa-card to pa_alsa_card, some changes >>> to the sink and source error handling is needed. Currently, if something >>> fails in the IO thread of an alsa sink or source, the sink/source >>> unloads the module that owns the sink/source (see the end of >>> thread_func() in alsa-sink.c and alsa-source.c). Now the owner module of >>> alsa sinks and sources becomes module-udev-detect, and we certainly >>> don't want to unload that if a single sink or source fails. The >>> sink/source should notify the pa_alsa_card object of the failure (new >>> functions pa_alsa_card_sink_failed() and pa_alsa_card_source_failed()), >>> and pa_alsa_card should free the failed pa_alsa_sink or pa_alsa_source >>> object. >> >> The case of manually-loaded module-alsa-sink is not described here, but >> should be. > > Right. When the IO thread fails, that needs to be handled in somehow > also when using module-alsa-sink (or -source). Either pa_alsa_sink needs > to act differently depending on whether it's owned by pa_alsa_card or by > module-alsa-sink, or pa_alsa_sink should have callback that it calls on > failure (pa_alsa_card and module-alsa-card would then set that callback > and handle the failure in their own ways). I'd prefer the callback > approach, but that's not a strong preference. OK. > >>> 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). >>> pa_alsa_card_pcm_removed() should mirror pa_alsa_card_pcm_added(), just >>> undoing the things that _added() did, in reverse order. So, first it >>> should call pa_card_remove_profile(). That function doesn't exist >>> currently, so it needs to be implemented. Next >>> pa_alsa_card_pcm_removed() should free the pa_alsa_profile, >>> pa_alsa_mapping and pa_alsa_path objects corresponding to the removed >>> device. I think that's it for pa_alsa_card_pcm_removed(). >>> >>> If the profile that is being removed is active, pa_card_remove_profile() >>> should change the card profile to something else. I suppose it should >>> use the same logic as what pa_card_new() uses when choosing the default >>> profile. >>> >> >> What else is missing is the big picture of the available multi-monitor >> use cases. >> >> Currently, if one has a card with multiple HDMI outputs, one can use >> audio from one monitor at a time, using profiles. I.e. there are no >> profiles like "HDMI Digital Stereo Output + HDMI 3 Digital Surround >> Output" (with the possibility to move individual streams between >> monitors), presumably due to the combinatorial explosion. Will this >> limitation be lifted? > > Since the dynamic profiles are created only when HDMI devices are > actually plugged in, I guess that will avoid too bad combinatorial > explosion. So yeah, I suppose it could be lifted for dynamic HDMI > devices. Not a hard requirement, though. > >> Also, AFAIR, there was a discussion of a possibility to send the same >> PCM stream to two monitors. How would that work? > > I don't remember reading that discussion, was it some other thread than > the one I linked to? If one PCM device is connected to two HDMI devices, > then that sounds like the PCM device is not dynamically added on monitor > hotplug. I have the assumption that the dynamic HDMI PCM devices that > this proposal addresses are dedicated to one HDMI output only. Is the > situation actually more complex? > I can't find that discussion either :( Let's suppose this is just my bad memory. Anyway, here is an old patch series that fixed a bug that manifested itself as "the same audio sent to three monitors", so this setup is definitely achievable if desired: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028914.html -- Alexander E. Patrakov
