fduncanh
commented
2 years ago I will close this pull request and break iit into samller pieces that are easier to review (1) raop API changes to /lib/raop* which will not impact use of unchanged raop API (2) changes to rpiplay to make use of them.
This is a "clean" pull request of the final form of my earlier one #249, which started out as a simple hack to put the port options in Waester's pull request #196 behind a command line option, as requested by pallas and FD-
However, this was not satisfactory: to quote FD-
_My main point is: The library currently supports multiple connections at once (even if the renderers don't support that), each with its own instance of raop_ntp, raop_rtp and raop_rtp_mirror. These are in the raop_conn_s structs. I'd like to retain that architecture, which means that each individual connection needs its own set of ports for raop_ntp, raop_rtp and raop_rtpmirror.
The new pull request implements FD-'s suggestion.
It required extending the API to allow the requested port numbers to be written into the structure raop_t raop, after raop_init is called but before raop_start is called. The embedded stored values are then available to be used later when the connection is made and the local timing, control, data and mirror-data port sockets are opened.
The new feature is accessed with a -p[n] option to rpiplay. Without this option, the previous behavior (random dynamical port selection, which fails if a firewall with closed ports is present) is unchanged.
-p uses Waester's legacy port choices, -pn (e.g. -p34567 for n = 34567) uses UDP and TCP on three consecutive ports starting at n. Ports must be in the range 1024-56535.