Unable to start queue. -- CODE: -66681

[chelsell]

Hi there,

I'm getting a very odd, sporadic, and difficult to reproduce error on OSX El Capitan version 10.11.6 (15G1510). To elaborate a little, simpleaudio works perfectly until one day or another I get this error, and the only way I've been able to get rid of it is by restarting the computer. Restarting always works, but it's a vexing error nonetheless. Below is the relevant part of the traceback. Let me know if you need more information.

  File "/Users/davidkokel/sauronx/sauronx/audio.py", line 145, in play
   aud = info.wave_obj.play()
  File "/Users/davidkokel/anaconda/envs/sauronx/lib/python3.5/site-packages/simpleaudio/shiny.py", line 20, in play
    self.bytes_per_sample, self.sample_rate)
  File "/Users/davidkokel/anaconda/envs/sauronx/lib/python3.5/site-packages/simpleaudio/shiny.py", line 61, in play_buffer
    sample_rate)
_simpleaudio.SimpleaudioError: Unable to start queue. -- CODE: -66681

[hamiltron]

Hi, thanks for the feedback!

Looks like that error code is a really generic and unhelpful one (on Apple's part): kAudioQueueErr_CannotStart

A few questions...

1. Is your app/script being run once over a long period of time or is it run (e.g. from the terminal) many times before the error occurs?
2. What is the sample rate and bit-depth (e.g. 44kHz, 16 bit) of the audio being played?
3. What is the likelihood that the audio being played is ever very short (less than a few milliseconds)?
4. What is the audio playback hardware (e.g. macbook or imac built-in audio, external audio interface, etc)?
5. Is the playback hardware ever being changed while the app is running?

Thanks,

-Joe

[chelsell]

Thanks for checking in!

1. My application runs from the command line in ~30 minute chunks, and we can run it dozens of times over the course of a few weeks before getting the error.
2. 44kHz, 16 bit .wav files.
3. Interesting. I might have to do some testing, but I feel pretty confident in saying 'no'. Certainly all of the files are hundreds of milliseconds at least, but it's possible that our application is doing something odd that results short plays.
4. It is an external USB device.
5. The playback hardware is changed to the USB device at the beginning and changes back to the built-in at the end. The application also switches back to built-in audio if the application fails.

Hope that helps. Really great package by the way, not having to rely on Port Audio makes my life much easier.

[hamiltron]

OK, interesting. A few thoughts ...

It could certainly be a bug in the library, but nothing is standing out and I wouldn't be able to pursue it any further without more detailed diagnostic information - which may or may not be possible to get.

There could potentially be other interactions with the audio interfaces that might cause trouble. I wouldn't rule out sleep/wake or display switching messing with audio interface assignments or other low-level hardware states. (I'm not sure if that applies to you.)

There's a remote chance the USB audio device driver might have a bug (or have some poor interactions with the stuff noted above). What is the audio hardware, if I may ask?

For 5, what is switching the default audio interface? Is it the python program? If so, how is that being done?

Some things to investigate (if you haven't already):

• When the audio interface becomes unusable, does it still appear in the system audio settings, and can it still be used by other programs (e.g. QuickTime)?
• Does disconnecting and reconnecting the audio hardware usb cable fix anything?
• If you can pinpoint the time that the first failure occurs, browse or search ('audio', usb', 'coreaudio', 'queue', etc) the logs in the 'Console' app around that time to see if anything looks related (probably a long shot but you never know).

... And thank you for the encouragement! I'm glad it's doing a small part to smooth the process of accomplishing your goals (at least when it's working 😉) - that's what I wanted it to do.

[chelsell]

Hi @hamiltron, sorry to leave you hanging! I got distracted, but I was reminded of the issue when the error happened again.

A few things:

• I think we can rule out sleep/wake because we run our application with caffeine due to previous problems. What do you mean by display switching?

• If by audio hardware you mean the USB device, it's this. If you mean the sound card, I think it's integrated into the motherboard, but apparently it's hard to tell what model the motherboard is. At least, I can't find it on Apple's spec sheets 🙄

• I'm using this application to switch the audio source on the command line.

• The interruption does not seem to have a persistent effect. In fact, if I simply run a shorter job in my application it will work fine.

• Reconnecting the USB device doesn't do anything. In fact, the error still happens if I play over built-in audio.

• I checked the log files, nothing stands out

What's especially concerning is that the error now seems persistent! Rebooting isn't working.

[hamiltron]

Thanks for the additional info. That ruled out a few things including the specific audio interface. (Getting the error with the onboard audio is pretty significant.)

So tell me if I understand the use case here ... The computer effectively never sleeps (that's good). You have a script that run a little utility (pretty handy) which switches the audio output, runs the Python app, and switches the audio back, all over about 30 min. This happens possibly multiple times in succession.

And tell me if I understand the problem ... sometimes the app crashes with the above error, repeatedly with the same input/audio files/etc but will not crash with others. Restarts are now not reliable fix.

Remaining questions ... Is it crashing immediately when playback attempted, somewhere in the middle, or toward the end of the app run? Is the Python app playing separate clips of audio over the roughly 30 min or is it one giant sound clip? If it's playing a sequence of clips, what's the range of duration? Does either the total length of audio played or total number of clips played seem to correlate with crashes?

[chelsell]

Yep, that's all right. I'm still trying to figure out what might be different about the audio I'm playing that is always resulting in the error.

It always happens at the end. In fact, the odd thing is that the error seems to happen after all my playback events actually happen. In fact, looking at it now, it seems like the error happens 10 seconds after the last bit of audio plays. Could that possibly be right? There might be a problem with the way I'm calculating that, because unfortunately my most detailed log file never gets written due to the error. But it's tough for me to account for a full 10 seconds the way I'm calculating it now...

The sound clips are separate.

The duration is typically hundreds of milliseconds. In this particular example, they're all right around 200 milliseconds.

Well, I certainly can't reproduce this on shorter runs. In the past, I've been able to reproduce it by spamming playback commands, so certainly the number and frequency of the clips played seemed to matter. But I just tried that again and it doesn't seem to be working.

[hamiltron]

OK, this is starting to smell like a possible resource leak, but I still don't know where that could be at the moment. I'm also curious whether playing a zero-length buffer/array/clip could cause problems. I will need to test when I get a chance.

This has definitely highlighted the issue that there's no easy way for a user to get detailed debug information. I think I will prioritize changing that and making the debug prints switchable at run time rather than compile time.

[chelsell]

@hamiltron I think we may still have the error sporadically, but it looks like we may have been playing very short, silent audio files after all. Since we changed that, we no longer consistently get the error. I wonder if we'll still get it sporadically, and update you if we hit it again. Thanks so much for your help!

EDIT: this proved to be premature, I continued to have persistent difficulties. However, I was apparently able to fix the recurring issue by clearing the NVRAM on the desktop.

[hamiltron]

Sorry to hear that this is persisting. I've tested out trying to play some empty arrays on OSX. An empty byte string crashed the interpreter with a segfault and an empty Numpy array crashed it with a 'Bus error: 10'. So ... probably some bugs to be sniffed out there, but nothing has behaved like your situation yet. As I've said before, my next update will make debug prints run-time switchable to hopefully aid in troubleshooting tricky cases like this.

[ckiw]

Hello, I'm using simple audio and I stumbled on the same problem. I use macOS sierra version 10.12.6, python 3.7 My use case is to play different songs of ~1 minute via a python script, every few minutes or more. And randomly (10 minutes to 3 hours) I get the _simpleaudio.SimpleaudioError: Unable to start queue. -- CODE: -66681 error I'm still investigating but this take time héhé. If you have solution that I can use to deal with this error, I'd be glad to hear it. Thanks