Audio source specification for vidcap switcher

[MartinPulec]

Using video capture switcher allows only one global^[2] setting of audio input device, eg.:

uv -s embedded -t switcher -t testcard -t decklink -t decklink:device=1  # or
uv -s portaudio -t switcher -t testcard -t decklink -t decklink:device=1

First case works (allows switching) but it doesn't allow setting different input connector (analog/AESEBU) for second decklink (indexed 1). , on contrary, if analog was set, it won't work for testcard, which currently implements embedded only (but it doesn't unsuccessfully initialize, other devices may). ^[1]:

uv -t switcher -s analog -t decklink -s embedded -t decklink:device=1 doesn't work (both decklinks need to use either embedded or analog)

Second line works normally as assumed (portaudio is used all the time regardless video switching).

^[1] no longer valid since 594e6493 ^[2] "global" means that "embedded" is applied to all devices and audio will be switched alongside with video; if used "portaudio" instead, portaudio is a standalone device, so audio won't be switched (portaudio will be used all the time)

[MartinPulec]

The problem is actually twofold:

1. it is not possible to switch independent audio (like portaudio) alongside with video, eg.:

   uv -t switcher -s portaudio -t tescard -s embedded -t decklink # portaudio doesn't flow through video switcher

   This is mostly an architectural constraint that is difficult to workaround. I could at most allow testcard to utilize arbitrary audio device as its slave (something like -t testcard:apattern=portaudio:20)

2. setting different audio sources just from the set {analog, embedded, AESEBU}, something like (audio precedes matching respective video):

   uv -t switcher -s embedded -t testcard -s analog -t decklink -s embedded -t decklink:1

   This could be feasible, but it is questionable if it is not more confusing and error-prone than it is now. Also a different behavior will take place in following cases:

   uv -t switcher -s portaudio -t testcard -d decklink # <- portaudio captured all the time uv -t switcher -s embedded -t testcard -d decklink # <- embedded audio captured for testcard, but not for decklink

[TheSashmo]

Let me explain the use case, and maybe it will give you guidance on how it could work.

There are times when a client is not giving us any signal or source. So in a traditional workflow the path needs to be "Active" and sending some sort of signal.

What I was trying to aheive was have some sort of testcard, or recorded file, that is in the proper frame rate and resolution, with audio, of what the client is expecting, and just switch that source to another input using the switcher. All of this without having to restart the UG pipeline.

[MartinPulec]

So in context of this issue which audio you want to send? It is a bit unclear to me from the above, for video - I've (also from #316) understood that decklink + (one?) another device (testcard or file), right?

If so, I suppose that you'd perhaps want to send embedded audio either from one or the another device, regardless if the input is decklink or the fallback?

If the above holds, namely that you want to send embedded audio from the video source which it is switched to, we could come back to remaining issues in the original bug report because I believe that this should already work in UG, just pass one -s embedded parameter to UG (the position doesn't matter).

[MartinPulec]

Since a25b285, audio connections (analog/AESEBU/embedded) can be specified for vidcaps individually as described in wiki. This applies to audio connection specifications only, if using standalone audio device (like PortAudio), only that one device can be used (audio not switched). For the time being, I don't think that this is necessary to implement.

[MartinPulec]

Since audio connection can now be specified per vidcap input, I am closing this now. Only audio connection linked to a vidcap is possible to use in this way but I think that this was the requested behavior in the original bug report (#316).