Following up on a discussion we started on #pulseaudio. The specific use case is a user has a bluetooth device in addition to an internal sound card. They start playing a stream, manually move the stream to the BT device, then suspend. On resume the stream is playing on the internal card instead of the BT device. The reason appears to be that the connection to the BT device is not restored on resume so module-rescue-streams moves the stream.
I can duplicate this non restored connection with a BT headphone but a different BT headset does automatically reconnect at resume (and the stream is then properly moved back to the device). I'm having a hard time tracking down in what layer of the linux stack the reconnect logic resides. Independent of pulseaudio what layer determines if a reconnect should be attempted and why the different behavior even with two somewhat similar types of BT devices. Then depending on the answer to the first question, should pulseaudio attempt to trigger some manual reconnect to BT devices it was streaming to when suspended. I guess the bluetooth module could use the Sleeping/Resuming signals on the org.freedesktop.UPower D-Bus interface. Thoughts? _______________________________________________ pulseaudio-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
