Audacity stops recording when another process plays audio

Audacity 3 Help Forum Windows
1

Audacity 2.4.1, Win10

Hi,

I’m doing some (very amateur) testing of hand-written audio software. Basically, I’m playing a ‘control’ WAV file (pure Sin wave) from players written in different languages and recording it in Audacity (running on the same machine). The players are written in:

  • Python (using the python-sounddevice library)
  • Python (using the pyaudio library)
  • UWP (C# - Universal Windows Platform - using the native audio DLLs, etc.)

I then wanted to examine the waveforms of all three recordings to see how well the apps played the audio out. Not scientific - all sorts of potential problems with interactions between processes, hardware conflicts, etc. But I just hoped to get a rough feeling - if one player was consistently showing drop-outs for example, it should be quite clear.

For background:
I did a similar recording test - Audacity playing a control WAV file (the same pure Sin wave) and all 3 apps recording it. All 3 recordings succeeded but the waveforms showed different attenuating effects going on and distortion of the sin wave (different distortions but consistent for each app).

Anyway, back to my playback issue:

The UWP/C# app plays fine and Audacity records its output fine and the waveform looks OK.

The Python apps do play the control WAV file fine. But when they start to play the control WAV file, Audacity just stops recording. There’s no error, nothing in the Audacity logs (Help > Diagnostics > Show log). No indication of why Audacity stops recording.

Any pointers much appreciated.

2

I think you made a messy assumption way back at the beginning. Computers have two natural sound pathways:

Application > Speakers or Headphones.
Microphone or Sound Source > Application.

That’s the total. That’s full stop. They don’t naturally connect to each other.

If you used the words “I played back” and “I recorded” in the same sentence, then some process or software must have provided that connection and that process frequently has its own damage and distortion. Early versions of this actually brought playback sound all the way out to the analog converter and only then turned it around to re-enter the system for recording, picking up both the D>A and A>D distortions along the way.

That gives us this complaint: “The only way I can get a good recording is to make my speakers too loud.”

Audacity would freeze if the data stream dropped dead, but nothing else failed. If I had to guess at it, I would say one of your redirects or special sound pathways failed.

Koz

3

Hi Koz,

Thanks for the reply.

I don’t think I made any ‘messy assumptions’… I generated a sin wave tone at 0.95 Pa, turned my volume up to max, closed my door and windows, sat still, stopped breathing and then:

  • hit record in my app.
  • hit play in Audacity.

I did that three times, once with each app.

Loading up the recordings made by the apps, Audacity allowed me to check the waveforms for drop-outs and distortion, compare absolute levels, see attenuation (over time). Of course, I could play them back too but they were too similar for me to get much from that (although I could hear the attenuation that the waveform showed).

I think the test ran as I’d expected - I think the sound left my speakers, travelled around the room and hit the mic from which Audacity made the recording - as I said, amateur - but adequate for my purposes.

Please do explain if I’ve misunderstood something.

I expected distortion, of course but the distortion I did see was not what I expected - the positive half of the sin wave was generally very well preserved (but not always). The negative half was quite badly distorted. The surprising thing is that the distortion I saw was very consistent within each individual recording, suggesting something ‘systemic’ rather than ‘random’.

Anyway, that was the app recording test - it showed me as much as I had hoped to learn within the limits of such a crude test - all three apps/technology stacks performed well with differing attenuation and distortion characteristics but no drop-outs.

But then I tried to do basically the same thing but with the apps playing and Audacity recording.

The C# app played and Audacity recorded it - it all worked as expected

As soon as the Python apps started playing Audacity just stopped recording. With no indication as to why.

As described above, as far as I know, the only sound-path link between the producer app and Audacity is the air in the room… I guess there’s some other conflict happening.

Perhaps the C# app is acquiring the ‘output’ device (speakers) and driving it but the Python apps are acquiring the ‘output’ and ‘input’ device (mic) and Audacity detects that it has lost the mic and so stops recording? That’s a complete guess but it might explain what I’m seeing. Any advice on proving that hypothesis very welcome.

BTW, Audacity didn’t freeze - it didn’t crash or stop responding to the UI. It just stopped recording as if I’d clicked ‘Stop’.

Thanks again for the response.

4

Ah!

If I use Windows Voice Recorder to record rather than Audacity it shows an error as soon as the Python starts to play:

Your microphone isn’t working. Check to make sure it’s plugged in.

So yeah - that supports the theory that the Python libraries are hijacking the mic.

I have a solution - I’ll just run Audacity on another machine. Job done.

Ivor

5

I’d recommend updating to 2.4.2 as it has 41 bug fixes after 2.4.1. Audacity ® | Download for Windows