1

I'm using the 64-bit PyAudio build available here, on Windows 7. When I import pyaudio and do pyaudio.PyAudio(), it works fine, but a large amount of what seems to be debug info is printed to stderr. There was a previous question on Stackoverflow about this here, but it's had no activity for over a year and appears unresolved.

As the asker of that question noted in his reply to the answer, redirecting stderr (by doing sys.stderr = somethingelse) does not stop the error messages from going to stderr. Even if it did, I don't want to redirect all of stderr just to handle PyAudio.

I have a suspicion that the problem is that this build of PyAudio and/or the PortAudio that comes with it was compiled with some sort of debug flag that is causing the debug info to be printed "raw" somewhere in the C extension code, bypassing the Python IO streams. So what I'm asking is:

  1. Can anyone confirm this behavior, and/or confirm that it doesn't happen with a different build of PyAudio for Win64? (I don't have the setup to compile PyAudio.)
  2. Is there any way to fix it without recompiling PyAudio? By "fix it" I mean suppress this debug output only from PyAudio (without redirecting stderr completely).

(If it's just an issue with this build I might try to contact the fellow who has made these 64-bit builds available and ask if he intentionally put up a debug version, since it's possible he just forgot to turn off debug when compiling.)

Edit: Here are the messages I'm getting. I'll try to condense them a bit because they're hundreds of lines long. I should also note that these don't look like error messages; they just seem to be status messages about various devices. I first get:

before paHostApiInitializers[0].
after paHostApiInitializers[0].
before paHostApiInitializers[1].
WASAPI: device idx: 00
WASAPI: ---------------
WASAPI:0| name[Realtek Digital Output (Realtek High Definition Audio)]
WASAPI:0| form-factor[8]
WASAPI:0| def.SR[48000] max.CH[2] latency{hi[0.010000] lo[0.003000]}
WASAPI: device idx: 01

Then a series of other similar messages starting with WASAPI and mentioning other devices (line in, microphone, etc.). Then:

WASAPI: initialized ok
after paHostApiInitializers[1].
before paHostApiInitializers[2].
Setup called
Enum called
noError = 0
Enum called
noError = 1
Device 1 has render alias
Device 1 has capture alias

. . . and again a bunch of other similar messages about "Enum called" and "capture alias" and so on. Then:

Interfaces found: 7
Device 1 has render alias
Device 1 has capture alias
Interface 1, Name: ATI HD Audio rear output
Creating pin 0:
No standard streaming
Creating pin 1:
Not source/sink
Filter NOT created

. . . and a series of similar blocks of messages for other device numbers. Then at the end:

after paHostApiInitializers[2].

That's what I see just on doing pyaudio.PyAudio().

Community
  • 1
  • 1
BrenBarn
  • 242,874
  • 37
  • 412
  • 384
  • 1
    I have added an answer to the old question, but it's for Linux and ALSA. Those messages aren't from PyAudio or PortAudio, but alsa-lib, see my post http://blog.yjl.im/2012/11/pyaudio-portaudio-and-alsa-messages.html Could you post the error messages you get? I may be able to help, even I don't use Windows. – livibetter Nov 19 '12 at 11:55
  • @livibetter: Thanks for your help. I edited my post to include the types of messages I'm getting. They seem a bit different than the ones you mention, because they mostly don't look like error messages, but just status information about various devices being identified. Any insight you can give would be appreciated. – BrenBarn Nov 19 '12 at 20:30
  • `WASAPI: initialized ok` this is a debug message of PortAudio via `PaUtil_DebugPrint()`. Your fellow indeed has a debug enabled build. From what I see, there is two ways, a) rebuild without debug flag b) set another function using `PaUtil_SetDebugPrintFunction()` to eat message, similar to what I did in another question. – livibetter Nov 19 '12 at 21:03
  • `PA_ENABLE_DEBUG_OUTPUT` is enabled by default in portaudio for Windows. I rebuilt without. – cgohlke Feb 11 '13 at 07:57

0 Answers0