search

FD- / RPiPlay

An open-source AirPlay mirroring server for the Raspberry Pi. Supports iOS 9 and up.
GNU General Public License v3.0
4.97k stars 354 forks source link

Casting audio only doesn't work #2

Open Wonderwuzi2000 opened 5 years ago

Wonderwuzi2000 commented 5 years ago

Whenever i try to play locally stored music on my iPad with the music app via Airplay to my TV i get no sound.

Could you please point me to the right direction - any help would be appreciated !!!

The details: iPad 6th Generation, 32 GB, iOS 12.4 Raspberry Pi 3+, Raspbian Buster - Patchlevel as of July 27th 2019 RPiPlay v 1.1 - with edited raop_rtp_mirror.c as stated on https://github.com/FD-/RPiPlay/issues/1 logfile.txt

FD- commented 5 years ago
  1. I don't see the AAC decoder error you mentioned earlier in the log file you attached now.
  2. How are you connecting to the AirPlay device? Via the dedicated mirroring button in control center or via the radio-like AirPlay button in the playback area in control center?
  3. Does a reboot of the iPad help?
Wonderwuzi2000 commented 5 years ago

The first way (the dedicated mirroring button) works fine - so picture and sound work well.

But the second way you mention (via the radio-like Air Play button) is - in my case - not working at all.

If you start rpiplay with the debug option -d the console looks like in the file logfile1.txt If you start rpiplay without the debug option -d the console looks like in the file logfile2.txt

A restart of the airpad did not help.

Funny - when picture and sound are transmitted together everything works OK. But when only sound is transmitted the problem starts.

logfile1.txt logfile2.txt

FD- commented 5 years ago

I see. This is not a bug. RPiPlay is an AirPlay mirroring server and doesn't support the distinct AirPlay audio and AirPlay video protocols that are also part of the AirPlay protocol suite. AFAICT, AirPlay audio uses a different audio codec (ALAC) than AirPlay mirroring (AAC), so that's why you saw the audio decoder error messages.

Adding support for the audio-only protocol should be pretty easy, since RPiPlay is derived from the audio-only Shairplay project, which can be used as a reference. It basically should just be a matter of finding the header field in the protocol that indicates the audio format, passing that to the audio renderer and decode it there, using the same ALAC library as Shairplay.

However, since I only need the mirroring functionality (and other AirPlay audio implementations already exist), I won't invest my time to add this functionality. Nevertheless, I'd gladly see someone step in and submit a pull request.

I'll leave this issue open for the case that someone wants to discuss how such a PR would work.

VHBrent commented 3 years ago

Is someone working on this? Or can someone tell me where the program knows the used codec so that I or someone else, can try to add this function?

fduncanh commented 3 years ago

The problem with ALAC (apple audio-only lossless streaming) is solved in issue #283, It was a bug in the AES-CTR decryption in RPiPlay that had little effect in AAC streams (so the corruption was not noticed before) , but was fatal for ALAC. It is solved by merely adding "+ 15" to a line of code. I have now added ALAC support to the RPiPlay fork (GStreamer only) http://github.com/FDH2/UxPlay. It would be now be trivial to add non-gstreamer ALAC support to RPiPlay by adding Alac.c and Alac.h from shairplay, and using the ALACSpecificData (Apple magic cookie) you can find in UxPlay 1.39 renderers/audio_renderer_gstreamer.c

apbarratt commented 2 years ago

I've encountered this issue myself having installed everything today. Glad to see a solution has been found and one of us can get to it when we find time and skill to do so. In the mean time though, could a try catch be put into the relevant place to just pop up with a quicky error linking to this issue in the console output rather than endless errors which ultimately seem to block the termination of the process without restarting the Pi from another session? :)

fduncanh commented 2 years ago

If someone wants to add ALAC support to RPiPlay, (or disconnect the client if ALAC is detected) the first byte of decrypted ALAC packets is 0x20, while that of AAC-ELD packets is 0x8[c,d,e] or (for ancient 32-bit iOS devices 0x8[0,1,2]).

UxPlay (with ALAC support) now also supports Raspberry Pi with Video4linux2 instead of OpenOMX for hardware video decoding.