search

FDH2 / UxPlay

AirPlay Unix mirroring server
GNU General Public License v3.0
1.35k stars 72 forks source link

Bug raop_ntp receive timeout 1 #153

Closed koaie closed 1 year ago

koaie commented 1 year ago

When connecting to uxplay with the following options: "uxplay -avdec -nh -n ice -vs 0 -as pulsesink -d" on debian 11.5 kernel 6.0.0-0.deb11.2-amd64. Using Pulseadio as it is the audio server i have installed. Server is using uxplay 1.58 on amd cpu and gpu (rx 550) client is m1 air on ventura 13.0.1 using the safari browser, on youtube. I have compared to the debug of version 5.12 with nothing out of the ordinary, the timeout pops up out of nowhere, no audio is heard.

uxplay-debug.txt

fduncanh commented 1 year ago

I did find a problem with -vs 0 that caused a segfault (which you didn't get) and it is now fixed in latest github source (which will become uxplay-1.59 sometime soon) (commit https://github.com/FDH2/UxPlay/commit/2644133234720c0c6f8efbc2ac6c69e3ccac0d87 )

-vs 0 is no longer the preferred way to stream without video (it hadn't been tested for a while, so the bug had crept in at some point): uxplay now also supports apple-lossless ALAC audio in audio-only streaming (this is different from -vs 0) But I don't know if a Mac can do ALAC audio like an ipad or iphone can.

In any case, after a small fix to the -vs 0 option, it now works for me for sending youtube audio (Pink Floyd) from safari on a macbook pro, with "uxplay -avdec -nh -n ice -vs 0 -as pulsesink -d"

In your debug trace, you never got an audio connection. The timeouts in your trace are a failure of the uxplay server to get a ntp time syncronization signal that it request from the client every 3 secs, so maybe you have some different problem, before getting to the one I found and fixed. If the server is behind a firewall, 3 UDP and 3 TCP ports must be open, one of them is for the ntp time signal (uxplay option -p is needed if there is a firewall).

Thanks for the report, it helped improve uxplay.

Please try latest uxplay from github. uxplay -v will report "uxplay-1.59"

koaie commented 1 year ago

Hi, it can not be a port thing as if I go to audio settings and choose the uxplay server it works, but then my entire device audio is played through ux play, any way I can help reproduce this or send more logs? my problem occurs regardless if I have video streaming disabled.

thank you

REPLY: yes, it is not a uxplay server port issue, it is that your client did not provide its timing port ("timing_rport, remote port from uxplay's viewpoint, since client did not specify a port, uxplay tried contacting client on port 2048, presumably some old default port)

fduncanh commented 1 year ago

your debug.txt

SETUP rtsp://10.0.0.9/9285097316790781247 RTSP/1.0
Content-Length: 599
Content-Type: application/x-apple-binary-plist
CSeq: 6                           <============Message Sequence # 6 in server-client dialog
DACP-ID: E4658F3C5E1567D
Active-Remote: 3866525343
User-Agent: AirPlay/665.13.1  <==client User-Agent string (indicates macOS Ventura 13.0.1, I guess)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>et</key>
    <integer>32</integer>
    <key>statsCollectionEnabled</key>
    <false/>
    <key>eiv</key>
    <data>
    4qWmMgo0xsz+Fuc4lKt1fQ==
    </data>
    <key>sessionUUID</key>
    <string>80DB4AD0-A83F-453F-ABF5-D76EB07FD87C</string>
    <key>isRemoteControlOnly</key>   <===========this could be part of problem???
    <true/>
    <key>timingProtocol</key>
    <string>None</string>       <======================HERE IS THE PROBLEM!!!!!!
    <key>osName</key>
    <string>macOS</string>
    <key>osBuildVersion</key>
    <string>22A400</string>
    <key>sourceVersion</key>
    <string>665.13.1</string>
    <key>osVersion</key>
    <string>13.0.1</string>
    <key>ekey</key>
    <data>
    RlBMWQECAQAAAAA8AAAAAPd1laBoVKFSjF5TLgcfNcEAAAAQq5e7lZXbSl23L8fAXHYx
    XOvAnvGnWY+uYHkFFvSDu9CRaH5f
    </data>
    <key>sessionCorrelationUUID</key>
    <string>36E00248-02BC-4F1B-8086-56F815A2CAE3</string>
    <key>deviceID</key>
    <string>A4:C6:F0:0B:72:39</string>
    <key>model</key>
    <string>MacBookAir10,1</string>
    <key>name</key>
    <string>koie</string>
    <key>macAddress</key>
    <string>A4:C6:F0:0B:72:39</string>
</dict>
</plist>

Handling request SETUP with URL rtsp://192.168.1.8/1935742912206425072

timing_rport = 2048   <========some default port, as client never told uxplay where to send timing requests
raop_ntp parse remote ip = 10.0.0.240
raop_ntp starting time
raop_ntp local timing port socket 21 port UDP 34487
raop_rtp parse remote ip = 10.0.0.240
raop_rtp_mirror parse remote ip = 10.0.0.240
eport = 43283, tport = 34487

raop_ntp send_len = 32, now = 1670705480625642   <==== you never get a reply to this from the client
raop_ntp receive timeout 1 (limit 5) (request sent 2022-12-10 20:51:20.187306)

raop_ntp send_len = 32, now = 1670705483938946
raop_ntp receive timeout 2 (limit 5) (request sent 2022-12-10 20:51:23.500610)

raop_ntp send_len = 32, now = 1670705487266660
raop_ntp receive timeout 3 (limit 5) (request sent 2022-12-10 20:51:27.828324)

raop_ntp send_len = 32, now = 1670705490598893
raop_ntp receive timeout 4 (limit 5) (request sent 2022-12-10 20:51:30.160557)

raop_ntp send_len = 32, now = 1670705493922648
raop_ntp receive timeout 5 (limit 5) (request sent 2022-12-10 20:51:33.484312)
raop_ntp exiting thread
***ERROR lost connection with client (network problem?)
   Client no-response limit of 5 timeouts (15 seconds) reached:
   Sometimes the network connection may recover after a longer delay:
   the default timeout limit n = 5 can be changed with the "-reset n" option
reset_video 0
Removing connection for socket 20
Destroying connection
Removing connection for socket 22
Destroying connection
Exiting HTTP thread

your client did not tell uxplay which port it expects to receive timing requests on, instead it said "timingProtocol" was "None"

my posted uxplay-1.52 debug shows the expected reply.

SETUP rtsp://192.168.1.8/1935742912206425072 RTSP/1.0
Content-Length: 585
Content-Type: application/x-apple-binary-plist
CSeq: 6
DACP-ID: 22A80D15EE336CD4
Active-Remote: 1313694374
User-Agent: AirPlay/610.19.1

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>et</key>
    <integer>32</integer>
    <key>eiv</key>
    <data>
    CGWI+A9Yacw4U/vHXDkBSg==
    </data>
    <key>timingProtocol</key>
    <string>NTP</string>        <====client will use NTP timingProtocol
    <key>sessionUUID</key>
    <string>1ADD23EC-328B-4BF0-A3ED-E91D77015191</string>
    <key>diagnosticsAndUsage</key>
    <true/>
    <key>osName</key>
    <string>iPhone OS</string>
    <key>osBuildVersion</key>
    <string>19E258</string>
    <key>sourceVersion</key>
    <string>610.19.1</string>
    <key>timingPort</key>
    <integer>50446</integer>   <=== client tells uxplay which port to request timing signals from
    <key>isScreenMirroringSession</key>
    <true/>
    <key>osVersion</key>
    <string>15.4.1</string>
    <key>ekey</key>
    <data>
    RlBMWQECAQAAAAA8AAAAACA4z+0g3Lk/IFLiUFvqOqAAAAAQ+mFYp0KGw3ymNjPlY6An
    NJ4no/Pblxr/PokZQyPMR1n3ZKjV
    </data>
    <key>internalBuild</key>
    <false/>
    <key>deviceID</key>
    <string>XX:XX:XX:XX:XX:XX</string>
    <key>model</key>
    <string>iPad7,11</string>
    <key>name</key>
    <string>X’s iPad</string>
    <key>macAddress</key>
    <string>xx:xx:xx:xx:xx:xx</string>
</dict>
</plist>

Handling request SETUP with URL rtsp://192.168.1.8/1935742912206425072

timing_rport = 50446    <========uxplay sents timing requests to this port on client
raop_ntp parse remote ip = 192.168.1.138
raop_ntp starting time
raop_ntp local timing port socket 27 port UDP 7011
raop_rtp parse remote ip = 192.168.1.138
raop_rtp_mirror parse remote ip = 192.168.1.138
eport = 7000, tport = 7011

raop_ntp send_len = 32, now = 1651552062528799
raop_ntp receive time type_t=83 packetlen = 32
80 d3 00 07 00 00 00 00 e6 1b 2d be 87 5f 5f 0b 
83 ac a4 1b 13 6e ee ee 83 ac a4 1b 13 76 dc f9 

raop_ntp sync correction = -1651411363454250
fduncanh commented 1 year ago

This is the correct response from a MacBook Pro (unibody, Intel, running Catalina macOS 10.15.7)'

SETUP rtsp://192.168.2.8/5814186892492819098 RTSP/1.0
Content-Length: 535
Content-Type: application/x-apple-binary-plist
CSeq: 6
DACP-ID: AD8709EF1077DDD3
Active-Remote: 1824468003
User-Agent: AirPlay/425.1          <========client's User-Agent string, 425.1 is macOS Catalina 10.15.7

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>et</key>
        <integer>32</integer>
        <key>eiv</key>
        <data>
        0qmJKglq1c/TxvhK6CQ1hQ==
        </data>
        <key>timingProtocol</key>
        <string>NTP</string>                <=========timingProtocol = NTP
        <key>sessionUUID</key>
        <string>50B0242C-80C4-4A9A-BA21-053982869B8E</string>
        <key>osName</key>
        <string>Mac OS X</string>
        <key>osBuildVersion</key>
        <string>19H2026</string>
        <key>sourceVersion</key>
        <string>425.1</string>
        <key>timingPort</key>      
        <integer>58508</integer>    <==== client's timingPort = 58508
        <key>isScreenMirroringSession</key>
        <true/>
        <key>osVersion</key>
        <string>10.15.7</string>
        <key>ekey</key>
        <data>
        RlBMWQECAQAAAAA8AAAAACtALwHFFBzwlKxYvmCeC24AAAAQ6etsczcXvs5Nu6s7/doP
        PPM6PGrpsHjXfsHt0lfVYLG/Ph0p
        </data>
        <key>deviceID</key>
        <string>40:6C:8F:47:42:B4</string>
        <key>model</key>
        <string>MacBookPro9,2</string>
        <key>name</key>
        <string>phy-haldane-mac</string>
        <key>macAddress</key>
        <string>7C:D1:C3:8A:4A:18</string>
</dict>
</plist>

Handling request SETUP with URL rtsp://192.168.2.8/5814186892492819098
DACP-ID: AD8709EF1077DDD3
Active-Remote: 1824468003
Transport: null
SETUP 1
eiv_len = 16
16 byte aesiv (needed for AES-CBC audio decryption iv):
d2 a9 89 2a 09 6a d5 cf d3 c6 f8 4a e8 24 35 85 

ekey_len = 72
ekey:
46 50 4c 59 01 02 01 00 00 00 00 3c 00 00 00 00 
2b 40 2f 01 c5 14 1c f0 94 ac 58 be 60 9e 0b 6e 
00 00 00 10 e9 eb 6c 73 37 17 be ce 4d bb ab 3b 
fd da 0f 3c f3 3a 3c 6a e9 b0 78 d7 7e c1 ed d2 
57 d5 60 b1 bf 3e 1d 29 

fairplay_decrypt ret = 0
16 byte aeskey (fairplay-decrypted from ekey):
81 4b 65 e5 6a a0 4d 7a 92 ce 49 2c 94 37 81 7b 

32 byte shared ecdh_secret:
08 2e 7e ab 6c 73 ac 01 68 e5 de d9 76 bc 81 6e 
a6 62 7f 56 2a 80 c5 70 d5 9d ad f5 14 09 42 79 

Client identified as User-Agent: AirPlay/425.1
16 byte aeskey after sha-256 hash with ecdh_secret:
8c 17 37 3a fe 7d d8 72 85 2f 40 14 23 22 22 8d 

timing_rport = 58508                 <=================uxplay knows the client's timingPort
raop_ntp parse remote ip = 192.168.2.144
raop_ntp starting time
raop_ntp local timing port socket 21 port UDP 7011
raop_rtp parse remote ip = 192.168.2.144
raop_rtp_mirror parse remote ip = 192.168.2.144
eport = 7000, tport = 7011

RTSP/1.0 200 OK 
CSeq: 6 
Server: AirTunes/220.68 
Content-Type: application/x-apple-binary-plist 
Content-Length: 77 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>timingPort</key>
        <integer>7011</integer>
        <key>eventPort</key>
        <integer>7000</integer>
</dict>
</plist>

raop_ntp send_len = 32, now = 1670858932893768              <===== sending timing signal request to client
raop_ntp receive time type_t=83 packetlen = 32                 <====== got it
80 d3 00 07 00 00 00 00 e7 41 c7 34 e4 cd fa ca 
83 aa ae 88 d2 fd c9 eb 83 aa ae 88 d3 00 0b 6c 

raop_ntp sync correction = -1670846636070299
fduncanh commented 1 year ago

Since you have got it working with different audio settings (?) your MacBook Air M1 running Ventura 13.0.1 apparently can use the NTP timing protocol. please post a debug log where it works. Maybe one can see why it it is not doing NTP timingProtocol with the settings you want. Maybe uxplay is telling it something wrong earlier, so it switches off NTP?

fduncanh commented 1 year ago

Please confirm you can get your MacBook AIr working with uxplay with some settings, and post debug log showing a working session starting.

koaie commented 1 year ago

Yes, by changing the global audio setting as shown here: image here is the debug setting: working_debug.txt

fduncanh commented 1 year ago

OK, it works fine. Need to find out why non-working case triggers the "isRemoteControlOnly" key on the client


SETUP rtsp://10.0.0.9/15514617994187589535 RTSP/1.0
Content-Length: 519
Content-Type: application/x-apple-binary-plist
CSeq: 6
DACP-ID: 4EF300EADFB6257A
Active-Remote: 4247021636
User-Agent: AirPlay/665.13.1  <============from client

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>et</key>
    <integer>32</integer>
    <key>eiv</key>
    <data>
    2oJm45sgyaU7Z5PezrMGCQ==
    </data>
    <key>statsCollectionEnabled</key>
    <false/>
    <key>sessionUUID</key>
    <string>D74EFEDD-A16F-479F-9D04-30669EF4B0AD</string>
    <key>timingProtocol</key>
    <string>NTP</string>                 <==================GOOD!
    <key>osName</key>
    <string>macOS</string>
    <key>osBuildVersion</key>
    <string>22A400</string>
    <key>sourceVersion</key>
    <string>665.13.1</string>
    <key>timingPort</key>
    <integer>55053</integer>   <========remote timing port used by client
    <key>osVersion</key>
    <string>13.0.1</string>
    <key>ekey</key>
    <data>
    RlBMWQECAQAAAAA8AAAAAPU8CY7ij/GUzaOom3q7C+MAAAAQfWn8zV/BBYGHNxPE75JE
    mCCMWq/C+vG2UMNgIis+rKcLxEel
    </data>
    <key>deviceID</key>
    <string>A4:C6:F0:0B:72:39</string>
    <key>model</key>
    <string>MacBookAir10,1</string>
    <key>name</key>
    <string>koie</string>
    <key>macAddress</key>
    <string>A4:C6:F0:0B:72:39</string>
</dict>
</plist>

Handling request SETUP with URL rtsp://10.0.0.9/15514617994187589535
DACP-ID: 4EF300EADFB6257A
Active-Remote: 4247021636
Transport: null
SETUP 1
eiv_len = 16
16 byte aesiv (needed for AES-CBC audio decryption iv):
da 82 66 e3 9b 20 c9 a5 3b 67 93 de ce b3 06 09 

ekey_len = 72
ekey:
46 50 4c 59 01 02 01 00 00 00 00 3c 00 00 00 00 
f5 3c 09 8e e2 8f f1 94 cd a3 a8 9b 7a bb 0b e3 
00 00 00 10 7d 69 fc cd 5f c1 05 81 87 37 13 c4 
ef 92 44 98 20 8c 5a af c2 fa f1 b6 50 c3 60 22 
2b 3e ac a7 0b c4 47 a5 

fairplay_decrypt ret = 0
16 byte aeskey (fairplay-decrypted from ekey):
23 bd 77 e8 87 24 93 3a cd bc 9e f9 68 a0 6b 6e 

32 byte shared ecdh_secret:
40 b7 f4 e4 6b 81 60 85 22 35 6f 9b 24 46 08 60 
86 bb 2e 47 48 9b 0b 49 81 7b 3d 8d 1f 7e 5a 08 

Client identified as User-Agent: AirPlay/665.13.1
16 byte aeskey after sha-256 hash with ecdh_secret:
6d 51 b2 7e c0 05 7c 63 f7 e0 ab a3 70 a1 8c 5d 

timing_rport = 55053     <=======uxplay knows client's timing port
raop_ntp parse remote ip = 10.0.0.240
raop_ntp starting time
raop_ntp local timing port socket 21 port UDP 50137
raop_rtp parse remote ip = 10.0.0.240
raop_rtp_mirror parse remote ip = 10.0.0.240
eport = 34343, tport = 50137

RTSP/1.0 200 OK 
CSeq: 6 
Server: AirTunes/220.68 
Content-Type: application/x-apple-binary-plist 
Content-Length: 77 

raop_ntp send_len = 32, now = 1670862524033315    <= uxplay requested NTP time signal from client
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>timingPort</key>
    <integer>50137</integer>
    <key>eventPort</key>
    <integer>34343</integer>
</dict>
</plist>

raop_ntp receive time type_t=83 packetlen = 32    <====uxplay received NTP time signal from client
80 d3 00 07 00 00 00 00 e7 41 d5 3c 08 87 54 f3 
83 ac 17 19 b0 35 f2 71 83 ac 17 19 b0 3b b4 0b 

raop_ntp sync correction = -1670757922347445    <= synchronization occured
Accepted IPv4 client on socket 22
fduncanh commented 1 year ago

investigate the linux "Sound Settings", maybe something to do with RemoteControl is set for "ice" you have debian 11.5.

I have a debian "testing" ( bookworm/sid) setup available , but not a bullseye 11.5

EDIT my debian setup uses KDE, and does not have a sound settings system anything like yours. what is it, Gnome?

fduncanh commented 1 year ago

the isRemoteControlOnly setting would seem to switch off NTP signalling on the client

fduncanh commented 1 year ago

once you get it working with -vs 0, you will need to use uxplay-1.59 (not yet released) from github.

koaie commented 1 year ago

investigate the linux "Sound Settings", maybe something to do with RemoteControl is set for "ice" you have debian 11.5.

I have a debian "testing" ( bookworm/sid) setup available , but not a bullseye 11.5

EDIT my debian setup uses KDE, and does not have a sound settings system anything like yours. what is it, Gnome?

hey that sound setting is from my macbook, no settings were touched on the debian machine.

fduncanh commented 1 year ago

On Catalina, I don't see anything like that in System Preferences->Sound. I have no idea how it works on Ventura.

It seems your issue is not directly a UxPlay issue. Somewhere the setting "ice" is setting the "isRemoteControlOnly" setting on the Mac, and that is somehow disabling the NTP timingProtocol. If this isn't in reponse to anything sent by uxplay, its not a uxplay issue.

once you get things working, to use -vs 0, you will need to use uxplay-1.59 (not yet released) from github.Since your working debug shows no video, I'm guessing you are using -vs 0 with uxplay-1.59. (I guess should have the initial terminal output print the UxPlay version)

koaie commented 1 year ago

On Catalina, I don't see anything like that in System Preferences->Sound. I have no idea how it works on Ventura.

It seems your issue is not directly a UxPlay issue. Somewhere the setting "ice" is setting the "isRemoteControlOnly" setting on the Mac, and that is somehow disabling the NTP timingProtocol. If this isn't in reponse to anything sent by uxplay, its not a uxplay issue.

once you get things working, to use -vs 0, you will need to use uxplay-1.59 (not yet released) from github.Since your working debug shows no video, I'm guessing you are using -vs 0 with uxplay-1.59. (I guess should have the initial terminal output print the UxPlay version)

What could cause "isRemoteControlOnly" to be set? and I wonder if "isRemoteControlOnly" could be set by safari? the only change i did to get it to work was on the mac (client), which implies it's a uxplay/macos/safari problem. as no settings were changed on the debian machine. Especially because there is a difference between using youtube and global audio setting to interact with uxplay.

fduncanh commented 1 year ago

The isRemoteControlOnly setting will be in some plist settings file somewhere on the Mac.

How did you create the "ice" entry on the Mac Sound Settings?
is this using System Preferences or something in Youtube or Safari?

It may be something that is not in Catalina, since updated Airplay2 was added to Macs after Catalina, and I don't have a post-Catalina Mac to test things on right now.

Try creating a new setting like "ice" (e.g. "icetest") from scratch , and keep a note of what exactly you did.

fduncanh commented 1 year ago

It cannot be a UxPlay issue, since all that happens before the Macbook sends its details (with the isRemoteControlOnly setting in the non-working case) is that the Macbook announces itself, then uxplay send its own plist settings , and the pairing exchange involving cryptography takes place. uxplay send the same plist data to the client in both the working and non-working cases, so whatever tells the Mac that it is operating with "isRemoteControlOnly" (and placed this in the plist settings on the mac) is something that was configured into the "ice" audio settings.

Somewhere, there will be a plist file with the "ice" settings. There is a plist editor on macOS that can change plist files directly. Look in ~/Library to try and find the appropriate plist file

in mac terminal

find ~/Library/ -name  "*.plist"  -exec ls  -l  {}  \; | grep 2022 | grep Dec

might help you find recently changed plist files. (use grep -e "Dec 12" for changes made today; make sure you use your Mac's "ls" date format if it is different from above)

google for how to use a plist editor on macOS to look at /change plist files

fduncanh commented 1 year ago

I noticed your "ice" icon is "Apple TV". Maybe because you specify apple TV it might by default have selected the isRemoteControlOnly setting.

This isnt a uxplay issue that can be solved in uxplay code, so I'll close it.

If you add any more info, I'll try to help or make a suggestion. Your best bet is to identify the plist file for "ice" settings and maybe change that isRemoteControlOnly setting there .

https://support.apple.com/guide/terminal/edit-property-lists-apda49a1bb2-577e-4721-8f25-ffc0836f6997/mac https://formac.informer.com/plist-editor https://macdownload.informer.com/prefs-editor/ https://apps.apple.com/us/app/plist-editor/id1157491961?mt=12

koaie commented 1 year ago

Ice is not created on the macos, it's detected automatically the hostname is removed from showing using the argument "-nh -n ice", I have ran the command you sent and it returns empty. So to recreate it the command "uxplay -avdec -nh -n ice -vs 0 -as pulsesink -d" is used.

from what i can tell from https://pyatv.dev/documentation/protocols/ and https://github.com/openairplay/airplay2-receiver isRemoteControlOnly is a session type, which seems to be part of airplay2. Is support for audio airplay2 planned?

fduncanh commented 1 year ago

I see from the pyatv doc that RemoteControl is an AirPlay2 protocol that UxPlay does not support. We are doing Airplay v1 "legacy" protocols, and need isRemoteControlOnly to be set to "false".

As described in the AirPlay v1 section of the pyatv doc,

<h4 id="setup">SETUP</h4>

<p>Sender requests initialization of a (Airplay v1) session (but does not start it).
 Sets up three different UDP channels:</p>

Channel | Description
-- | --
server | audio
control | sync and retransmission of lost frames
timing | sync of common master clock

Your mac must provide the AirPlay v1 timing channel for UxPlay to work.

Unless someone new forks UxPlay and manages to get any of these Airplay v2 features into it, it won't happen, I'm afraid. Its main task is mirroring ipads, macs, etc. audio only is just an extra. The main missing feature is AirPlay v2 video-streaming which require a better understanding of Apple's encryption. Maybe the people working on pyatv will find how to do this, the protocol document seems to have advanced since I last looked at it.

fduncanh commented 1 year ago

In any case, you are able to get UxPlay to work, just not the way you want, I guess.

fduncanh commented 1 year ago

Here is some documentation of "features" codes. https://emanuelecozzi.net/docs/airplay2/features/ https://openairplay.github.io/airplay-spec/features.html

The two "features" bits are set in lib/dnssdint.h

possible making a change to them will stop the client using the "Remote Control" session protocol.

#define FEATURES_1 "0x5A7FFEE6" /* first 32 bits of features */
#define FEATURES_2 "0x0"        /* second 32 bits of features */
#define RAOP_FT FEATURES_1 "," FEATURES_2
/* use same features for RAOP and AIRPLAY: is this correct? */
#define AIRPLAY_FEATURES_1 FEATURES_1
#define AIRPLAY_FEATURES_2 FEATURES_2
#define AIRPLAY_FEATURES  AIRPLAY_FEATURES_1 "," AIRPLAY_FEATURES_2

0x5A7FFEE6 = 0101 1010 0111 1111 1111 1110 1110 0110 5 A 7 F F E E 6

bit value (right to left)
0:  0 Video | video supported   no
1:  1 Photo | photo supported  yes
2:  1 VideoFairPlay | video protected with FairPlay DRM
3:  0 VideoVolumeControl | volume control supported for videos

4:  0 VideoHTTPLiveStreams | http live streaming supported
5:  1 Slideshow | slideshow supported
6:  1
7:  1 Screen | mirroring supported

8:  0 ScreenRotate | screen rotation supported
9:  1 Audio | audio supported
10: 1
11: 1 AudioRedundant | audio packet redundancy supported

12 :1 FPSAPv2pt5_AES_GCM | FairPlay secure auth supported
13: 1 PhotoCaching | photo preloading supported
14: 1 Authentication4 | Authentication type 4. FairPlay authentication
15: 1 MetadataFeature1 | bit 1 of MetadataFeatures. Artwork.

16: 1 MetadataFeature2 | bit 2 of MetadataFeatures. Progress.
17: 1 MetadataFeature0 | bit 0 of MetadataFeatures. Text.
18: 1 AudioFormat1 | support for audio format 1
19: 1 AudioFormat2 | support for audio format 2. This bit must be set for AirPlay 2 connection to work

20: 1 AudioFormat3 | support for audio format 3. This bit must be set for AirPlay 2 connection to work
21: 1 AudioFormat4 | support for audio format 4
22: 1
23: 0 Authentication type 1. RSA Authentication

24: 0
25: 1
26: 0 HasUnifiedAdvertiserInfo
27: 1 SupportsLegacyPairing    

28: 1
29: 0
30: 1 RAOP | RAOP is supported on this port. With this bit set your don't need the AirTunes service
31: 0

32-63: 0
fduncanh commented 1 year ago

@koaie Maybe experiment with switching off bits 19 and 20 (to see if the client stops using AirPlay 2)
so FEATURES_1 in lib/dnssdint.h is defined as 0x5A67FEE6 (instead of 0x5A7FFEE6 )