4

I'm currently facing a problems with AirPlay device inside of my application. I used this topic as a sample for configuration of airplay device. But currently couldn't find any solution for two problems:

First of all, i couldn't detect if airplay device is currently busy or not, as it is not supports simultaneous input? I tried to find any property inside of CoreAudio but without any luck.

Second problem that I found was about airplay device with password enabled. I can't get any notification if password was entered or not, as result my application can't react as should on any of that events

Thanks in advance for any help.

Marchenko Igor
  • 63
  • 8

1 Answers1

1

I'm not familiar with the new CoreAudio APIs, so there might be a much simpler way. Here's how I solved the same problem last year.

You can determine whether the device requires a password with Bonjour (also called multicast DNS or Zeroconf). You should be able to match the source name with the CoreAudio info. For audio AirPlay, you need to check for _raop._tcp devices. Here's how it works from the terminal:

First, discover nearby AirPlay devices (note that the dns-sd command is called mDNS before Mountain Lion):

laurent ~ $ dns-sd -B _raop._tcp
Browsing for _raop._tcp
DATE: ---Tue 15 Jan 2013---
17:37:31.977  ...STARTING...
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
17:37:31.977  Add     2  4 local.                    _raop._tcp.               406C8F53F1DD@iMac de Laurent

Then, fetch the full record of the AirPlay instance:

laurent ~ $ dns-sd -L "406C8F53F1DD@iMac de Laurent" _raop._tcp local
Lookup 406C8F53F1DD@iMac de Laurent._raop._tcp.local
DATE: ---Tue 15 Jan 2013---
17:43:47.097  ...STARTING...
17:43:47.098  406C8F53F1DD@iMac\032de\032Laurent._raop._tcp.local. can be reached at iMac-de-Laurent.local.:5000 (interface 4)
 et=0,1 ek=1 ss=16 raAudioFormats=ALAC,L16 tp=UDP pw=false txtvers=1 ramach=iMac12,1 vn=3 md=0,1,2 sv=false sm=false ch=2 sr=44100 rast=afs rastx=iafs cn=0,1

pw=false indicates that there is no password. That's the basic idea, now you should do the same thing with DNSServiceResolve.

Now, the only way of checking if the device is busy that I know of is to actually connect to it. Internally, AirPlay uses RTSP, so you can send this request:

RTSP/1.0 OPTIONS *
# empty line

If the device replies with status 453, it means that it already streaming.

You can check my AirPlay RTSP stack for more information.

Laurent Perrin
  • 14,671
  • 5
  • 50
  • 49
  • Thanks a lot Laurent. It is quite helpful information. I leveled up this answer but still that is not "right" way. As I use CoreAudio the "right" way is to use it for all work with that device. If I wouldn't find any other solution i will mark this answer as excepted. – Marchenko Igor Jan 17 '13 at 21:19
  • Yeah, it would make a lot more sense to do this directly within CoreAudio. However, since third-part support for AirPlay is quite new in OSX, it wouldn't be surprising to find big holes in the API. – Laurent Perrin Jan 18 '13 at 13:47