>> So, we need to use the "networked transmitter" only for the control, and use
>> a local tx that generates our master audio (including CTCSS and everything
>> else) that is then timestamped and sent off to the network.
> NULL coded added for this. Maybe we need a NULL audio device on the RemoteTrx
> side as well but a UDP device can be used as a temporary replacement.
This is not required as Alsa has several methods of providing a NULL audio device.
There is a device named "null" and there also is a module "snd-dummy" that can be loaded
to provide a null soundcard that can be configured as usual. The NULL codec should be
enough. (I hope to test that soon)
Maybe this is also enough to avoid having to use two soundcards. We would like to avoid
that as we don't have many spare slots in some of the computers at hand.
I am trying to build the external UDP application but it is extremely tricky to get all the timing
correct (so there remains a nice but not too long queue of audio for the soundcard). As I am
trying to debug it at home I feed it with arecord and socat, and it turns out that does not output
the datagrams nicely spaced.
This made me realize that timestamping the datagrams on arrival on the UDP socket makes
it all dependent on scheduling in the (non-realtime) system. This will require further study.
>> So a test with a local tx sending output to Jack, using NetJack to
>> distribute it and then having some NetTx to send the PTT control alongside
>> would be possible.
> Yes, try that.
In the meantime I have put that solution back because it turns out that the plugin that makes
Jack emulate an Alsa soundcard is very unreliable (according to what is written in several
Making svxlink able to call Jack directly would be a solution, but that for now is beyond
my capabilities. And it may be very difficult to do because Jack is not interfacing via
filedescriptors so it cannot be incorporated in a select loop.