I came up with a simple metric for detecting DSP and CPU blocking conditions / performance holdups at the HOST port from the profiler data exported from the Hatari debugger.
1) If a disassembled instruction contains "jclr #0,$ffe9" or "jclr #1,$ffe9" the DSP is waiting to receive or transmit respectively. So only these addresses are interesting for detecting this kind of problem.
2) The instruction needs to refer to it's own address e.g. "p:0041 0aa980 000041" to indicate a blocking loop (in most instances this will be the case anyway - other rarer cases probably not worth the trouble, i.e. just ignore them).
3) For all of these transmit/receive addresses, if the profile count value is less than some small multiple (e.g. 2x) of the next instruction's count value, it means the blocking loop was very short - most likely passing straight through on occasion. In the worst case, the counts will be equal, which means the DSP never waits and is probably behind the CPU - the CPU is always waiting. This identifies a DSP-side holdup.
4) For the same addresses, if the count value is greater than some larger multiple (e.g. 8x) of the next instruction's count value, it indicates the DSP is always waiting, and therefore identifies a CPU-side holdup.
5) The values (multiples) in-between aren't so interesting because there should always be some margin between CPU and DSP, but ideally a small margin - this indicates both processors are occupied most of the time. The multiples I have chosen are arbitrary thresholds, maybe not ideal ones - but it has worked ok for me.
D.