01-08-2021, 07:42 AM
It could be easily that the PineBook Pro schematic we have available actually isn't the latest revision. For example, the schematic available for RockPro64 is obviously outdated, so it could be the same for the PineBook Pro.
Could it be that the headphones detection works because the RK3399's GPIO line is tolerable when it receives all kinds of weirdness, instead of a clear logic level? The audio signal shorted from HPO_L to HP_DET_H should be somewhat filtered by the C9 on the daughterboard (but that would also negatively affect the left audio channel), which might help in removing some of the weirdness that the RK3399's GPIO line receives? But, how would all that "work" when there's no audio playback at all?
Furthermore, the above-presented excuse for the bad design might be confirmed by experiencing more than a single interrupt generated upon unplugging the headphones... During the disconnection/unplugging, the left channel signal no longer has the path through the left earpiece or the left built-in speaker, so all of it tries to go through the RK3399's GPIO line, and the bumps on the headphone plug recreate or reinforce that scenario a few times during the disconnection of headphones.
However, I'd agree that my above-presented sorry excuse for the bad design is rather absurd and highly debatable. Though, here's something that might actually support it: if there's no music playback, I see only one headphones detection interrupt upon the unplugging of the headphones. If there is music playback, the unplugging always generates a few interrupts. I've checked it and confirmed a few times. Even if it doesn't support the sorry excuse, this behavior is really strange.
Could it be that the headphones detection works because the RK3399's GPIO line is tolerable when it receives all kinds of weirdness, instead of a clear logic level? The audio signal shorted from HPO_L to HP_DET_H should be somewhat filtered by the C9 on the daughterboard (but that would also negatively affect the left audio channel), which might help in removing some of the weirdness that the RK3399's GPIO line receives? But, how would all that "work" when there's no audio playback at all?
Furthermore, the above-presented excuse for the bad design might be confirmed by experiencing more than a single interrupt generated upon unplugging the headphones... During the disconnection/unplugging, the left channel signal no longer has the path through the left earpiece or the left built-in speaker, so all of it tries to go through the RK3399's GPIO line, and the bumps on the headphone plug recreate or reinforce that scenario a few times during the disconnection of headphones.
However, I'd agree that my above-presented sorry excuse for the bad design is rather absurd and highly debatable. Though, here's something that might actually support it: if there's no music playback, I see only one headphones detection interrupt upon the unplugging of the headphones. If there is music playback, the unplugging always generates a few interrupts. I've checked it and confirmed a few times. Even if it doesn't support the sorry excuse, this behavior is really strange.