Alpine linux: Connection works with iPhone, but not with Macbook (M2 Max, macOS 14)

[wenerme]

Soory to open this, I found this https://github.com/FDH2/UxPlay/issues/73 , but already using uxplay build from master source, I don't know where to look at.

gst.log uxplay.log

started by

uxplay -n "tv@rad-office" -nh -fps 18 -fs -vs ximagesink

[fduncanh]

your uxplay.log shows raop_rtp_mirror starting mirroring raop_rtp_mirror local data port socket 27 port TCP 36903 Mirroring initialized successfully

But no video data from client ever seems to arrive at TCP port 36903.

UxPlay is tested on OSX )with M2 Max, and works correctly. So far, I have no idea what is wrong with your linux system (or maybe OS X)

try the -p option to use fixed data ports.

Can you test with some more standard linux (e.g arch or ubuntu) on standard hardware to rule out some alpine-specific issue.

• ====================================== This is what correct behavior should be:

  
  Mirroring initialized successfully

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

<?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">

streams dataPort 7100 type 110

httpd receiving on socket 24 conn_request

SET_PARAMETER rtsp://192.168.1.6/10952456368813525176 RTSP/1.0 Content-Length: 20 Content-Type: text/parameters CSeq: 8 DACP-ID: 6DB695A11C64DAF3 Active-Remote: 2045431899 User-Agent: AirPlay/690.7.1

volume: -20.000000

Handling request SET_PARAMETER with URL rtsp://192.168.1.6/10952456368813525176

RTSP/1.0 200 OK CSeq: 8 Server: AirTunes/220.68

raop_rtp_mirror accepting client

Received unencryted codec packet from client: payload_size 37 header 01 00 16 01 ts_client = 105495.817923 raop_rtp_mirror: unidentified extra header data 240.000000, 0.000000 begin video stream wxh = 1440x1080; source 1440x1080 raop_rtp_mirror width_source = 1440.000000 height_source = 1080.000000 width = 1440.000000 height = 1080.000000 raop_rtp_mirror: SPS+PPS header size = 6 raop_rtp_mirror h264 SPS+PPS header: 01 64 00 28 ff e1

raop_rtp_mirror SPS NAL size = 18 raop_rtp_mirror h264 Sequence Parameter Set: 27 64 00 28 ac 13 14 50 16 80 89 f9 66 e0 20 20 20 40

raop_rtp_mirror PPS NAL size = 4 raop_rtp_mirror h264 Picture Parameter Set: 28 ee 3c b0

remainder size = 4 remainder of SPS+PPS packet: 02 00 00 00

raop_rtp video: now = 1686755908.969296, ntp = 1686755909.010221, latency = -0.040926, ts = 105495.817923, 00 10 00 00 Begin streaming to GStreamer video pipeline Looking for X11 UxPlay Window, attempt 1 raop_rtp video: now = 1686755908.996586, ntp = 1686755909.060171, latency = -0.063584, ts = 105495.867872, 00 00 00 00 Looking for X11 UxPlay Window, attempt 2

*** X11 Windows: Use key F11 or (left Alt)+Enter to toggle full-screen mode

raop_rtp video: now = 1686755909.131488, ntp = 1686755909.093482, latency = 0.038006, ts = 105495.901183, 00 00 00 00 raop_rtp video: now = 1686755909.131524, ntp = 1686755909.126795, latency = 0.004729, ts = 105495.934496, 00 00 00 00 raop_rtp video: now = 1686755909.131562, ntp = 1686755909.176765, latency = -0.045203, ts = 105495.984466, 00 00 00 00 raop_rtp video: now = 1686755909.163448, ntp = 1686755909.226733, latency = -0.063286, ts = 105496.034434, 00 00 00 00 raop_rtp video: now = 1686755909.213604, ntp = 1686755909.276702, latency = -0.063098, ts = 105496.084403, 00 00 00

[fduncanh]

maybe the -fps18 is the issue? try without this option.

[wenerme]

Thanks, Yes，-fps18 is the problem, 😭 . Should I close this or wait to solve this ?

[fduncanh]

-fps 18 tells the client that the server will not accept video at a rate greater than 18fps.

It seems that your macOS M2 client system refuses to send any video at that slow rate. The default is 30fps.

[fduncanh]

We will try to test alpine linux,,but not before next week. what processor architecture ?
raspberry pi 4b or 5 is available, or is the target intel/amd 64bit

[wenerme]

@fduncanh Thanks, I use alpine on amd64 as host. UxPlay feels lag so I want to try lower fps, uxplay works like stop a will then works again.

https://github.com/FDH2/UxPlay/assets/1777211/86e3b1c5-8478-48b3-b198-ae745e87b769

[fduncanh]

uxplay should work without lags on amd64.

Is alpine linux "friendly" in a multi-boot (multi-linux) setup (i.e. won't destroy other linux installations - this is a grub2 issue)? Is a virtualbox installation OK for testing your issues?

How much memory does your amd-64 system have. how old is it (describe it more)

there appear to be various modes

1. diskless mode
2. data disk mode
3. system disk mode

which one is giving you problems?

[wenerme]

uxplay should work without lags on amd64.

Is alpine linux "friendly" in a multi-boot (multi-linux) setup (i.e. won't destroy other linux installations - this is a grub2 issue)? Is a virtualbox installation OK for testing your issues?

How much memory does your amd-64 system have. how old is it (describe it more)

there appear to be various modes

1. diskless mode
2. data disk mode
3. system disk mode

which one is giving you problems?

Thanks.

I use sys mode, no multi-boot (all my server are alpine), here is the neofetch output

OS: Alpine Linux v3.19 x86_64
Kernel: 6.6.9-0-lts
Uptime: 1 day, 23 hours, 28 mins
Packages: 125 (apk)
Shell: bash 5.2.21
Terminal: /dev/pts/0
CPU: Intel Pentium 4405U (4) @ 2.100GHz
Memory: 102MiB / 15923MiB

[fduncanh]

we installed an alpine linux 3.19 test installation (sys mode on x86_64), with kde.

running "uxplay -vs xvimagesink" (in an X11 session) triggers something (in gstreamer?) that causes PAM to immediately shutdown sddm, and terminate the user session.

/var/log/messages shows:

Jan 18 15:20:05 [host] user.notice libddcutil[3617]: libddcutil terminating.
Jan 18 15:20:05 [host] user.err pulseaudio[3700]: [pulseaudio] stdin-util.c: Lost I/O connection in module "module-gsettings"
Jan 18 15:20:05 [host] authpriv.info : pam_unix(sddm:session): session closed for user 

"uxplay" by itself also does this, probably because xvimagesink is the default choice made by "autovideosink".

-vs ximagesink and -vs glimagesink work.

In a wayland session this also does not occur (presumably autovideosink chooses waylandsink)

Another alpine SDDM weirdness (which apparently a KDE known bug in a prerelease version of SDDM, also reported in Arch Linux) is that the regular "enter" key is not recognized on the login screen, only the numeric keypad "enter" is. https://github.com/sddm/sddm/issues/1824