search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2.07k stars 236 forks source link

support Measy A2W/renkcast #60

Open lollul opened 9 years ago

lollul commented 9 years ago

I'm trying to use forked-daapd (latest source using openwrt trunk) with Measy A2W/renkcast/EZCast device which is supposed to work as airplay speakers. (android Retune is used as controller). I'm not able to get any sound from it although EZCast device is 'visible' as speaker in Retune, shows artwork and volume level on its HDMI output. BTW My setup works with shairport as a speaker.

forked-daapd log shows (hope I'm able to show relevant parts): mdns: Service 46334C35CCD9@EZCastmsy-4C35CCD9, hostname EZCastmsy-4C35CCD9.local resolved to 192.168.0.163 player: Event for AirPlay device 46334c35ccd9/EZCastmsy-4C35CCD9 (47000) player: AirPlay device 46334C35CCD9@EZCastmsy-4C35CCD9: password: 0, encrypt: 0, metadata: 1, type AppleTV [...] xcode: Determining transcoding status for codectype mpeg xcode: User-Agent: RetuneAndroid xcode: Could not identify client, using default codectype set xcode: Codectype supported by client, no transcoding needed [...] raop: ApEx EZCastmsy-4C35CCD9 closed RTSP connection raop: Cleaning up failed session (deferred) on device EZCastmsy-4C35CCD9 player: AirPlay device EZCastmsy-4C35CCD9 FAILED

My guess is it is EZCast software issue...but maybe it is possible to tweak in forked-daapd how it is treated... e.g. can we make demote EZCast to be 'Airport Express' device? Appreciate any help!

lollul commented 9 years ago

avahi is telling me: enp2s0 IPv4 EZCastmsy-4C35CCD9 _airplay._tcp local hostname = [EZCastmsy-4C35CCD9.local] address = [192.168.0.163] port = [7000] txt = ["pw=0" "srcvers=150.33" "model=AppleTV3,1" "rmodel=EZAir1,1" "features=0x100029ff" "deviceid=46:33:4C:35:CC:D9"] I'll try to play with devtype in player.c

lollul commented 9 years ago

changing devtype didn't help. I'm not sure what else I should try... Forcing transcoding/disabling transcoding seem to have no effect - transcoding is done anyway. The device works fine with iTunes server on windows (I see iTunes is sending the same amounts of data to EZCast as it sends to a shairport client). Would it help to catch the network traffic between iTunes and EZCast?

ejurgensen commented 9 years ago

Very good troubleshooting effort! The output from Avahi seems to point at some problems. There is no tp field (transfer protocol, should be part of the txt field), which means either the device does not support AirPlay v2, or it just doesn't announce it. You should be seeing a message in the log about this?

The other problem would be the "pw=0" (no password), which forked-daapd interprets as password enabled, because other devices announce "pw=false".

I made a quick fix for these two issues, which you can try here: https://github.com/ejurgensen/forked-daapd/tree/ezcast

Let me know if it works. If it doesn't I have a few other suggestions.

ejurgensen commented 9 years ago

Oh just saw this part of your message: "AirPlay device 46334C35CCD9@EZCastmsy-4C35CCD9: password: 0, encrypt: 0, metadata: 1, type AppleTV"

Guess that means it is actually detected as it should? I really don't understand how that is possible given the txt field you posted.

And yes, forked-daapd will always transcode to pcm, but that should hopefully not be a problem for the device.

lollul commented 9 years ago

Thank you for your prompt reply! I'm afraid it didn't help. Here is a full log: http://pastebin.com/w5UsbciM I could run a wireshark trace of itunes connection if this could help... (BTW I've patched the source manually. I've tried to set up openwrt compilation like here https://forum.openwrt.org/viewtopic.php?pid=215402#p215402 but configure broke telling me antlr3 can't be found. So much to learn! :) )

ejurgensen commented 9 years ago

I noticed that the missing fields in the txt field are because you got the wrong announcement from Avahi. You got for _airplay._tcp, but you need to get for _raop._tcp. Use this command: "avahi-browse -r -k _raop._tcp". What does that give you?

You could also try turning encryption on, just to see if that does the trick. You can force encryption by setting the device to RAOP_DEV_APEX2_80211N in player.c.

Wireshark is certainly an option, but not an easy one, since it is hard to parse the stream.

Another option is to try and see if the Pulseaudio Raop sink (http://hfujita.github.io/pulseaudio-raop2/) works with your device. If it does, it might be possible to narrow down the culprit, since it is also open source. I'll admit that I've never tried the Pulseaudio AirPlay solution, and I don't know the state of it.

About building: If you use the OpenWrt Makefiles and patches from GitHub you should not see the antlr3 error. There is a patch for that. However, if you have the option of building and troubleshooting natively on a Linux pc, I would recommend that.

BTW I can see from your log that you have the database inside your media library. I wouldn't recommend that, it means the filescanner is constantly being triggered.

lollul commented 9 years ago

Thanks for the tip about antrlr3 - now I realize there is a special patch for openwrt Tried setting it to RAOP_DEV_APEX2_80211N - didn't work: http://pastebin.com/TcmtsBh8 I've tried with pulseaudio-raop2 - it doesn't even make the device 'switch' to audio output (no artwork, volume control etc). Here is the log: http://pastebin.com/FUrHQ4hs Sorry about avahi output. Here it is: enp2s0 IPv4 46334C35CCD9@EZCastmsy-4C35CCD9 _raop._tcp local
hostname = [EZCastmsy-4C35CCD9.local]
address = [192.168.0.163] port = [47000] txt = ["sf=0x4" "am=AppleTV3,1" "rmodel=EZAir1,1" "vs=150.33" "vn=65537" "tp=UDP" "ss=16" "sr=44100" "sv=false" "pw=false" "md=0,1,2" "et=0,3,5" "da=true" "cn=0,1,2,3" "ch=2" "txtvers=1"]

ejurgensen commented 9 years ago

The avahi output looks normal to me, and I don't see any hints about what the problem might be. So I guess that leaves Wireshark...

lollul commented 9 years ago

This is current iTunes version connecting to EZCast installed on win xp (on a virtual machine: http://wikisend.com/download/176164/itunes_ezcast.pcapng.gz What is surprising to me is that forked-daapd is somehow able to 'connect' to EZCast - I mean it switches to 'Airplay' mode, shows artwork and accepts volume control commands. Just no audio... While pulseaudio-raop2 is not making any visible change on EZCast screen.

lollul commented 9 years ago

maybe relevant... I believe this means iTunes is announcing it will be sending data with AES encryption: ANNOUNCE rtsp://192.168.0.107/3497680159 RTSP/1.0 CSeq: 3 Content-Type: application/sdp Content-Length: 325 User-Agent: iTunes/12.0.1 (Windows; Microsoft Windows XP Professional Dodatek Service Pack 3 (Build 2600)) Client-Instance: CEA1B29DE0AF7248 DACP-ID: CEA1B29DE0AF7248 Active-Remote: 739668222

v=0 o=iTunes 3497680159 0 IN IP4 192.168.0.107 s=iTunes c=IN IP4 192.168.0.163 t=0 0 m=audio 0 RTP/AVP 96 a=rtpmap:96 AppleLossless a=fmtp:96 352 0 16 40 10 14 2 255 0 0 44100 a=fpaeskey:RlBMWQECAQAAAAA8AAAAAPFIMw/fVfud2wlB/RxFhacAAAAQKQkEjwAvZ1kJBEmsr5ajtlKnruiIWFpZJFTGtYkIdUeqYvTp a=aesiv:EXwUUMC5vek2dVEuhl5d8Q

RTSP/1.0 200 OK Audio-Jack-Status: connected; type=analog Server: AirTunes/150.33 CSeq: 3

...and EZCast was saying et="0,3,5" meaning no encryption or FairPlay encryption is supported. I guess I should try harder forcing AES encryption...

ejurgensen commented 9 years ago

If you didn't already, maybe try this: https://github.com/ejurgensen/forked-daapd/commit/1e5e4d4233c1a67dba0c3ee57eeaa8f71f405524

Just a shot...

lollul commented 9 years ago

Still no sound. Here is a packet capture: http://wikisend.com/download/670266/forked_daapd-ezcast.pcapng.gz I've also tried to set the user-agent to be identical to iTunes string - no change.

lollul commented 9 years ago

Looking at the iTunes-EZCast TCP stream I see POST /fp-setup commands starting with FPLY. This would be a FairPlay key exchange I guess. Checking on the net it doesn't look like FairPlay has been cracked and I doubt EZCast engineers have cracked it or bought a license from Apple... but the key exchange certainly looks different on each connection.

ejurgensen commented 9 years ago

I've had a glance at your traffic dumps to see if I could spot anything suspicious. I noticed the Fairplay transactions too, but I agree with you that it seems like an unlikely cause. Other than that, I'm sorry to say I didn't find any clues.

Have you considered submitting the problem to the EZcast people? There is probably not much chance that they will look into it, but who knows.

lollul commented 9 years ago

I did report to EZCast: http://forum.iezvu.com/bbs-en/viewtopic.php?f=2&t=6687&sid=f1e7d4cc05b8b040760dcefe974d2dfd I can only help they will look into it. Its a shame as at ~10Eur it is a cheapest solution to connect my music library on openwrt router with my hdmi-capable amplifier.

I found a report describing how to connect to an UART interface on this device. Maybe with root access I could find out what software they are using. Most likely they use open source code and they managed to cripple it somehow :)

At least DLNA works on this device. I shall take a look at making MPD output to a DLNA receiver... or do you think forked-daap could work with upnp/dlna in the furture?

ejurgensen commented 9 years ago

I haven't got any plans in regards to DLNA, I'm thinking there are already plenty of DLNA servers out there? I guess the added value forked-daapd could offer is support for AirPlay and DLNA targets at the same time - is that what you mean?

lollul commented 9 years ago

Please don't take my request seriously....I'm sure there are more important features. But yes, in my setup I have one openwrt router which acts as a server, another router with usb audio card (where I don't care that much about sound quality). This part works with mpd and pulseaudio network module. Now I wanted to have music in another room but to have digital signal provided to the amplifier (which supports hdmi/spdif etc). I figured since the amplifier has probably a good DAC then let's use it. This is what EZCast was supposed to solve. I would love to have just one server with the content...either forked-daapd, mpd or minidlna.

andyjenkinson commented 9 years ago

Just wanted to say - in actual fact I plan to do what is described above - i.e. have forked-daapd send audio to DLNA renderers as well as AirPlay devices. I have lots of streaming targets in my house - some support AirPlay, some support DLNA, few support both.

However before you think about implementing DLNA renderers in forked-daapd, consider the different ways of doing this, as there are implications of each:

Personally I think the last option is the most flexible. There is no reason why proxies could not be run on the same server that forked-daapd is running on, which would be nearly as good when piping from forked-daapd but will also provide an AirPlay target for iPhones etc.