01-17-2021, 09:17 AM
Thank you for checking, and no worries about the delay, 
The Linux kernel driver for the built-in audio codec actually takes the current state of the associated RK3399 GPIO line when deciding where to route the audio output, instead of relying on the current interrupt count. That way, the driver may change (or better said, apply) the audio output routing multiple times upon (un)plugging the headphones, but the actual audio routing should be correct each time. However, it would be the best not to have multiple audio routing (re)configurations upon a single (un)plugging event.
It's really strange that the behavior on my and your wife's PineBook Pros is pretty much the opposite, but it still shows pretty much the same hardware issues. As already explained, I always get multiple headphone detection interrupts upon unplugging the headphones (with active music playback), while you get those upon plugging the headphones in. Weird, but it clearly points into the need of reworking the entire PineBook Pro's headphones detection circuit. Also, I've been able to see up to 4-5 interrupts upon unplugging the headphones, which is weirdly much lower than the 11 interrupts you've observed upon plugging the external speakers in.
In the meantime, I've tried to isolate the source of "spontaneous" spurious headphone detection interrupts I've observed on my PineBook Pro, but to no avail, unfortunately. I've also been unable to figure out what could be causing random "clicks" emittted through built-in speakers on my PineBook Pro. Furthermore, those random "clicks" do not seem to be related in any way to the aforementioned spontaneous interrupts.
However, we've done pretty much everything from the debugging standpoint, short of modifying the actual circuitry. I'll add this issue as one of the entries in the next-revision wishlist.
The Linux kernel driver for the built-in audio codec actually takes the current state of the associated RK3399 GPIO line when deciding where to route the audio output, instead of relying on the current interrupt count. That way, the driver may change (or better said, apply) the audio output routing multiple times upon (un)plugging the headphones, but the actual audio routing should be correct each time. However, it would be the best not to have multiple audio routing (re)configurations upon a single (un)plugging event.
It's really strange that the behavior on my and your wife's PineBook Pros is pretty much the opposite, but it still shows pretty much the same hardware issues. As already explained, I always get multiple headphone detection interrupts upon unplugging the headphones (with active music playback), while you get those upon plugging the headphones in. Weird, but it clearly points into the need of reworking the entire PineBook Pro's headphones detection circuit. Also, I've been able to see up to 4-5 interrupts upon unplugging the headphones, which is weirdly much lower than the 11 interrupts you've observed upon plugging the external speakers in.
In the meantime, I've tried to isolate the source of "spontaneous" spurious headphone detection interrupts I've observed on my PineBook Pro, but to no avail, unfortunately. I've also been unable to figure out what could be causing random "clicks" emittted through built-in speakers on my PineBook Pro. Furthermore, those random "clicks" do not seem to be related in any way to the aforementioned spontaneous interrupts.
However, we've done pretty much everything from the debugging standpoint, short of modifying the actual circuitry. I'll add this issue as one of the entries in the next-revision wishlist.