To be more precise, GGX isn't actually crashing the driver but instead is keying on looped samples with LSA > LEA and this is being mishandled.

Code
StartSlot[0E]:   SSCTL 0 SA 04EFEA LSA FFEC LEA 0008 PCMS 2 LPCTL 1
                 AR 1F D1R 00 D2R 00 RR 1F DL 00 KRS 0 LPSLNK 0
                 TL 0C OCT 0 FNS 000
                 LFORE 0 LFOF 00 ALFOWS 0 ALFOS 0 PLFOWS 0 PLFOS 0
                 IMXL 0 ISEL 0 DISDL C DIPAN 17

I'm not exactly what the hardware does in this case, but it would make the most sense if LEA is only processed after LSA is reached, and for this to work, the sample counter needs to rollover upon reaching 0x10000.

AOSDK isn't applying this rollover, and in this particular case, havoc ensues with the steps_to_go part of the ADPCM decoder as this value gets very large and contiunes to increase, unbounded. The result of this is the sound processing spends most of it's time chasing this everly increasing steps_to_go value and is unable to update the sound buffer at the required 44.1 kHz. And so, the end user then hears something along the likes of a broken record.