UPnP resending audio

Hi, I’m testing new setup for my system which is basically a Mac mini M2 with latest Audirvāna Studio and a Raspberry Pi4 running the “software who works better”.

Everything was ok unless I tried to send audio stream to Pi4 running Volumio, Different issues, strong static noise after few seconds or audio stream like “re initialized”, meaning audio back few or more seconds while playing. Spoke with some users they said try Moode,

I moved to Moode, I prefer, more stable. I can stably stream from iPad over UPnP for hours, also use the integrated UPnP “proxy” for Qobuz, no issues.

But, but, but. When I want to stream from Audirvana everything gets crazy, Tried all options, 2 different dacs, everything I read on forums, running only cabled network, but still problem persists, It looks like a re transmission, some time after 15 secs, some times after 1 min. I got surprisingly 30 mins playing without issues and then back again. It’s kind of annoying.

I’m IT expert, I do fix issues daily but this is now too much for me :slight_smile:

Should I just give up with this?

If you are an IT expert I will assume you are able to do this easily, but if you have any questions just ask:

I would reduce the “moving parts” and just keep things very simple. Install a minimal no-gui Linux OS and mpd with upmpdcli on the Pi to run UPnP. See whether that gives you a nice stable connection.

This to fix an Audirvāna issue? I need more then just upnp on my Pi and no time to custom make my o.s.

Understood. I was suggesting trying the simplest possible setup to eliminate any sources of complications and error, but if you need other things running on the Pi then that isn’t an alternative. I think you will probably be asked by others for your debug information when this happens, so it would be a good idea to post that here. I hope someone else is able to help you.

1 Like

I have been streaming from Audirvana to Volumio, a Volumio device that is, but that’s the same software. No problem at all. Sounds like a network issue.

Same network, same switch, wireless off, Mac OS firewall off. I did try to lower to minimum the upnp settings to 44.1/16 to reduce data transfer, still same.

I think Audirvāna is not getting (if part of the protocol) the ack answer and so it sends again, or … something is too fast or too slow and go retransmission. Network should be ok as all other services works flawless.

Audirvana doesn’t resend. It has problems with working across Mesh networks I noticed, but I have never been able to pin it down.

Update.

Checked file used to stream to Pi from debug log, File wav has no issues.

UPnP to my Sony TV … no issues.

Still to check if any Pi/USB port to DAC creating problems.

You put some curiosity on me :upside_down_face:

I see that Upmpdcli is also used in Moode, latest version and can’t upgrade. Or at least not easily. Have activate logs for UPnP (which are not set) and looking for one hour nothing strange. It logs every second properly as the song is running without issues, but I have glitches,

Last test for tonight was to check MPD logs, might loose sync with UPnP and I have found this, can’t explain but is something … you might know something more?

Feb 04 00:03 : exception: got HTTP status 404
Feb 04 00:03 : exception: Failed to decode http://192.168.1.159:49153/audirvana/audio_f_34.wav; got HTTP status 404
Feb 04 00:05 : ffmpeg/wav: Packet corrupt (stream = 0, dts = NOPTS)
Feb 04 00:05 : ffmpeg/wav: .
Feb 04 00:05 : exception: CURL failed: transfer closed with 75264 bytes remaining to read
Feb 04 00:05 : player: played "http://192.168.1.159:49153/audirvana/audio_f_33.wav"
Feb 04 00:06 : ffmpeg/pcm_s16le: Multiple frames in a packet.
Feb 04 00:06 : ffmpeg/pcm_s16le: Invalid PCM packet, data has size 3 but at least a size of 4 was expected
Feb 04 00:06 : ffmpeg: avcodec_send_packet() failed: Invalid data found when processing input

now need to sleep, will continue tomorrow if have time.

1 Like

I am sorry, all I can see is that the network transmission isn’t working correctly for those two files, which you can already tell. I’m not technically savvy enough to know more.

1 Like

What you see are network errors