Windows bug: adding a new track from file takes forever if done during playback

[feik]

Sorry if this is not the correct place, I know it's called Adding Features, but I followed the link from https://wiki.audacityteam.org/wiki/Reporting_Bugs and it leads here.

Audacity 2.4.2 (but I remeber this happening for at least a few months if not years now)
Downloaded straight from website https://www.audacityteam.org/
Windows 10 with SSD (NTFS)

Dragging a .mp3 file from windows explorer into audacity takes normally a few seconds. However, if you already have one track, start playback of it and try to add a new one from dragged .mp3 file it will take *MUCH* longer. We talking about increases in order of 40 seconds.

IIRC this doesn't happen in linux.

Perhaps even the dragging of file while playing is a bug since you are prohibited from importing in the File menu.

[steve]

Sorry if this is not the correct place, I know it's called Adding Features, but I followed the link from https://wiki.audacityteam.org/wiki/Reporting_Bugs and it leads here.

Thanks for that info. I've updated the link on the wiki as it should point to "Audacity 2.x Feedback and Reviews".
I'll move this topic to the correct place.

I can't examine the issue that you raised at this moment as I'm not on Windows right now.

[waxcylinder]

Testing on W10 wit 2.4.2 and the latest alpha test build I have for the upcoming 3.0.0

Dragging a .mp3 file from windows explorer into audacity takes normally a few seconds. However, if you already have one track, start playback of it and try to add a new one from dragged .mp3 file it will take *MUCH* longer. We talking about increases in order of 40 seconds.

I can drag in another track while Audacity is playing - and it takes the same time as when Audacity is not playing

Perhaps even the dragging of file while playing is a bug since you are prohibited from importing in the File menu.

I think you may be right - I'm pretty sure it's not intentional.

I also note that
a) you can drag in an audio file while Audacity is Recording.
b) you can use File>Recent Files while Audacity is playing or recording (but you can't use File>New)
c) You can use File>Exit while Audacity is recording or playing (and you can use the top-right "X" similarly

I'm not sure that any of these are intentional, some are certainly inconsistencies - I will consult.

Peter.

[steve]

I can drag in another track while Audacity is playing - and it takes the same time as when Audacity is not playing

Same here with my usual computer. However, I can reproduce the issue on a seriously under-powered PC with Windows 10.

@feik
What are your computer specs? In particular, the CPU and RAM?
Try opening Task Manager and check the amount of CPU, RAM and HDD usage while importing an MP3 during playback.
(Note that Audacity currently has very little multi-threading, so it mostly runs on a single CPU core, thus 25% CPU on a 4 core CPU means that one core is maxed out.)

[kozikowski]

seriously under-powered PC with Windows 10.

That would be my guess. If the machine had trouble allocating resources, it would pick "Live Performance" first and then shuffle off plain, ordinary, unimportant file transfers for later.

That's not to say changing operating systems wouldn't help. Any more efficient system would help. Your symptoms just mean the machine is right on the edge of running out of steam.

IIRC this doesn't happen in linux.

Use Linux?

Koz

[feik]

I can drag in another track while Audacity is playing - and it takes the same time as when Audacity is not playing

Same here with my usual computer. However, I can reproduce the issue on a seriously under-powered PC with Windows 10.

@feik
What are your computer specs? In particular, the CPU and RAM?
Try opening Task Manager and check the amount of CPU, RAM and HDD usage while importing an MP3 during playback.
(Note that Audacity currently has very little multi-threading, so it mostly runs on a single CPU core, thus 25% CPU on a 4 core CPU means that one core is maxed out.)

Hello, it seems your comment about single core usage was spot on. Notice on https://youtu.be/hD04jDzYArk (8MB mp3) how CPU 2 (top row, third graph) is being maxxed out.

During first import it took ~2 seconds, importing during playback took ~9 seconds. Testing again, which is not on video, with best performance mode rather than balanced profile, makes the import during playback to be consistently 5-6 seconds.

By my tests, playback itself is taking 20% of a core. I would expect the import time to grow to around 3 seconds max, so I doubt playback is starving so much my CPU slices that import time would take 3x more time than usual. Perhaps something is causing the CPU usage in imports mid-playback to be higher than necessary?

Im doing this from SSD, ignore the HDD usage. It's doing some stuff in background.

The reason for the 40sec increase I mentioned previously was an setting in my UEFI/BIOS settings that was locking my CPU to 1.6GHz that I forgot to disable after using.

For those who couldn't reproduce, I was NOT(https://www.youtube.com/watch?v=SXXzGHQvelY) able to reproduce this with a really short audio file, so you may want to try a bigger file.

Specs:
Laptop
Windows 10 Home Single Language 20H2 recently installed (less than 7 days go)
Intel Core i5-8250U (reaches 3.4 GHz with turbo)
Filesystem is 117GB NTFS partition on a SSD (WDS240G2G0B M.2 SATA III)
8GB RAM
Intel(R) UHD Graphics 620

None of the videos have audio, it's on purpose.

I have an application on my sistem called Waves MaxxAudioPro that could be part of the issue. I cannot fully disable it as it's necessary 3rd-party software otherwise I can't configure whether to use the headset microphone or the laptop built-in one.

[steve]

ignore the HDD usage. It's doing some stuff in background.

What is it doing?
Does the problem still occur when the hdd is idle?

Perhaps something is causing the CPU usage in imports mid-playback to be higher than necessary?

CPU is expected to be higher because not only is the CPU having to decode the MP3 (note that even when not playing, this peaks at 100%), but it is also having to switch tasks between playing and decoding without interrupting playback. In effect, the MP3 decoding is waiting for moments when the CPU core is free, then doing a little bit of decoding and stopping to allow the CPU to handle playback. The constant switching between tasks takes additional resources. When there's a bottleneck, there's no problem until you try to push too much through the bottleneck.

[feik]

ignore the HDD usage. It's doing some stuff in background.

What is it doing?
Does the problem still occur when the hdd is idle?

The HDD was being defragmented. Tested it again after it finished and has no activity: still 5-6 seconds avg. when importing during playback.

I also disabled all extra features from Waves MaxxAudio ("dimension" and "playback", which was pretty much a fancy equalizer), same result.

I will soon attempt to test this with Manjaro Linux on my HDD and see if same thing happens.
If same result, this being a bug in Audacity can be totally ruled out and it's simply my CPU being the bottleneck.
Otherwise, it might be Windows' scheduler being funny or something in Audacity maybe?

[steve]

I will soon attempt to test this with Manjaro Linux on my HDD and see if same thing happens.

It is likely to be less of a problem on Linux.

Although the official "system requirements" for Windows 10 and Manjaro are about the same, Windows 10 on a minimum spec PC runs like a slug, whereas Manjaro quote specs intended "to ensure that you get the most out of your Manjaro system".

[feik]

Here's how it runs on Manjaro (all packages up to date) on my HDD: https://youtu.be/pHJVYXkFqn8. Minimum increase in import time, if at all. This seems to confirm it's a problem only on Windows.

I will from now use Audacity in Manjaro, as I like there more than Windows 10 anyway and was just playing around.

Perhaps there's something in Audacity code (or one of its dependencies) when in Windows that's worth investigating about this, or not. Still, it's always good to have this suff documented in the forums for future reference if needed at least, thanks for the time invested in replying me!