First things first: great tool - thank you very much!
there is an issue i recovered a few week ago and its still there (v2.1.2). The last 0.2 seconds of a sample or a selection is not played.
I’m using 2 instances, the original files are .wav but it occours on copied samples as well - can this have something to do with a windows configuration or is it related to Audacity?
Thanks!
Ben
It’s probably due to the audio being buffered (required to ensure smooth playback) and that Audacity starts and stops its audio stream on demand.
For a sound system such as ASIO or Jack in which the audio stream runs continuously, Audacity should play to the very last sample of the selection. For a sound system such as MME or DirectSound playback is likely to miss the very end of the selection because the connection is closed when Audacity reaches the end of the selection, but some of the audio data may still be in the buffers. I don’t know what the situation is with WASAPI (I don’t use Windows).
If it’s a problem, the workaround is to generate a bit of silence anywhere after the end of the track, then ensure that your selection goes a bit beyond the end of the audio that you want to play. That will ensure that all of the audio that you want to play has time to pass through the buffer before the connection to the sound system is closed.
In short, it’s not really a “bug” but a limitation of some computer sound systems. However, it could possibly be “fixed” if Audacity kept the connection open all the time (this has been suggested by one of the senior developers, but I don’t know if it will ever happen as there could be a down side to this mode of operation).
Moved to the correct Windows board.
I would guess the answer is the opposite. In my experience WASAPI has the described problem, so use MME or Windows DirectSound host instead which doesn’t.
EDIT: Reducing Audio to buffer in Audacity’s Recording Preferences lets WASAPI play to the end of the track.
But if you set that buffer too low, MME and Windows DirectSound will not play properly. I found 25 ms plays to the end on WASAPI and almost always plays OK with the other hosts.
Gale
I’ve just checked with Audacity 2.1.2 in Windows XP and the behaviour there appears to be that the connection to MME or DirectSound remains open until the buffer has been emptied (at least that appears to be the case on my test machine).
I’ve not tested with the latest Audacity alpha version - the behaviour “could” be different as Audacity (2.1.3 alpha) now uses a later version of portaudio. Portaudio is the library that handles communications between Audacity and the sound system.
The problem still exists in the alpha version (with Wasapi).
Thanks for testing Robert. I wasn’t expecting it to be any different, but nice to know.
Setting the audio buffer to 0 doesn’t solve the problem either.
The attached file isn’t not played entirely. However, Loop playback makes the second (lower) click audible.
That’s a nice workaround, at least for some situations 
Another one is to add a label a bit beyond the end of the track, then select up to the label and play (tested on Linux).
I was on Windows 10 when I tested and found lower Audio to buffer let WASAPI play the entire file.
On Windows 7 where I am now, the buffer setting makes no difference.
If that difference is repeatable it could perhaps be due to Windows 10 changes to reduce audio stack processing delay.
Gale
The audio buffer trick worked in 2.1.2, if I don’t err, i.e. prior to the portaudio upgrade.
Gale, were you able to determine how much isn’t played at a very low buffer setting?
I’m actually not willing to upgrade to Windows 10–never change a winning team
Robert
Today on Windows 7, on 2.1.2 or 2.1.3-alpha, I can hear at least some of the last 50 ms of a track with WASAPI and 20 ms or lower buffer. Yesterday I could not. I have not rebooted, only gone into computer sleep and out.
So at least on Windows 7, it seems the machine state is a variable.
It may be that Windows 10 would play to the end more relaibly under WASAPI. I can only try it over the next week or so and see.
Gale
Thanks for testing.
You know, there’s full moon today at noon…
You confirm my suspicion, I also had the feeling that it sometimes works and sometimes not.
I don’t know but it seems to me that it can’t be to hard to pad the selected audio with buffer-sized silence, before the stream is opened and sent to Portaudio/Wasapi.
The problem is already listed as part of Bug 652 – WASAPI issues.
I just tested Goldwave using WASAPI API (its other choice is DirectSound). It has no problem playing a full track at either low or high buffer setting (it calls that setting “latency”).
Gale
Does Goldwave open and close its ports each time a play / record command is started / stopped, or does it open the port once and leave it open for the duration of the session?
I don’t know. It offers choices for shared or exclusive use of the sound card and neither of those settings made a difference to ability to play the file.
However I could still play audio in Audacity while Goldwave was playing with an exclusive option chosen, so that seems confusing.
Is there an obvious way to test for your question?
Gale
Weird. I wonder what they mean by “exclusive”. Perhaps the behaviour is different on different versions of Windows?
I don’t know for Windows, I was hoping that you might . On Linux with Pulse or Jack there’s tools that show the ports opening and closing.
What about if you set the sound card to exclusive mode in the control panel? Does that work with WASAPI? Does that allow one and only one application to access the sound card at a time? Does Goldwave “hang onto” the sound card once it has accessed it, or does it release it for other applications when playback is stopped?
The Help says:
GoldWave takes exclusive control of the audio device unless you select Shared quality. If you select Shared quality, GoldWave shares the audio device with other programs, but has no control over the sampling rate, channels, or quality used. The system sets the attributes used by all programs.
It certainly means for Goldwave playback, Goldwave will request its specified bit depth and sample rate direct from the device.
In the reverse case, with sound card Exclusive Mode on but Audacity playing audio first, starting to play in Goldwave with one of its “exclusive” choices terminates Audacity playback. Audacity can’t grab the device from Goldwave though, even using WASAPI host.
I do now vaguely recall some tool I have that may do that, but it would probably be quicker to install Jack for Windows.
When I set the sound device to Exclusive Mode in Windows Sound, then when Goldwave is playing, Foobar 2000 and Audacity cannot access the device. As soon as I stop playing in Goldwave, I can play in Foobar2000 or Audacity.
So this “short playback” problem looks a bit more like an Audacity or PortAudio bug than it did.
Gale