So, I have essentially scanned through just about all "User configuration data" keys of csr chip. I have not found anything that affects dsp. But I did find quite a bit of something. Here it goes.
"user0" = "User configuration data 0" aka PSKEY_USR0
"word0" = the index of word (16-bit value) of data in the key.
"0400" = bitmask in hexadecimal notation. If followed by "->" means I tested that precise value.
user0: word0: == 0010 bit -> startup sound == ffff -> boot-loop, self-resets to BEDF 0400 bit set-> crash word3: startup volume word4: if >1aac -> boot loop (halfway through startup sound) data6: word0: 0001: always BT-pairing? data7: word1: change to 0011 -> no startup sound word6: crashy 2000 -> crash 1000 -> crash 0100 -> crash 0010 -> ok 0040 -> ok 00ff -> crash word9: dbd0 -> crash d000 -> crash 0b00 -> crash 00df -> crash 0080 -> ok 000f -> ok data8: word9: >8bcf -> no sound data13: word0: crashy 0070->crash fb70->crash user16: word9: 6070 -> crash 5070 -> ok logic unclear word10: similar to 9 word11: other channel than word12? word12: A060 if any of these set, boot loop with startup sound playing 4000 : boosts volume 001f : boosts volume, the more the value the more the boost user20: word0: 0003: if any bit set -> crash with deep powerdown, needs powerbutton tricks to reflash user21: see user26 user26: similar to user21 word0: crash if zero, otherwise no effect word2: if zero, next values are filled with what looks like random numbers user30: sounds table, 3 words per entry word0: event number. 4001 = startup, 4002 = shutdown word1: sound number. 0000-0009 = digits; 000a = startup, 000b = shutdown, 000c = pairing, 000d = connected, e = bump, 000f = chord, 0010 = connect+, 0011 = cancel connect+ word2: bit 0002 is enable/disable, the rest seem irrelevant user37: word0: 0x0080 - clearing this bit inhibits aux input user43: word2: changing value causes either boot loop, no sound, or nothing. Hard to understand word4: signed word, adjusts startup sound loudness (negative for less loud) (0100 is noticeable amount) user49: word0, word1 always restore themselves user51:(thanks @karl.potratz) device color 0001 = Black 0002 = Red 0003 = Blue 0004 = Turquoise 0005 = Grey 0006 = 0007 = Red Base with Blue chequer crosses 0008 = Camouflage 0009 = Blue with Orange chequer stripes 000a = Grey with Turquoise chequer triangles 000b = Turquoise with Blue concentric square pattern 000c = Black 000d = Black 000d = Black user53: change to any value -> crash (tested word0 bit 0001, word2 bit 0001) user61: (thanks @karl.potratz) Custom Device Name. 16 Chars max. (this can also be set via the JBL app) 004a 0042 004c 0020 0046 006c 0069 0070 0034 0020 0031 0032 0033 0034 0035 0036 J B L F l i p 4 1 2 3 4 5 6
Of course, this is still very far from complete. I didn't test all bit combinations for the values listed here, so the conclusion might be wrong.
I've written random values to all unknown data, while looking for clues. Dsp was never seriously affected. Even after isolating a lot of things that cause crashes, I was still observing crashes, boot loops, and overall strange behavior. At least one crash was an unlucky combination of at least two settings in different keys; hunting that stuff down is too time-consuming.
As for "DSP configuration data" - I replaced it all with random values, three times, and it had no effect whatsoever. I'm afraid, it is simply not used at all. Other possibility might be that it checks some checksum on these settings, and reverts to default if checksum is not matched. But I doubt it, it's pointless... So my chances of disabling dsp are really slim at this point.