In your example, it looks like you’re first playing almost all of the file, then the first synth stops. Then you’re not re-cuing the file, and playing starting with the data still in the buffer (near the end of the file). I believe in this case that it will only play the very tail of the file.
One thing you haven’t stated is the expected behavior. Since you’re saying that the short sound is not right, I’ll assume that you’re expecting a long sound, and this probably means that you want it to start again from the beginning. To do that, you’d have to cue the file again. (You wouldn’t have to free and re-allocate the buffer, just close it and use the cueSoundFile instance method.)
If you’re going to use DiskIn for repeated playback, or segments, buffer management takes some care.
Yes, it is.
However, in my example, EnvGen outputs the values of Env.linen precisely for the duration of the sound file and then stops the synth.
I expect that DiskIn.ar plays the sound entirely without remaining the tail of the sound file in the buffer.
I should add an extra time, for example, 0.2 seconds, to the duration of Env, to let DiskIn.ar entirely play the sound without remaining the tail of the sound file in the buffer.
My problem is that I do not understand why DiskIn.ar need more time (0.2 secs) than the length of the sound file to play the sound file entirely.
My experiences with .cueSoundFile as an instance method, i.e. re-cueing, were not so stable when I made a music file player in SuperCollider, which sequentially plays WAV and AIFF files — creating a new Buffer.cueSoundFile after closing and freeing an old Buffer.cueSoundFile was more stable than re-cueing an existing Buffer.cueSoundFile.