Not all zmq protocols supported. about odr-audioenc HOT 3 CLOSED

Yep. I didn't want to support too many options, to reduce amount of testing and documentation.
If you have a need you cannot reasonably cover with the existing options, please open the ticket again and explain why it would make sense to include IPC.
Thanks!

from odr-audioenc.

I think it would not need any additional testing or documentation, because that is entirely handled by zmq. Just need to make the zmq endpoint argument accept all the valid zmq endpoints instead of filtering for specific protocols.

The dabmux even accepts IPC, I think, but audioenc cannot output it, because the protocol is not recognized as zmq.

But you are right: one can just use TCP, but I think IPC has the benefit of not using the TCP stack and being more optimized.

And it just requires an additional accepted prefix for zmq in the argument parsing logic, or removing that logic all together and not trying to pre validate the zmq endpoints, because that should be handled by the library itself.

from odr-audioenc.

It's not the "what does it do" nor "how does the protocol work" that needs documentation, it's "when to use it". That's what the guide and the scenarios in the README aim to present.

And the only things that don't need additional testing are things you do not support. That was also my reasoning behind putting the validation in the code.

But that doesn't mean it has to stay like that. The advantage I see with the ipc transport is that you don't block TCP ports (I cannot say anything about one being more optimized than the other).

I'm fine with elevating ipc to the same level of support as epgm, which is to say "use at your own risk, we don't guarantee anything", and I'd welcome a patch adding ipc:// to the list or removing the check (but filename detection needs to be done differently) and update the usage screen accordingly.

from odr-audioenc.