What audio capture device to use for a duplex connection?

[ygreq]

Hi there,

I started testing duplex communication between 2 powerful Windows laptops on the local network for now. I first tested sending webcam data back and forth. Everything working fine. I will put the scrips I used in case you notice some other mistakes I am doing.

PC1 uv -t dshow:device=4:mode=0:RGB -c libavcodec:codec=H.264 -d gl:d 192.168.1.202
PC2 uv -t dshow:device=1:mode=0:RGB -c libavcodec:codec=H.264 -d gl:d 192.168.1.104

Then I tested sending and receiving data from OBS via Spout
PC1 uv -t spout:name=fromOBS:fps=60:codec=RGB -c libavcodec:codec=H.264 -d gl:spout=fromUV 192.168.1.202
PC2 uv -t spout:name=fromOBS:fps=60:codec=RGB -c libavcodec:codec=H.264 -d gl:spout=fromUV 192.168.1.104

Now I am trying to figure out how to also send audio data. I tested this and it seems to work, sending a sample wave from testcard:

PC1 uv -t spout:name=fromOBS:fps=60:codec=RGB -c libavcodec:codec=H.264 -d gl:spout=fromUV -s testcard -r portaudio 192.168.1.202
PC2 uv -t spout:name=fromOBS:fps=60:codec=RGB -c libavcodec:codec=H.264 -d gl:spout=fromUV -s testcard -r portaudio 192.168.1.104

But I tried -s audioport afterwards and it does not work. Any idea what to write in order to send internal microphone data back and forth? I also tried -s embedded but does not work and it gives me some error written in Chinese idioms. -s wasapi does not work either.

PC1 uv -t spout:name=fromOBS:fps=60:codec=RGB -c libavcodec:codec=H.264 -d gl:spout=fromUV -s portaudio -r portaudio 192.168.1.202
PC2 uv -t spout:name=fromOBS:fps=60:codec=RGB -c libavcodec:codec=H.264 -d gl:spout=fromUV -s portaudio -r portaudio 192.168.1.104

These are the available audio capture devices:
AESEBU
analog
embedded
jack
none
portaudio
testcard
wasapi

And these are the available audio playback devices:
AESEBU
analog
decklink
dummy
embedded
jack
mixer
none
portaudio
wasapi

BTW, is there a better option for audio playback devices instead of portaudio?

Thank you!!

[ygreq]

Hmm.. I've been using Max to send out commands and just tested via cmd and it seems to work actually.

So one question remains. Is using -s portaudio and -r portaudio the best option or is there some other option that I didn't figured yet?

Thank you!!

[ygreq]

Hey, Martin! The file you shared is called libportaudio.dll. The file presented inside of UltraGrid is called libportaudio-2.dll. I tried the following:

1. I copied your file thus having both files. Same problem:

Created new RTP session with SSRC 0x08042d33.
Assertion failed!

Program: C:\UltraGrid\uv.exe
File: ../portaudio/src/hostapi/wdmks/pa_win_wdmks.c, Line 1061

Expression: FALSE

2. I copied your file while deleting the old file. I renamed your file to libportaudio-2.dll. It gives me an error when trying to play UltraGrid. Even uv -t help gives me the same error. The error is:
uv.exe - Entry Point Not found. The procedure entry point Pa_getVersionInfo could not be located in the dynamic link library C:\UltraGrid\uv.exe

3. Like I was saying, portaudio used to work on this PC. And you said that it is distributed with the program utilizing it. So I redownloaded UltraGrid and put it on a new location. I tried running it from there but I get the same error as point 1

What else is there? Or what am I doing wrong?

[ygreq]

I just tested UltraGrid v1.4 and I don't have this portaudio problem anymore. I will test v1.5 asap.

I don't know why I did not think about this sooner. Probably because I still think that I tested the last version and it worked. Hm Hmm

LE: I tested v1.5 and it works as well. Freshly downloaded v1.6 gives me the portaudio error.

[MartinPulec]

Freshly downloaded v1.6 gives me the portaudio error.

Could you try rather the continuous build? 1.6 is a bit obsolete - there was one important fix since then that may affect that issue. Alternatively you may try --audio-capture-format channels=2 to enforce 2 captured channels with version 1.6, although I'd strongly recommend using continuous builds, anyway.

As for the Portaudio DLL - it should work with the continuous branch, I guess that with former versions it is binary incompatible.

[ygreq]

Ah! I didn't know about the continuous branch. Thank you!!!

BTW, I believe I used v1.6 and portaudio worked until it didn't. Oh well! It works now!

[MartinPulec]

BTW, I believe I used v1.6 and portaudio worked until it didn't. Oh well! It works now!

It is possible - there are 2 possibilities - either the library itself has changed (the build always grabs current version /from the particular channel/) or your HW setup has changed. That is a nasty thing about Portaudio that it has some asserts inside where it shouldn't be - normal runtime failures causes crash of the whole program, even though the problem may be in a (sub)device that you even don't intend to use (since all are initialized to some extent).

Anyways, I'd recommend the use of continuous track for now - it is more up-to-date and easier to fix problems there. I tried to backport the WASAPI fix to 1.6 but it was a bit complicated so I abandoned the idea. Hopefully there will be a new UG release next month.

[ygreq]

When doing uv -r portaudio:help a newly reinstalled Win 10 machine I get
[NAT] Private outbound IPv4 address detected and bound to a non-dynamic port. Consider adding '-N' option for NAT traversal.

May I ask what this is? I can just add -N, but I am still curious. I am still struggling with networking and google is not that helpful.

Thank you!

[MartinPulec]

It basically means that you are acting as a receiver and you are behind NAT. This obviously may not matter if also the sender is inside the same NATted subnetwork but this is just a hint if someone tries outside->inside NAT sending. I'll perhaps adjust the message to be more clear. If you, however, use UG just inside a LAN, it is not relevant.

Just to what it does - it tries to utilize NAT-PMP or PCP for NAT traversal (also see here for some additional info.

[ygreq]

OK. portaudio as well as wasapi are working with the continuous version. :D I had no idea about its presence. I was using v1.6 this was causing all the problems.

One problem remains related to audio. I finally got to test in separate rooms and it easily creates feedback loop noise simply from the sound coming out of the speakers looping back to the mic of the same pc. I will search the Discussions here to see how people managed this.