Jump to content

bubbleguuum

  • Posts

    76
  • Joined

  • Last visited

  • Country

    France

2 Followers

Retained

  • Member Title
    Freshman Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It's been a long time foo_upnp is not supported anymore. Anyway, there is foo_out_upnp as a replacement to 'Playback Stream Capture', an official plugin by the foobar2000 dev. It behaves similar to what you describe, streaming foobar2000 audio output as a single PCM stream until samplerate/bitdepth changes in which case it plays a new stream to the renderer with the new samplerate/bitdepth.
  2. @Miska Thank you for the info. The renderer's protocolInfo does not seem to include application/ogg (while it includes audio/ogg), at least it is not included in the protocolInfo I have for HQPlayerEmbedded:SignalystHQPlayer5 from a few months ago. Many Ogg-FLAC streams use application/ogg as their Content-Type http header, thus this what BubbleUPnP uses as mime-type for SetAVTransportURI (which fails with an error 714). Can you consider adding application/ogg to the protocolInfo ?
  3. Hi, BubbleUPnP dev here. A user of the HQPlayerEmbedded:SignalystHQPlayer5 renderer made me aware of playing some SHOUTCast streams to this devices, with log files. It showed a few problems in BubbleUPnP, but I have some questions about this renderer capabilities to make a proper fix. What are the exact capabilities of HQPlayerEmbedded with SHOUTcast streams (whether via ICY or HTTP protocols) ? In particular, does it support natively AAC streams and Ogg-FLAC streams ? example streams: AAC: https://st01.sslstream.dlf.de/dlf/01/high/aac/stream.aac?aggregator=web Ogg-FLAC: https://stream.radioparadise.com/flacm Also, can you confirm that this renderer does strict checking of the mime-type vs its protocolInfo, when being issued a SetAVTransportURI command, and if the mime-type is not listed in its protocolInfo it always return error 714 "Illegal mime-type" ? Speaking of which, it does not seem to define any mime-type for playing AAC (audio/aac) and AAC im MP4 container (audio/mp4 or audio/x-m4a). Does it support AAC at all ?
  4. @Miska Tidal proxying: in v4.3.2 it is always enabled as mentioned in the changelog. Next app update will make it configurable again (ability to disable it) although it will still be enabled by default, as too many renderers have issues streaming directly from TIDAL: whether TLS issues (most TIDAL streams are https), not buffering at a proper pace (resulting in drop outs or TIDAL server closing the connection unilaterally), not supporting http redirects... Reliable TIDAL streaming (especially HiRes) can be really tricky with a tad more possible issues that regular LAN FLAC streaming. Proxying helps in most cases and it does not alter audio quality (renderer receives the exact same FLAC). System UI issue: start BubbleUPnP, go into 'More > Settings > Control' and disable 'Android 11+ notification'. Although this should be normally disabled by default on Moto devices running Android 12, since v4.3.2. If you cannot even get there try again after clearing app data in Android Settings > Apps > BubbleUPnP > Storage. This issue is actually a bug introduced by some System UI change on these devices (Moto, Android 12) done by the manufacturer that broke the default Android 11+ media notification (at leas in how BubbleUPnP use it). No other devices have this issue. Also, to improve reliable streaming with BubbleUPnP when screen is off it is very recommended to do these: - apply these instructions for your Android device: https://dontkillmyapp.com/ - apply instructions in BubbleUPnP in More > Settings > Disable system battery optimization
  5. @thegios For playing gapless albums, in BubbleUPnP you need to enable More > Settings > Renderer settings > (Pick renderer) > Gapless control. If 'Gapless control' is grayed out (disabled) your renderer does not have the UPnP command for gapless. If you can enable it, it is not a guarantee that gapless control will work properly.
  6. In BubbleUPnP, did you enable More > Settings > Renderer settings > (pick HQPlayer) > Gapless control? If you did can you check if you have this issue with it disabled ?
  7. A few notes about BubbleUPnP Audio Cast: - It is somewhat similar to AirPlay on iOS, capturing audio from most music apps as a continuous 44.1/16 PCM stream to play it on your Lumin renderer. - It works with most music apps, including Apple Music, YouTube Music, Deezer, TuneIn and many more, but it notably does not work with Spotify (technical limitation) - In the free version of the app, it is in demo mode and limited to 15 mins after which it cuts out (you can restart it as many times as you like) - next app update will remove the need to clear the Playlist tab (playback queue) for the free version of the app
  8. BubbleUPnP developer here. This looks like a HQPlayer issue but where are the tracks coming from and what format are they (codec, samplerate, bitdepth) ?
  9. LOL MQA. That tech in search of a problem cannot disappear fast enough.
  10. Not using AirPlay, but BubbleUPnP can capture other music app's audio to play it to most renderers it supports (UPnP/DLNA, Chromecast, OpenHome, but not AirPlay). Let me know if you want details.
  11. There is no need for a new SPK as BubbleUPnP Server updates are independent of whatever packaging system installed it. Go into the web interface of BubbleUPnP Server and check if the version is 0.9-update44 (it should if you did not disable auto-updates). If it isn't, go into the Settings/Updates tab and use the "Check for update" button.
  12. Yes it will, for the official update in a few days (not before next Thursday).
  13. I have a beta version of BubbleUPnP Server for testing that should work fine with latest iOS Lumin version (8.2.0). Please test that version if you use OpenHome renderers managed by BubbleUPnP Server: - download https://bubblesoftapps.com/bubbleupnpserver/beta/0.9-update44p1/BubbleUPnPServer.jar - stop BubbleUPnP Server - in its installation directory, replace existing BubbleUPnPServer.jar by the downloaded one - start BubbleUPnP Server - verify in the web interface, Status tab, that the version is 0.9-update44p1 - use the Lumin app on iOS to control an OpenHome renderer managed by BubbleUPnP Server and check that play / pause / next / prev / seek playback position / shuffle / repeat work properly in as much scenarios as possible
  14. BubbleUPnP dev here. BubbleUPnP Server will need to be updated to work with the new Lumin app. I will look into it but no promise if/when it will be.
  15. Some info about Qobuz/TIDAL playback to various renderers. Streaming Qobuz/TIDAL reliably to various renderers has much more potential for playback problems than, say, streaming FLAC from MinimServer on your local network. First, there can be network bandwidth issue where either reading the FLAC stream cannot be done fast enough (user's network or ISP issue), or the Qobuz/TIDAL http server serving the stream cannot send if fast enough (Qobuz/TIDAL issue). This should be rare (especially the later), but still possible. And rarely, the service can have a temporary failure. Next, the Qobuz/TIDAL http servers may close connection if a reading client (the renderer or BubbleUPnP) does not read the stream fast enough. This entirely depend at which pace the renderer performs its buffering, which can be very different depending on model. Such issue manifests as playback stopping unexpectedly mid-track (usually on longer tracks), as Qobuz/TIDAL http servers decide to unilaterally close the connection due to inactivity. Probably infrequent, but some renderers may also fail to access Qobuz/TIDAL http servers entirely due to the behavior of said servers (not liking some http headers, not supporting possible http redirects, ...). Much more frequent, you also have some renderers not buffering enough, or not able to buffer the amount they want in the amount of time they expect, thus exhibiting playback problems (dropouts). This is mostly the case for HiRes Qobuz streaming. Finally, some renderers have semi-broken or problematic FLAC decoders (that may only fail for 24-bit or High-Res for example). To alleviate all these issues (lacking bandwidth excluded), there is the 'proxy' option in BubbleUPnP, which reads as much of the TIDAL/Qobuz FLAC stream as fast as possible into RAM and serve that to the renderer, with no loss of quality. And in case that the renderer's FLAC decoder has problem, there's also the ability to have BubbleUPnP convert to FLAC to WAV and serve that to the renderer (without loss of quality). When using either (proxying, or WAV decoding which implies proxying), there's the new requirement that the renderer maintain a good network connection to BubbleUPnP on the LAN (in term of bandwidth), and that BubbleUPnP itself has a good WiFi connection the Internet to read the stream. Which adds the recommendation of keeping the Android device not too far from the WiFi router. Finally, for the duration you are playing TIDAL/Qobuz tracks, BubbleUPnP must have working Internet connectivity (whether proxying is enabled or not, playing to OpenHome renderer managed by BubbleUPnP Server excluded) and remain accessible on the LAN by the renderer. Some Android devices have aggressive battery saving measures when the screen is off, that can cause problems in that regard. Thus it's recommended to apply these instructions for your Android device: https://dontkillmyapp.com/. And to apply instructions in BubbleUPnP, in More > Gear icon > Disable system battery optimization. As you can see Qobuz/TIDAL streaming can be rather tricky...
×
×
  • Create New...