Careful reading and understanding of the DSP programming guide...

We can't sample an input and play a different input at the same time. However the sinewave generator (tone generator in DSP speak, but I'm trying to avoid confusion with the tone (bass/treble) controls..) can be used in any input mode. It can be used in one of two internal modes.
One of those generates the sine at the input stage and effectively overwrites the current input. These sines are processed by the audio block (EQ, bass/treble, loudness, SAM, main volume) before output. This is the mode I would have liked to use, since we want to be able to test the EQ. The currently-released kernels in this thread use this mode.
However, the QPD description in the manual is a little ambiguous. It states that we can take peak measurements of the current input, but doesn't state which that is when the tone generator is active (ie raw input or the overwritten sine). Unfortunately, after having entered all the definitions and code needed to support the QPD in the kernel, I discovered that my suspicions were correct - it will take peak measurements of the sine wave when generated, and not of the current input.

The other mode for the generator is superposition mode, where the sine is superimposed at the output, after the EQ, bass/treble, loudness and volume processing. This is the mode that the current player beep code uses, and hence why the music doesn't stop when the player beeps.
At first glance this isn't useful to us. We ideally want the sinewaves to be processed by the EQ so that we can qualify our EQ corrections. And we also don't want the player music to mix with our sines. Sure, we could expect users to either pause or Quit the player when doing this, but that's not very user-friendly. Plus, for measurement purposes, we *want* an input (Mic input over Aux In), Can you say positive feedback?!
Then I realised that when the sinewave is used in superposition mode, it is added after the SAM (soft audio mute) block. That means by muting the player, we're still left with the sine wave. It makes the coding a bit more difficult, but works.

In case you hadn't noticed before, there are 2 peak detectors that can be individually set to monitor 2 different points in the processing chain. So we can measure the raw 'car audio dynamics' response to a known sinewave at one point, and by measuring the response after the EQ block we should be able to tell whether we're correcting for it.

See the diagram below.

<img src=&quot;http://empeg.comms.net/files/146948-empsine.png&quot;>

In the frequency domain;
C(f) = Car response
S(f) = signal.
EQ(f) = EQ response.

In normal use we hear C(f).EQ(f).S(f)
To hear S(f), we want C(f).EQ(f) = 1, so we are trying to get EQ(f)=1/C(f).
Actually, the value 1 isn't important. Since we like to change volumes, what is important is that it is a constant, and not dependant on f. So we want C(f).EQ(f)=K, or EQ(f)=K/C(f)

You can see that in non-superposition mode, we can only only measure S(f) and EQ(f).S(f). We have no way of measuring C(f)

But in superposition mode with SAM set, we are measuring C(f).S(f) at the input, and EQ(f).C(f).S(f) at the output of the EQ block.
The first measurement is of use to us - since we know S(f), it tells us about C(f). We could calculate EQ(f)=1/C(f) from this though. But the second value EQ(f).C(f).S(f) is also eminently useful. In the sinewave mode, S(f) is a constant. Therefore we're really measuring EQ(f).C(f). Do you remember that I said we wanted EQ(f).C(f) to be a constant?

We can not only calculate EQ(f) from the first measurement, we can test it from the second. As long as the second value is constant across the frequency range, the EQ is correct.