Spurious headphone detection interrupts

[KC9UDX]

I'm sorry for the delay; I finally had an opportunity to test this.

I don't see multiple interrupts during audio playback, nor during start nor stop, without plugging anything in.

However, I do see anywhere from 1 to 11 interrupts upon plugging in headphones (or in this case unpowered speakers today). This is of course only during audio playback. But the ISR always gets it right: I never have a situation where audio is playing out the wrong speakers. (I do have at least one Android phone which does this upon multiple rapid plug/unplug events).

So clearly the audio being the source of the interrupt logic level is defeating the debounce. But what I found odd is that I cannot get multiple interrupts upon unplugging the headphones. Only when plugging them in. Unplugging generates exactly one no matter how much I try to bugger it.

I should also add that I'm still not seeing any spurious interrupts without headphone jack activity such as you are seeing.

[dsimic]

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.

[KC9UDX]

I wish it was possible to use a simple (debounced) logical switch in the socket in stead of sharing contacts with the audio channels. I don't know if a socket with a dedicated switch like this exists.

Beyond that, I miss the good old days where software didn't get involved: just the socket did the switching. I'm not sure what we've gained with getting software involved. My best guess is that this is just that modern mentality that everything needs to be done in software. Not blaming Pine64 of course, this just seems to be the modern accepted practice.

[dsimic]

I'm no expert when it comes to the various types of the headphones socket, but, based on my earlier limited research on the subject, I can confirm that many types exist, including a strange variant (example C in the linked image) that has a pair of built-in isolated switches, intended for powering up a device upon plugging in the headphones.  Thus, selecting and sourcing a perfectly suitable, "shared-nothing" headphones socket for the PineBook Pro should be rather easy.

Quite frankly, before diving into the PineBook Pro schematics and the whole ALSA thing, I expected the PineBook Pro's heaphones socket to do the switching itself, with no additional software support.  (Despite being a Linux user for over two decades, I've never had interest to research the way Linux sound subsystem actually works.)  Now, I can confidently say that ALSA is well architected, and that having the headphones socket doing the actual switching would be against the general level of post-2000 audio hardware and against the support for the advanced audio features made available by ALSA.

Things inevitably change, and the improvements should be embraced while remembering the origins.  However, improvements are sometimes not actually improvements, but luckily, audio hardware actually got better over time.

[KC9UDX]

Using an isolated switch, but letting the socket do the audio route switching would then be ideal, I guess. The isolated switch could tell the software which output is active, but not rely on the software to do the routing.

Diagram C would not work for the PBP as designed, because it does not accept a microphone input. I would not eliminate that (even though I don't currently use it).

I still wish I had time to add a dedicated socket for the serial terminal.

[dsimic]

The variant C in the linked picture was just an example, it surely cannot be used in the PineBook Pro.

[KC9UDX]

I guess I shouldn't even comment: I forget that I don't really know what's available these days. Things have changed a lot.

[dsimic]

The basic principles are still the same, but the things have changed a lot indeed.  It's a good thing, IMHO.

I still wish I had time to add a dedicated socket for the serial terminal.

As a delayed response, having a separate socket for the serial console would also eliminate the need for the built-in analog switch, which should also remove the presumed DC bias on the audio output(s).  That would be a clear win-win-win situation.

[xyzzy]

Is there DC bias in the audio output? Should be easy enough to measure.

I don't think there needs to be anything wrong with the circuit. It could be the pin for the RC3399 GPIO is configured with an internal pullup. It would be in the pinmux section in the dts. In this case, when the headphones are inserted, the HP_DET_H line is disconnected from HPO_L and isn't driven by anything other than the internal pullup. The only connection appears to be a 100 nF cap on the small board. So the level rises to a logic 1. The cap would help to debounce that.

When the headphones are removed, it will be driven to the level of HPO_L. And that should be low enough to be detected as a logic 0.

Since there isn't really a debounce circuit, there's might be multiple interrupts triggered per insert/removal. But that doesn't really matter. Just debounce in software by ignoring interrupts for a bit after the first one.

I suppose a continuous high level on HPO_L could be enough to trigger the circuit.

And yes, if they had just added a rs232-usb chip we could have a serial console, and headphones, and no analog switch, and no need to open the pbp to enable the console, and no special console cable that's over the voltage limit.

[dsimic]

My apologies for the delayed response.

Actually, I've been thinking about using an oscilloscope to have a look at the audio output signal, which should clearly show if there's DC bias, but I haven't managed to do that (yet).  Maybe I'll get around to that one day, but your explanation shows that checking that actually shouldn't be needed.  Thank you very much for pointing out the pull-up configuration, and I'll reiterate below, with further insights.

Indeed, according to the DTS file for PineBook Pro, an internal pull-up resistor is configured on the GPIO line that's used for the headphones detection.  Also, the audio codec configuration uses the logical high level of the GPIO line to indicate the presence of headphones, which additionally confirms the use of the pull-up configuration.

Software support for the debouncing of GPIO lines already exists, and it is already in use for the headphones detection.  It might be worth playing with the debouncing configuration, but the actual "debounce_time" value is hardcoded to 150 in the Linux kernel driver, which means that improvements to the driver source code would be required to make the value configurable in the DTS file.  Doable, if helpful, but not exactly a one-liner.

The pull-up configuration clearly covers the case when the headphones are plugged in, in which case the HP_DET_H GPIO line isn't connected to anything but the 100 nF capacitor on the daughterboard, which is connected to the ground, but that makes no difference in this case.  For the plugged-in headphones, there's a clear logical high level.  However, the issue of debouncing remains, as already decribed above,

With no headphones connected, the HP_DET_H GPIO line gets connected to the HPO_L audio output, in addition to the above-mentioned connection to the ground through the 100 nF capacitor.  In this case, the capacitor might "smooth out" a bit what gets to the GPIO line, but may also adversely affect the audio quality of the left channel.  However, the GPIO line gets pretty much the same "junk" (from the standpoint of the logic level) that goes to the left audio channel.

However, the "junk" coming from the HPO_L audio output should be low enough, more precisely below 0.8 V, to cause a logical low level on the GPIO line when there are no headphones plugged in.  Which it actually does, but the issue of spurious interrupts remains.  As described in the original post, I see spurious headphones detection interrupts generated with no headphones plugged in, and with no actual insertion or removal of the headphones.  No amount of debouncing can help there, and it clearly shows that the audio "junk" or something else present on the audio channel isn't stable or clear enough to be fed to the GPIO line,

I know, in the end it kinda works most of the time, but why compromising on something that could be rectified by a slightly different headhones socket?  I highly doubt that using a different socket would add more than $0.10 to the BOM, which would be negligible.

By the way, why would we want a built-in RS232-to-USB bridge chip to use it as the console serial port?  It's much better to use the RK3399's already existing native serial port as the system console, as it doesn't mandate the initialization of the USB subsystem for the console to become operational, requires no additional active components on the PCB, doesn't waste what's already existing, etc.  Quite frankly, the best option would be to have the native serial port made available through an additional jack, instead of having it sharing the headphones jack.