To start off
I was always assuming that the information given in the manual to the GUS was incorrect; "playfile is for recording and playback only restricted by the space on your harddisk".
However DOSBox (vanilla 0.74 and ECE) play only about 128kB and then the player stops, sometimes it even crashes DOSBox when it reaches the 128kB (rarely).

I really gave it up already and thought it is an issue of the software, nonetheless today i gave it a try in DOSBox-X and to my own surprise here playfile works as expected (just perfect).

Instead to write a lot i've made two short clips playing back a driping tap sound (30 sec, 1'0015 kB ) and a calibration signal (500Hz 5 sec about 108kB, turn the volume down if you don't like to get deaf) which is in the range to be played back - or should be it depends on samplerate not on time, both files have a samplerate of 22kHz and a bitdepth of 8 (unsigned).

I missed (or tossed) the clips i made with DOSBox ECE but it acts exactly like vanilla DOSBox and can't play back more as 128kB on the GUS.
It is a matter of size and not playtime, a 11kHz sample will play double compared to my 8bit 22kHz demo samples and a 44kHz sample half, if it's 16 44kHz bit you get down to 1.25 seconds roundabout, if it would be stereo 16bit, 44kHz lousy 0.6 seconds.

EXCEPT if i use GUSTEST, but this program loads the complete sample to the DRAM thus it's no surprise it can playback the whole file (dunno yet what happens if the file is above 1MB).

The thing of interest is DOSBox-X, it plays back on the GUS perfect, the calibration signal loops perfect very unlike to vanilla DOSBox which loops "randomly" start, end, mid section but never the whole file. Sometimes the signal is even heavy distorted, a few samples hang of a previous played file still lurk around in the DRAM and will sometimes appear if you loop a file.
"Show off effect", i couldn't reproduce it when i captured the clips, but if you record (which is a stupid idea) you will record exactly this remnant.
This seems to be a common GUS issue therefore GUSTEST was written, to flush the DRAM.

Why do i care for the GUS?
It is in my humble opinion the best sample player, it works bit exact and can loop perfect as you will see, you can specify an offset and playtime in bytes which makes it perfect to playback my RAW audio samples - if there wouldn't be this issue.
I really tried dozens of players but i always return to playfile, sure some SB players are quite good, a quite recent one (1998 😀 ) SBPLAY would be a good choice
BUT well this player has an issue which makes it under certain condition unsuitable for me, it can fail together with ANSI art and will freeze DOSBox, not often you will have to give it many tries until it happens, but i have a project where i splatter some ANSI on the screen every few seconds and playback a random joined together audio track (the reason to decide for the headerless format, it gives me full control over the samples), this and similar repetitive use of ANSI art and repetitive use of a SFX lead in a longer run to this freeze - always. Not so with Playfile, this i can run a whole night and a whole day and it still runs no matter what is on the screen. This and other issues with the handcrafted SB players always let me return to GUS Playfile. If it would be fine i wouldn't use another player, it can pop sometimes and you can't get rid of that but i assume this is caused by a previous DC offset correction which is irreversible. This i noticed myself, files where i corrected the DC offset have all this popping sound when playfile ends and it neither helps if you set the boundaries (offset, playtime) exact to the first, resp. last byte containing a signal. Else playfile really is perfect you can notice this on the calibration signals loop, it's perfect (in DOSBox-X). Playfile is meant to keep track of samples you made for the gus, you can determine with it the exact offset and playtime for the sample, how you elaborate it with Playfile this it will sound as sample for the GUS wavetable synth.

I would appreciate it much if that issue could be solved for vanilla and DOSBox ECE because i don't like to use "X" it's a beast to handle.
FYI, both run with a standard configuration, no changes to the config made except "mount..." and cycles=max.

here the clips to show off better what my problem is (just a few seconds)
vanilla DOSBox:
https://youtu.be/RnFxOXdJRV8

DOSBox-X
https://youtu.be/wVq3aUvvZ1o

I hope it will help.

if you like you can use my "testcases" CALIBRTN.RAW (a 0dB 500Hz mono signal made with audacity), DRIPDROP.RAW (a driping tap), CROWD01.RAW (crowd noise from the intellivision).

(erm yes you might wonder avout the quite large footer my samples, except for the calibration signal, have (1024 bytes for 22kHz). But this i made for SBPLAY which starts and ends usually silent but if there is no silent end about a tenth of a second it will "pop" respectively cut off the SB before the file ends, or vice versa, however in such a case it can repeat the last few bytes of the signal even if the file has already ended, to avoid this i added this "large" footer. Playfile wouldn't need that as you can see you can let a file end on the byte and if looped you won't notice the loops end/start. Playfile is unerringly. Also all my samples have 64bytes of "lead in" it's rather a reserve, if i would only use playfile or another player which allows to specify offset and length i could insert a sort of header containing info which i can bypass then with the offset or a footer, i have seen both already even if this breaks the conditions for a plain resource file.).