ao_pipewire: add support for device selection

[t-8ch]

Open points:

• Sometimes the process() callback is not fired by Pipewire, so the playback stays frozen. Needs to be investigated.
• The proper hotplug driver-callbacks are not implemented because mpv only calls the hotplug handlers for the first AO that defines them, in this case it will be pulseaudio
• No hotplug events are fired.

[t-8ch]

The random freezes are fixed now. This PR should be ready for review and testing now.

The hotplug points require changes to the larger AO logic.

[philipl]

I have to say it seems like a pretty convoluted mechanism just enumerate fundamental metadata. There's no imperative way to get it?

Anyway, It worked in my basic testing and does what it's supposed to do.

[Dudemanguy]

The hotplug points require changes to the larger AO logic.

Just out of curiosity, what kind of changes would that be? I'm not doubting you, but pipewire code looks basically exactly like how wayland code looks so it's a bit surprising to hear that a higher level of abstraction is needed to handle hotplugging instead of it just living in ao_pipewire. I guess this has something to do with the client not being able to tell if pipewire is actually driving audio?

[t-8ch]

I have to say it seems like a pretty convoluted mechanism just enumerate fundamental metadata. There's no imperative way to get it?
@philipl All the APIs which are using the remote protocol are based on callbacks defined in event structures.

[t-8ch]

Just out of curiosity, what kind of changes would that be?

@Dudemanguy The problem is in ao_hotplug_get_device_list() in ao.c:

    for (int n = 0; audio_out_drivers[n]; n++) {
          const struct ao_driver *d = audio_out_drivers[n];
          if (d == &audio_out_null)
              break; // don't add unsafe/special entries
  
          struct ao *ao = ao_alloc(true, hp->global, hp->wakeup_cb, hp->wakeup_ctx,
                                   (char *)d->name);
          if (!ao)
              continue;
  
          if (ao->driver->hotplug_init) {
              if (!hp->ao && ao->driver->hotplug_init(ao) >= 0)
                  hp->ao = ao; // keep this one
              if (hp->ao && hp->ao->driver == d)
                  get_devices(hp->ao, list);
          } else {
              get_devices(ao, list);
          }
          if (ao != hp->ao)
              talloc_free(ao);
      }

This will make sure that only the first driver with a hotplug_init() method will have it called:

              if (!hp->ao && ao->driver->hotplug_init(ao) >= 0)
                  hp->ao = ao; // keep this one

Edit: seems to be intentional:

struct ao_hotplug {
     // A single AO instance is used to listen to hotplug events. It wouldn't
      // make much sense to allow multiple AO drivers; all sane platforms have
      // a single such audio API.
      // This is _not_ the same AO instance as used for playing audio.
      struct ao *ao;
}

[Dudemanguy]

@t-8ch: Would it be better to just wait for the pipewire developer to come up with some way for clients to detect if pipewire is driving the audio?

[t-8ch]

Yeah, we can wait with the full hotplug functionality for when the pipewire so comes before pulse. Then this PR should be in it's final state.

[philipl]

I'm fine with with merging as it is. Adding hot plug support on top is incremental, and there is value in what exists here right now,

[philipl]

@t-8ch Do you want to squash and I'll merge it, or do you want to wait for the detection work in pipewire?

[t-8ch]

@philipl I think it should be two commits. The cleanup commit is not actually related to the device list feature.