-
Notifications
You must be signed in to change notification settings - Fork 151
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
Achieving stable latency between calls of "playrec" #521
Comments
I think this depends on your hardware and maybe also on the host API (none of which you disclosed). Some devices reliably (and sample-accurately) provide the same latency (given the same But yes, either way, during the runtime of a single stream, the latency should stay mostly constant, except maybe for some clock drift. Some suggestions:
|
@davircarvalho alternatively you could try to compensate the varying delays after capture. However, it depends on your application how this could be done, or if at all. |
Hi sorry for the late reply, I've been trying with MME and WASAPI, but behaviour is similar. I'm testing with virtual audio cable and with an rme madiface pro interface. The actual reported latency is always the same. I'm doing a loopback measurement, where I call play rec multiple times and have a sleep time in between the call. When I overlay the outputs however they don't align perfectly. Am I just being naive to expect MME / WASAPI to deliver sample accurate stability, or could there be something else I'm not really understanding? This is my current test script:
and this is what I'm observing here, all the curves shold be a single line: Thanks for your help :) |
Please try all host APIs and report back. Please also provide your device list. Otherwise the device IDs in your code are meaningless. Also, it would tell me which host APIs are even available. MME isn't made for low latency, so I wouldn't expect stable latency either. With WASAPI, I would only expect good behavior in "exclusive" mode, see https://python-sounddevice.readthedocs.io/en/0.4.6/api/platform-specific-settings.html#sounddevice.WasapiSettings ASIO normally gives the best (i.e. lowest) latency values, maybe also the most stable ones.
I don't understand, both at the same time? Please elaborate. |
That's the thing, I don't really mind how large is the latency, as long as it is stable.
As mentioned in my previous message the script is run in loopback (the output is connected to the input of the same interface), either digital interface in the case of Virtual Audio Cable (VAC), or a hardware interface in the case of the madiface (here a cable is used to connect the output to the input of the same interface). This setup is done for testing latency only not in the real use case. In the test code I sent above I was using virtual audio cable interface, so output of VAC goes into the input of VAC.
I'd love to use ASIO but unfortunately my signal flow wouldn't allow to use ASIO because I'd need to mix APIs (which I don't it's possible, please correct me if I'm wrong) this is my current device list, but please keep in mind the IDs are different now from the ones I used in that code. If I were to run it with the current config I'd use output ID 11 and input ID 2 in the case of MME
|
Well, typically when someone cares about latency, it is short and stable, and if not it's none of those.
Did you try? I'm not seeing your RME sound card in your device list, am I missing something? Can you please try all available host APIs? |
Being able to isolate the effect of the latency is a very common use case in acoustic measurements. If you can remove the latency caused by the equipment it's possible to extract lots of useful information from what you're measuring, for example the propagation time from a speaker to a microphone. But more importantly you're able to sync multiple measurements. If I measure the latency before a measurement I can post process all subsequent measurements to remove the delay caused by the latency, however if the latency keeps changing as shown in my previous reply, then post processing to remove the system's latency is becomes unviable.
I just didn't have it pluged when I called sd.device_query
|
Of course, it may be very relevant to compensate for the delay correctly. I have done extensive measurement series utilizing EDIT: To clarify, the (second) loopback channel is output and recorded simultaneously each time, of course. |
Hello,
I'm just looking for advice on the best way to implement this.
I have a system I want to do calls of simutaneous playback and recording. When I do multiple (non-concurrent) calls of sd.playrec() each one ends up with different latency.
I believe this happens because the stream within sd.playrec() is closed after each playrec call, then after subsequent call portaudio will deliver a slight different latency.
If I want to achieve constant latency which is sample accurate across all calls of a "playrec" function, I suppose I need to start one stream and use it for all the "playrec" calls? Is such goal even realistic?
Any help is appreciated!
The text was updated successfully, but these errors were encountered: