Chromecast stuttering playing WAV files

[iang77 0]

Hey all.

Emby server is struggling to play 44.1/16 WAVs to chromecasts.

I'm running Emby server on Raspberry Pi, connecting to my NAS through NFS. I have added a direct path to the share like this: nfs://xxx.xxx.x.xx/Music/Music/

When i cast from my Android phone, or from the web interface via my laptop, the WAV stutters in a very particular way;

• it gets to 6 seconds and pauses.
• it gets to around 27 seconds and pauses
• it then most of the time plays the rest of each track fine.

when playing through the web interface the progress bar shows the track playing (in green) and what i suspect is the track buffering (in grey). If it is buffering then what i see on the progress bar matches the bullet points above - the green bar catches up with the grey bar a couple of times then the grey bar zooms off.

 

I've ruled out:

• my synology nas (monitored whilst casting, no performance issues)
• my wifi (i can cast the same WAV using DLNA via BubbleUpnp with no performance issues)
• my pi (monitored whilst casting, no performance issues)

Have i got the nfs path incorrect? Is there something else i should do?

 

Logs attached. Any help appreciated - thanks.

 

 

embyserver.txt

[iang77 0]

i should mention that mp3 and flac play ok. Thanks.

[Luke 37004]

Hi, keep in mind that the difference with bubbleupnp is that will cast from smartphone to chromecast, whereas we cast from your emby server to your chromecast. Your smartphone can easily outperform your RPI I'm sure.

 

To me this just sounds like the data isn't being delivered fast enough. I think we should probably add music quality settings for Chromecast so that we can convert these on the fly to a smaller format.

[iang77 0]

Hi Luke. That sounds reasonable, but just to add to this, I can also cast the same wav without issues from the RPI if I use BubbleServer and make the Chromecast an OpenHome renderer.

I thought that when casting, the control point sends a command to the renderer to play a file from a location but doesn't actually process the audio itself, so the control point shouldn't impact the performance? Appreciate it's probably not that simple....

Ian

[Luke 37004]

 

 

I thought that when casting, the control point sends a command to the renderer to play a file from a location but doesn't actually process the audio itself, so the control point shouldn't impact the performance?

 

For Chromecast it depends because some apps will stream directly from mobile device to chromecast.