Draft: vlc_aout: add vlc_audio_output_callbacks for device hotplug support in player
The callbacks are similar to those from vlc_audio_output_events
but
are meant to forward to the interfaces/player instead of the audio
output owner. They could be unified in later refactors.
The Qt interface doesn't implement the callback correctly yet, I'm waiting for approval on the way I plan to refactor the audio output events vlc_variable
into the callback structure in input_resource
.
Fixes #22478
Refs #22479
Merge request reports
Activity
changed milestone to %4.0
added Component::Core: Audio output label
assigned to @alexandre-janniaux
- Resolved by Rémi Denis-Courmont
Is the idea that a device may be present but unplugged? What's the boolean flag for?
The Qt interface doesn't implement the callback correctly yet, I'm waiting for approval on the way I plan to refactor the audio output events
vlc_variable
into the callback structure ininput_resource
.Is this designed to remain a core-only API or you envision it would eventually make its way into LibVLC? Just curious, one libvlc user just inquired about this feature.
Hi, I haven't thought about it yet. But the same issue solved here exists with https://videolan.videolan.me/vlc/group__libvlc__audio.html#ga5d13bb70351f6fa597d8f1b553da81d5 and it could be added as a new event in libvlc_event https://videolan.videolan.me/vlc/group__libvlc__event.html#ga284c010ecde8abca7d3f262392f62fc6 but it's probably a bit trickier than that: Qt uses
vlc_player
and thus can lock the player to gather the list of devices and then use the callbacks (or probably better, only use callbacks). LibVLC cannot lock the player and using both the getter and the event might lead to races if not properly designed/documented.Except this issue, once the callback is there, it's pretty easy to route it towards libvlc.
136 136 int (*gain_request)(audio_output_t *, float); 137 137 }; 138 138 139 struct vlc_audio_output_callbacks { This is a owner-like callback structure, much like
vout_window_callbacks
, except that the audio output codes adds an intermediate layer between the owner of the audio output and its implementation (I'd call that private core part). In the end, factoring the private code part out of the audio output to match vout_window could be a possibility but it means that we typically loose the device cache.It's provided through the input resource, because though the input resource will store it, it's not the client of the audio output but would still create the audio output.