What chance then Peter of getting the player to 'echo'/broadcast the RDS packets it reads to a well-known UDP port (for example) so that Alex [or anyone elses] apps can also get their hands on the RDS packets being delivered to the player from the DSP?

It seems a real waste to have that valuable RDS data stream available in the empeg and yet have it locked away from the userland apps that really could make the best use of the data.

While its been a while since I did some unix socket programming I seem to recall a few mechanisms within Unix [and I suppose Linux too] whereby user level apps can 'share' in a fairly low-level resource wise way data via sockets such as Unix sockets or UDP broadcast sockets or similar.

In the best of all worlds, the player software would read [from config.ini?] a list of UDP ports to echo each RDS packet read from /dev/rds to and then each userland app [if more than one] could bind to a free UDP socket being sent the UPD packets.

In the worst case multiple userland apps could co-operate and rebroadcast amoungst themselves the RDs packets one of the them gets from the main UDP socket.

Either way Alexes problems would be solved as I don't think his application would mind a few milliseconds delay between the RDS packets arriving in the player and then being broadcast back out to his app.