Delayed audio output with apple music

[r10r]

What version of Music Assistant has the issue?

2.4.0b16

What version of the Home Assistant Integration have you got installed?

No response

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• Yes

The problem

Audio output is delayed when music provider is apple music. The track is playing but there is no audio output for some time (often 5s to 30s).
This happens when the first track is played, after skipping to the next track and after seeking.

How to reproduce

Play files from apple music.

Music Providers

The music provider is apple music.

When playing local files the playbacks starts immediately.

Player Providers

The player provider is airplay (shairport-sync)

Full log output

music-assisant-log.txt

Additional information

No response

What version of Home Assistant Core are your running

2025.1.2

What type of installation are you running?

Home Assistant OS

Container (podman)

On what type of hardware are you running?

Raspberry Pi

Dell Optiplex 7040 Micro ( Intel(R) Core(TM) i5-6500T CPU )

[OzGav]

Include the log as per the issue template. When did this start happening? If after an update have you rolled back and confirmed it doesn’t occur?

[r10r]

Hi @OzGav,

thanks for your quick response. I've updated the issue request accordingly.
I'm new to music-assistant and I have tried the following versions:

• 2.2.2
• 2.4.0
• 2.4.0b14
• 2.4.0b15
• 2.4.0b16

The issue is always the same.

The log does not show anything relevant to me. How can I enable debug logging ?

Is there a way to test playback from cmdline with ffmpeg and cliraop-linux-x86_64 ?
I can see the following process in the container, but I do not know how to setup the pipeline
and how to obtain the encryption key for apple music.

ffmpeg -hide_banner -loglevel error -nostats -ignore_unknown -protocol_whitelist file,hls,http,https,tcp,tls,crypto,pipe,data,fd,rtp,udp -ac 2 -channel_layout stereo -ar 44100 -acodec pcm_f32le -f f32le -i - -af alimiter=limit=-2dB:level=false:asc=true,aresample=resampler=soxr:precision=30:osf=s16:dither_method=triangular_hp -acodec pcm_s16le -f s16le -ar 44100 -ac 2 -

/app/venv/lib/python3.12/site-packages/music_assistant/providers/airplay/bin/cliraop-linux-x86_64 -ntpstart 7460792441373850498 -port 5000 -wait 1750 -latency 1000 -volume 14 -if 10.0.9.50 -alac -et 0,1 -md 0,1,2 -am ShairportSync -pw false -dacp FE08AF41130674AB -activeremote 3001 -udn C18761ABB159@Dach._raop._tcp.local. 10.0.9.43 

ffmpeg -hide_banner -loglevel info -nostats -ignore_unknown -protocol_whitelist file,hls,http,https,tcp,tls,crypto,pipe,data,fd,rtp,udp -decryption_key **hidden** -reconnect 1 -reconnect_delay_max 30 -reconnect_streamed 1 -reconnect_on_network_error 1 -reconnect_on_http_error 5xx,4xx -i https://aod-ssl.itunes.apple.com/itunes-assets/Music118/v4/e2/c8/e9/e2c8e986-56f5-19a4-4a00-dcb9ba751c62/mzaf_A696447251.rmhq.aac.wa.mp4 -af volume=-5.01dB -acodec pcm_f32le -f f32le -ar 44100 -ac 2 -

[OzGav]

@MarvinSchenkel

[MarvinSchenkel]

Interesting, you're the first one to report this issue. A few seconds of delay is expected, since there is no official apple music api. I had to reverse engineer the api along with obtaining decryption keys , so that takes a 1-2 seconds.
However, 30 secs seems way too long. Your hardware also seems capable enough.

Do you have more stuff running on that hardware besides HA? Have you checked your hardware utilization? Also see you are not running HA OS, so I'd definitely look into available cpu / memory for MA.

[r10r]

@MarvinSchenkel First let me say that I'm really impressed by the apple music integration! Thanks for your work!

Memory and CPU should not be an issue. I did a simple test playing to a directly attached output using aplay. Playback starts immediately. So I think either ffmpeg or cliraop-linux-x86_64 to be the culprit.

/ruben-audio # ffmpeg -hide_banner -loglevel info -nostats -ignore_unknown -protocol_whitelist file,hls,http,https,tcp,tls,crypto,pipe,data,fd,rtp,udp -decryption_key <hidden> -reconnect 1 -reconnect_delay_max 30 -reconnect_streamed 1 -reconnect_on_network_error 1 -reconnect_on_http_e
rror 5xx,4xx -i https://aod-ssl.itunes.apple.com/itunes-assets/Music116/v4/b1/2f/ad/b12fadb2-6fec-a4c7-468e-4f8c6fc9d8b7/mzaf_A1440782866.rmhq.aac.wa.mp4 -acodec pcm_s16le -f s16le -ar 44100 -ac 2 - | aplay -q -D softvol4 -t raw  -r 44100 -c2 -f S16_LE

NOTE: I've disabled the loudnorm plugin since this increases ffmpeg's CPU usage from 2% to 15%.

Next I'm trying to send it to airplay. The shairport sync instances I have are running in Airplay 1 mode only are working very well with our zoo of apple devices.

[marcelveldt]

NOTE: I've disabled the loudnorm plugin since this increases ffmpeg's CPU usage from 2% to 15%.

That is only the first time you stream a track to collect the measurement while streaming. Next time it will have a measurement and it can do a simple gain correction. See docs about this.

The track is playing but there is no audio output for some time (often 5s to 30s).

Does this issue also occur on actual Apple hardware or only on shairport sync instances ?
What could be the case is that shairport sync requires a certain buffer treshold to be reached before it starts outputting audio.

Is there a way to test playback from cmdline with ffmpeg and cliraop-linux-x86_64 ?

No that will be near to impossible as its a whole chain of logic in python, pipes and processes.

[MarvinSchenkel]

I would also be interested to see where the delay is actually happening. I can think of two places:

1. Inside the apple music provider when the decryption key is requested
2. Somewhere in the ffmpeg chain

Can you enable debug logging on both the apple music provider AND the stream server to figure this out? If you see an ffmpeg log message like "Start streaming queue track xxxx" after 2-3 sec (indicating the ffmpeg process starts playing) and it still takes another 10+ sec for the music to start player, then it might be a buffer issue like @marcelveldt suggested:

[r10r]

I've already tested ffmpeg playback from apple music to local speaker output which works properly.
Please have a look at my previous comment #3470 (comment)

@marcelveldt

Does this issue also occur on actual Apple hardware or only on shairport sync instances ? What could be the case is that shairport sync requires a certain buffer treshold to be reached before it starts outputting audio.

No I do not have any issues with the shairport-sync instances. Airplay works fine from any other devices and the output always starts at the beginning of the track.

Is there a way to test playback from cmdline with ffmpeg and cliraop-linux-x86_64 ?

No that will be near to impossible as its a whole chain of logic in python, pipes and processes.

But it should be possible to let ffmpeg pipe sampled output directly to cliraop-linux-x86_64 ? I'll try that in the evening.

@MarvinSchenkel

I'll enable debugging in the apple music provider and send you the log output.

[marcelveldt]

No I do not have any issues with the shairport-sync instances. Airplay works fine from any other devices and the output always starts at the beginning of the track.

That is not exactly what I asked. I asked if you tested Apple Music from Music Assistant to another airplay device (so not the shairport sync).

But it should be possible to let ffmpeg pipe sampled output directly to cliraop-linux-x86_64 ? I'll try that in the evening.

You do not have to test that because that will work and you already confirmed that by playing local files so save yourself the trouble.

I guess this is a combination of Apple Music where it takes a tad longer to get the initial stream and shairport sync.
Can you give us some example config for shairport sync in airplay 1 mode so we can try to reproduce in that exact same config ? I have shairport sync setup on my macbook for some occasional listening but I think ios not forced into airplay 1 now.

[marcelveldt]

Ah that didnt take long - I just tried shairport sync and could immediately reproduce the issue.
I'll see what we can do about it

[r10r]

That is not exactly what I asked. I asked if you tested Apple Music from Music Assistant to another airplay device (so not the shairport sync).

Ah ok. No I didn't. I have no other speaker with airplay support - but I think I can test this with my macbook as receiver this evening.

But it should be possible to let ffmpeg pipe sampled output directly to cliraop-linux-x86_64 ? I'll try that in the evening.

You do not have to test that because that will work and you already confirmed that by playing local files so save yourself the trouble.

I guess this is a combination of Apple Music where it takes a tad longer to get the initial stream and shairport sync. Can you give us some example config for shairport sync in airplay 1 mode so we can try to reproduce in that exact same config ? I have shairport sync setup on my macbook for some occasional listening but I think ios not forced into airplay 1 now.

I've compiled shairport-sync without airplay 2 support:

autoreconf -i -f
./configure --with-avahi --with-mqtt-client --with-ssl=openssl --with-pipe --without-airplay-2

You can take a look at the attached Dockerfile - but it will not run without additional config files because it is customized for my environment.

entrypoint.sh.txt
Dockerfile.txt
shairport-sync.conf.txt

[r10r]

I'll try playback with cliraop-linux-x86_64 and let you know about the results.

[marcelveldt]

Well there is no more need for you to do more tests, I have reproduced the issue and I'll let you know later when I found the cause and solution