-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with CallbackFlags not being set? #64
Comments
Thanks for having a critical look at this, I appreciate that! ad 1) That's strange, the sleep trick should do it. Another way would be to set the block size to an insanely low value, e.g. ad 2) This has never worked for me (I tried it on Linux). The PortAudio documentation isn't very verbose about that, but if I remember correctly (probably this was mentioned on the mailing list?), this is only supposed to work on certain host APIs. I've actually started working on an example (ce662b8), but like you, I've never seen the flag. And since I got the impression of it not being available on all host APIs, I just abandoned it. Feel free to investigate further! What host API(s) are you using? |
ad 1) I'll try reproducing my problem with one of the simplified examples I was testing in Windows 10 w/ ASIO mainly, but I will try testing the priming feature on linux w/ ALSA as well. BTW the code that I'm working on for streaming audio files is posted as a public gist here |
OK
So obviously something went wrong in the background but Portaudio is not completely aware of it. I'm mainly concerned about this because I need my application to exit as soon as there are any underflow/overflows. If portaudio can't tell me that reliably then I'm in a pinch. EDIT: This issue only seems to occur in windows. In linux the underflow flag does get set. |
Thanks for sharing your code, that's really interesting. I had the feeling that your Regarding your actual problem: Thanks for the additional tests. Sadly, I have no idea why sometimes you don't get the expected callback flags. This might be a problem with PortAudio itself, but I'm not sure. |
Yeah the way I wrote the classes isn't ideal, mostly because of having to duplicate code, but it wasn't too difficult to write so it's not a big deal for me. I made some updates to my code and now it seems like I can reliably get it to raise an underflow condition but I'm still not really convinced of how reliable this flag really is. I have an inkling that underflow can still occur without portaudio letting you know if the drop out is short enough. (I wonder if it's possible that data might be getting dropped over USB since I'm using a USB audio device). I'll see if I can dig a little deeper in the following days. I have not tried the different DLL's, I'm just using the windows sounddevice build provided by gohlke. That uses a pretty recent portaudio version right? |
OK, I've merged #65 anyway. If you have any ideas how to improve the API for a use case like yours, please tell me! I don't know how reliable those flags are, in case of doubt you could ask on the PortAudio mailing list. PortAudio has loopback tests which should be able to detect dropped audio blocks. I've been meaning to port them to Python, but I haven't yet. See #14. If you like to implement this or have some other ideas how to systematically test this, that would be great! And yes, the Gohlke DLLs should use the most recent PortAudio version. But to be sure, you should check |
@mgeier I've reviewed #65 and it looks really helpful. Thanks for adding this! Hmm the PortAudio loopback tests look pretty extensive. I had approached loopback testing from a very different angle in my tests for the audio file streamer script I've been writing. The test code is here. All I'm doing in the tests is to generate a stream of random integers then verify them in a separate thread as the audio data comes in. I used the ALSA loop module - snd-aloop - to set up a virtual loopback device then configured that using the .asroundrc file I posted along with my code. I have very little experience with JACK but likely I could adapt my scripts to use it and maybe make something that works across platforms. BTW I've added some comments to #14 |
I guess it doesn't have to be JACK. |
I don't really know anything about travis-ci..do you get to choose the OS you're running? The upside to using JACK is that JACK works across platforms. Mine was more of a one off test. I'll try using the JACK dummy driver when I get some spare time. |
I'm going to consider this issue closed at this point. It may be that portaudio doesn't always properly detect underruns, but that doesn't have anything to do with sounddevice. Same goes for the Many thanks for your support! |
AFAIK, Linux (Ubuntu) and OSX are supported. Here are two working Linux example configurations I've made: OSX can apparently be enabled with: os:
- osx There are also other CI services available, it doesn't have to be travis-ci if something else works better.
That's theoretically true, but AFAICT PortAudio can only really use it on Linux. But anyway, those loopback tests don't have to be host API-specific, people can just use an actual physical cable on any platform.
The |
Well JACK is available on Windoze but now that I look into it I see that its support in Windows relies on using Portaudio which seems to defeat the purpose of using jack for testing. I'll defer to you on the OSX testing, I don't have an OSX machine to test on and I'm not really familiar with it. |
This is actually two issues that I have when doing full-duplex streaming using my own callback function:
I wanted to make sure that the over/underflow flags were indeed set when my callback function was too slow but it doesn't seem to be working. To simulate this, I just put a
time.sleep(1)
inside the callback, but no error was raised and none of the callback flags are set on the next callback. Do you have any code that tests this functionality indeed works as intended?I tried setting the prime_output_buffers_using_callback parameter, but my callback function never gets a call where
status.priming_output
is true. I'm using full duplex streaming, is there any other reason why this option might be ignored? Have you tested this option?The text was updated successfully, but these errors were encountered: