Audacity seems to not play the last 0.2 seconds

[Gale Andrews]

Setting the audio buffer to 0 doesn't solve the problem either.

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.

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?

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

[Robert J. H.]

Setting the audio buffer to 0 doesn't solve the problem either.

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.

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?

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.

[Gale Andrews]

Setting the audio buffer to 0 doesn't solve the problem either.

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.

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?

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

[steve]

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").

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?

[Gale Andrews]

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").

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

[steve]

However I could still play audio in Audacity while Goldwave was playing with an exclusive option chosen,

Weird. I wonder what they mean by "exclusive". Perhaps the behaviour is different on different versions of Windows?

Is there an obvious way to test for your question?

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?

[Gale Andrews]

However I could still play audio in Audacity while Goldwave was playing with an exclusive option chosen,

Weird. I wonder what they mean by "exclusive". Perhaps the behaviour is different on different versions of Windows?

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.

Is there an obvious way to test for your question?

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.

I do now vaguely recall some tool I have that may do that, but it would probably be quicker to install Jack for Windows.

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?

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