tx_audio_stream api, who has the stream?

  • 1
  • Question
  • Updated 8 months ago
I'm using the API and trying to determine the state of the TX audio stream.  In short, I'd like to know which if any of the DAX clients connected to the radio have the blue TX button lit up.

When I toggle the button either on/off or from one DAX client to another I do get messages from the radio.  It's trying to tell me something:
S63E5DC0F|tx_audio_stream 0x84000000 in_use=1 dax_tx=0 ip=192.168.2.111 port=4993
S63E5DC0F|tx_audio_stream 0x84000001 in_use=1 dax_tx=0 ip=192.168.2.179 port=4991
But, when I toggle the TX button back again, I get exactly the same set of messages.  I was expecting that an in_use field might change or that I'd get a 'streaming=1' on one of them like what I see with the IQ streams.

Did I forget to subscribe to something?  I have no trouble determining this for the IQ streams but I cant seem to tell which of the TX or RX streams are currently active for a given client.

Thanks.

--Don
Photo of K1DBO

K1DBO

  • 426 Posts
  • 74 Reply Likes

Posted 8 months ago

  • 1
Photo of Wayne

Wayne

  • 614 Posts
  • 84 Reply Likes
Does the Ip address relate to the client that the stream is going or coming from? Just a thought ..
Photo of K1DBO

K1DBO

  • 426 Posts
  • 74 Reply Likes
Hi Wayne,

Yes, the ip address shown for each stream is the address of the machine running DAX.  Multiple machines can run DAX and have a TX stream.  However, only one of those streams can be active at any time.  The active stream is the one where the DAX client shows the TX stream button in blue.  I am trying to figure out how a DAX instance knows if it's button should be blue or grey. 

The API must provide the information.  I'm just not seeing it.  The lines I posted above show the only updates sent from the radio when the DAX TX stream is enabled or disabled from a DAX client.  At first I thought there was a bug in the API implementation.  That it wasnt sending the right updates to the other connected clients.  But, the fact the multiple DAX clients are able to keep their buttons correctly colored has turned my suspicions inwards.  I must be missing a subscription. 


--Don
Photo of Mario - DL3LSM

Mario - DL3LSM

  • 63 Posts
  • 23 Reply Likes
Hi Don,

you stumbled over one of the puzzles of the API because it is not clear what is going on. There is no information about the tx stream/client which data is actually send.. From my tests it seems that it is the last client who issued the "dax tx 1" command. And really I don't see (in Wireshark) from where the SmartDAX client is getting the information that another client has pressed the "TX" button and that it should deactivate the "TX" button. There is no clear status message so my best bet is that SmartDAX interprets the status messages according to it's internal state..

It would be really nice if someone from Flex would chime in as in xDAX I would really like to also deactivate the button for the tx stream if some other DAX client activates his tx stream but I don't know how to recognize this event.

Thanks and 73
Mario, DL3LSM
Photo of K1DBO

K1DBO

  • 426 Posts
  • 74 Reply Likes
Hi Mario,

Yeah, it is a good one, isnt it.  Knowing of your work on xDAX I was hoping you or someone from Flex would reply.  It's interesting that you've noticed the same issue.  

While I do suspect there is a bug in the API, clearly there is some other way, possibly easy, to get the information.  Have you observed the behavior of the UDP stream as the activation moves from DAX client to DAX client?  The existence of the stream object together with packets arriving at the UDP interface might be all it takes.  

In your case, where you care to process the UDP packets anyways, that might be fine.  In my case I dont care to process the packets at all.  I just need to know who might.

--Don
(Edited)