Gapless (groan) with RoPieee and BubbleUpnp

[dartmoor]

(03-10-2023 10:07)stefano_mbp Wrote:  “16MB ram” (megabytes) is not a lot, rpi4 has 2GB (gigabytes) at least (4 and 8 GB available too)

Of course... duh. I was clearly having a very senior moment - either that or the caffeine hadn't kicked in yet!

[simbun]

(03-10-2023 09:11)dartmoor Wrote:  Sadly there was only a marginal difference with the RoPieee Openhome checkbox enabled. mconnect was as before - gapless. BubbleUpnp may have reduced the gap (difficult to tell) - but it's still there with a click between each track. I installed and tried HiFiCast as well - the gap was huge - a good second.

I've just tried all three control points and as long as gapless playback is enabled in each, all three play those 5 second tracks perfectly.
Do you have the UPnP Bridge configured?
What file formats are you playing?

I'd be tempted to flash the SD card again as something isn't right.

(03-10-2023 09:11)dartmoor Wrote:  I'm wondering if the Openhome player might prove better? I'm not familiar with it yet I see from their website that the Pi player requires 16MB memory??? A typo surely? I wasn't aware that such a thing existed.

I didn't know there was a player!
Those requirements are in addition to the OS requirements obviously.

[dartmoor]

.
[/quote]
I didn't know there was a player!
Those requirements are in addition to the OS requirements obviously.
[/quote]

Nor did I until I investigated OPenhome. As they say:

"The application runs on Raspberry Pi in GUI mode as a GTK application, or if you don’ want a GUI version, you can download the headless version which runs straight from the commandline."

I'm tempted to see if this gets rid of the BubbleUpnp gap problem.

[simbun]

(03-10-2023 11:03)dartmoor Wrote:  I'm tempted to see if this gets rid of the BubbleUpnp gap problem.

Given that all the control points are working here I'm pretty sure it's not a BubbleUPnP problem. You could try turning on debugging in BubbleUPnP to see if that showed anything.

If you were going the OpenHome player route then you'd have to configure the audio stack yourself in the OS. I use a HAT so it seems like a lot of work to me.

[simoncn]

A slow network connection might cause this if the control point is not giving the renderer much advance notice to load the next track.

[dartmoor]

(03-10-2023 11:21)simbun Wrote:  

(03-10-2023 11:03)dartmoor Wrote:  I'm tempted to see if this gets rid of the BubbleUpnp gap problem.

Given that all the control points are working here I'm pretty sure it's not a BubbleUPnP problem. You could try turning on debugging in BubbleUPnP to see if that showed anything.

If you were going the OpenHome player route then you'd have to configure the audio stack yourself in the OS. I use a HAT so it seems like a lot of work to me.

I'll check out the debug - and investigate OpenHome more if nothing else works.

[dartmoor]

(03-10-2023 11:24)simoncn Wrote:  A slow network connection might cause this if the control point is not giving the renderer much advance notice to load the next track.

Now there's a thought! The Pi is running on wifi and I'm not convinced the signal is the best. It's the only room in the house not with an ethernet connection so I'll decamp to another room with wires for testing

[simbun]

One other thing to check would be to go into the ropieee settings in BubbleUPnP and change 'FFmpeg audio decoding' to 'Never use'.

On a hunch I ran BubbleUPnP in debug mode and found that for some reason BubbleUPnP is transcoding my FLAC files to WAV and serving those (from the phone) to ropiee, which will introduce a lag, especially if the signal is already bad.
I always disable this because I'd rather know if something needs transcoding, and have MinimServer perform it, but I forgot this time.

I'm not sure why it's doing this, because MinimServer appears to be serving a content type of 'audio/x-flac' (from 'curl -v http://192.168.*.*:9790/minimserver/*/FLACTesting/5Seconds/01.01.flac') and ropieee appears to support it (from debug log):

Code:

ropieee [RoPieeeXL]-UPnP/AV: supported mime-types: [audio/lpcm, audio/L16, audio/l16, audio/x-flac, application/flac, audio/flac, application/x-flac, audio/x-ogg, application/x-ogg, audio/vorbis, application/ogg, audio/ogg, application/vnd.apple.mpegurl, application/x-mpegurl, audio/aacp, audio/aac, audio/3gpp, audio/3gpp2, audio/x-aac, application/aiff, audio/aiff, application/x-aif, application/aif, application/x-aiff, audio/x-aifc, audio/x-aiff, audio/aif, audio/aifc, audio/x-aif, audio/dff, audio/x-dff, audio/x-dsd, audio/dsd, audio/x-dsf, audio/dsf, audio/m4a, audio/mp4, application/x-m4b, application/x-m4a, application/x-m4p, application/x-mp4, audio/mpeg4, audio/x-m4b, audio/x-m4a, audio/x-m4p, audio/x-mp4, application/mpeg4, audio/matroska, audio/x-matroska, audio/mp1, application/mp1, audio/mp3, application/mp3, application/x-mp3, audio/mpg, audio/mpeg3, application/mpeg, audio/x-mp3, audio/x-mpegaudio, audio/mpeg, audio/x-mpeg3, audio/x-mpg, audio/x-mpeg, application/mpeg3, application/ape, application/x-ape, audio/monkeys-audio, audio/x-monkeys-audio, audio/ape, application/monkeysaudio, audio/x-monkeysaudio, application/monkeys-audio, audio/x-ape, application/x-monkeys-audio, application/x-monkeysaudio, audio/monkeysaudio, audio/wav, application/x-wave, audio/wave, application/wave, application/wav, application/x-wav, audio/x-wave, audio/x-wav, audio/x-ms-wma, application/x-ms-wma, application/wma, audio/wma, audio/x-scpls, audio/x-vorbis+ogg, audio/x-vorbis, audio/wavpack, application/x-wavpack, audio/x-wv, application/wavpack, audio/wv, audio/x-wavpack, application/wv, application/x-wv, video/mp4v-es, video/mp4, video/3gpp]

That wasn't my hunch by the way, I'm still looking into that :-)

[simoncn]

Transcoding by BubbleUPnP is a very plausible explanation for this issue. As well as the delay caused by FFmpeg transcoding, there is also a delay caused by the audio passing across the network from MinimServer to BubbleUPnP and then from BubbleUPnP to the RPi. Transcoding by MinimServer/MinimStreamer (if needed) enables the audio to pass directly from MinimServer to the RPi.

[dartmoor]

I've now removed the transcoding and installed a wired connection - and on the same Ethernet switch as the music server.

The result is now gapless BubbleUpnp playback!

Thankyou kindly, again, particularly to simoncn and simbum for your time and effort to help. It is much appreciated.

Incidentally I believe SImbum uses a HAT DAC on the Pi. I've another Pi to install and I'm wondering what's the 'best' HAT DAC to use - and what case?