Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[madbrain]

We just feed the audio to googles library to manage Chromecasts. Do they still support Chromecast Audio?

They haven't sold them for a long time (2018 I believe), but I think they are still supported, though in maintenance mode.
The fact is that some apps work on my CCAs (Plex, Qobuz, Google Home) and others don't (here, JRemote2, but MO4 Media behaves the same). There is a bug somewhere, in some layer, but I have no idea which one.

For example, a while ago, it was discovered that having Home Assistant (running on a completely separate host!) with the Google Cast integration enabled stops the SirusXM Android app from being able to cast to CCAs. Very strange but completely reproducible bug.

I do happen to be a HA user and I use this cast integration to turn on amplifiers when playback starts, since I have so many zones and can't afford to leave the amps running hot 24/7.
Unfortunately, disabling this integration (and even stopping my Home Assistant VM altogether) does not fix the problems with JRemote2/MO4 Media.

I do have a fairly extensive home network with 153 static DHCP reservations. I figured I would try to strip it to the bare minimum to see if that made the CCA work.
I spent much of my day today doing so -:
1) I setup the Comcast gateway as router instead of just modem (bridge mode)
2) I disconnected my pfSense router from the WAN
3) I connected just 5 devices to a switch on the LAN side of the Comcast gateway
a) one CCA in my home office
b) one PC running MC31 server
c) one Wifi access point in my home office
d) the Raspberry Pi running my Unifi controller (so I could change the Wifi config and isolate the network)
e) the WAN
So, after disconnecting 148 IP devices from the network (they continued to function on a separate LAN, with no Internet access), lo and behold, both JRemote2 and MO4 Media could cast successfully to the lone CCA on the network.

I then reverted to the previous setup with pfSense and all the device, and was able to cast from JRemote2 as well for a while, even to a speaker group of 12 indoor CCAs. This was about 20 minutes ago. Then, I tried to cast from MO4 Media, and it failed. And then, back to JRemote2, it now fails as well. I rebooted the Android phone (S22 Ultra), but to no avail. I rebooted the CCA in my office too, using the Google Home app. Still no dice. I'm not sure how to proceed next to debug this failure. It seems the CCAs are very sensitive to the presence of other devices on the network, but I'm not sure which one(s).
Sigh.

[markf2748]

My 14 CCAs all work fine in other apps such as the Google Home app (cast my audio feature), and Qobuz.
Any idea what might be going on and how to fix it ?

I run two original CCA's regularly using Android apps MO 4Media, JRemote2, JRiver Panel, and BubbleUPnP for Android, as well as directly from the MC Server itself.  Reliability is pretty good on my smallish home network - sometimes it takes a little coaxing to get the first track in a playlist to start.

However, I never use a "cast" button in these apps.  Instead I run BubbleUPnP Server on the MC server computer which makes the CCAs look like DLNA renderers to the apps and MC server. The CCAs appear as DLNA devices in the MC server's tree "Playing Now" and in the apps' player choices.  I would recommend static DHCP addresses to maintain sanity.  You can find many old posts about the setup in this forum, but it's really quite simple.

Win 11 Pro 64-bit 22H2    MC 31.0.80

[madbrain]

However, I never use a "cast" button in these apps. 

Have you ever tried, and if so, what was the result ?

Instead I run BubbleUPnP Server on the MC server computer which makes the CCAs look like DLNA renderers to the apps and MC server.  You should see the CCAs as DLNA devices in the MC server's tree "Playing Now" and in the apps' player choices.

Thanks. I have yet to give BubbleUPnP a try, though I have read about it. I read that it doesn't solve the lack of gapless support issue with CCAs, so I didn't pursue it. Does it help with reliability ? Also, does it support groups ? And does it properly multi-cast like the CCAs normally do ?

I would recommend static DHCP addresses to maintain sanity.  You can find many old posts about the setup in this forum, but it's really quite simple.

Yes, I use static DHCP addresses already. And pfSense allows giving my CCAs hostnames in its DNS too so I can use those too presumably.

[madbrain]

So, I tried BubbleUPNP server on Windows. I created 21 DLNA renderes for all the CCAs, CCUltra, CCGtvs, and the 4 groups. JRemote2 unfortunately does not see those DLNA devices. Do I need the BubbleUPNP for Android program for that to work ?

The good news is that MO4 Media does see all those 21 DLNA renderers, and it even hides the corresponding Chromecasts, so there are no duplicates. Playback seems to work fine, except it's full of gaps between tracks, but I unfortunately knew what to expect in that regard.
Edit2: there are duplicates, I just didn't wait long enough for the full list of renderers to populate.

Edit: I tried the BubbleUPNP Android app also. It doesn't change the behavior for JRemote2 unfortunately - the DLNA renderers for the Chromecasts still don't show up.

The BubbleUPNP app itself shows a lot of devices to render to - all my CCAs, plus the corresponding CCA DLNA renderers, the video Chromecasts, the Airplay Marantz AVRs, and even some FireTV.
I set it to play from my MC31 library server onto a CCA BubbleUPNP DLNA renderer, and it worked fine (with gaps). Directly playing onto the CCA worked too, unlike JRemote2 and MO4 Media ... It is still very mysterious why some Android apps can cast successfully to the CCAs, and others can't.

[madbrain]

So, I tried BubbleUPNP server on Windows. I created 21 DLNA renderes for all the CCAs, CCUltra, CCGtvs, and the 4 groups. JRemote2 unfortunately does not see those DLNA devices. Do I need the BubbleUPNP for Android program for that to work ?

Turns out I was missing something. I was using the cast button in the JRemote2 app in the top right corner.
I completely missed the circular zone control on the bottom left of the JRemote2 pop-up menu.
The 21 BubbleUpNP DLNA receivers do show up there.

It is still very mysterious why some Android apps can cast successfully to the CCAs, and others can't.

Spent quite a few more hours today taking my network apart. Can't tell you the number of Ethernet cables I unplugged, or pfSense config changes and resets. Anyway, I ended up in a state in which Chromecast audio casting works in all apps on my phone, including JRemote2 and MO4 Media, but I'm really not at all sure what change did it.
The problem seems to be quite intermittent, so I expect it to come back, unfortunately.

I have been unhappy with the lack of gapless support in the CCAs for a long time. So, I ordered a Wiim Pro Plus a couple days ago. I received it today. I have been playing with it. After struggling a little bit, I got it to play my gapless albums with MC31 for Windows. I then got the JRemote2, BubbleUPNP and MO 4Media apps working with this as well.
The only thing I haven't gotten to work is native DSD, which the Wiim device is supposed to support up to DSD512. I'm just trying to play DSD64/SACD ISOs. So far I had to enable transcoding to stereo PCM 24/192 kHz because I otherwise just got playback errors. I haven't tested the grouping feature since I only have one Wiim, but that will probably change soon.

[markf2748]

So, I tried BubbleUPNP server on Windows. I created 21 DLNA renderes for all the CCAs, CCUltra, CCGtvs, and the 4 groups. JRemote2 unfortunately does not see those DLNA devices. Do I need the BubbleUPNP for Android program for that to work ?
...
Edit: I tried the BubbleUPNP Android app also. It doesn't change the behavior for JRemote2 unfortunately - the DLNA renderers for the Chromecasts still don't show up.

I find that when using BubbleUPnP Server, recognition of DLNA CCA renderers by MO 4Media, JRemote 2, and JRiver Panel corresponds 1-1 with what appears under MC Server's tree Playing Now.  If renderers disappear from the apps, then it means MC Server is not seeing them.  Closing and restarting the processes Media Center 31 and Media Center Server in Windows Task Manager usually resolves the issue.  In contrast, the BubbleUPnP player app is generally more robust in this regard than the other apps, I think because it communicates directly with the BubbleUPnP Server which I find to be extremely reliable.  Bubble just needs MC running to access the MC library.

The BubbleUPNP app itself shows a lot of devices to render to - all my CCAs, plus the corresponding CCA DLNA renderers, the video Chromecasts, the Airplay Marantz AVRs, and even some FireTV.
I set it to play from my MC31 library server onto a CCA BubbleUPNP DLNA renderer, and it worked fine (with gaps). Directly playing onto the CCA worked too, unlike JRemote2 and MO4 Media ... It is still very mysterious why some Android apps can cast successfully to the CCAs, and others can't.

In the past, implementation quality of Google Cast varied widely between different Android MC player apps, and Google CCA firmware was also less robust.  For the longest time I found "Casting" from these apps was totally unreliable, sometimes crashing the phone or hanging MC Server.  Hence my move to Bubble and never looking back, until today.  I tried "Casting" from the apps today and it actually worked without issue.  I'll try using it more often, out of curiosity.

The other advantage of Bubble and DLNA CCAs on the server is MC Playing Now > Overview allows you to see and control all playlists for DLNA renderers.  The Cast renderers do not show up at all in the MC Server Overview.

Be aware that off-normal activity on the MC server can cause DLNA CCA renderers to disappear from Playing Now and hence disappear from apps.  In particular, a windows update downloaded in the background, but waiting to be installed, can wreck havoc here (no idea why, but I have seen it repeatedly).  I recently experienced an outage from my internet provider.  Local Wi-Fi kept working, but after the internet came back, I had to close and restart MC Server to get DLNA CCAs back to normal in MC.

[markf2748]

I have been unhappy with the lack of gapless support in the CCAs for a long time. So, I ordered a Wiim Pro Plus a couple days ago. I received it today. I have been playing with it. After struggling a little bit, I got it to play my gapless albums with MC31 for Windows. I then got the JRemote2, BubbleUPNP and MO 4Media apps working with this as well.
The only thing I haven't gotten to work is native DSD, which the Wiim device is supposed to support up to DSD512. I'm just trying to play DSD64/SACD ISOs. So far I had to enable transcoding to stereo PCM 24/192 kHz because I otherwise just got playback errors. I haven't tested the grouping feature since I only have one Wiim, but that will probably change soon.

I seem to recall others reporting success with Wiim devices recently.  The clear advantage is that they are DLNA renderers so MC sees them directly without Bubble and that should be good news for the Android apps.  Great to hear that it works gapless with MC; it would be nice if you further report your experiences.  Wiim is on my list if I ever decide to abandon those $35 CCAs.

[madbrain]

I find that when using BubbleUPnP Server, recognition of DLNA CCA renderers by MO 4Media, JRemote 2, and JRiver Panel corresponds 1-1 with what appears under MC Server's tree Playing Now.

Yes, that mirrors what I see, when I use these apps on my LAN subnet.
However, when I put my phone on 4G/5G (the signal is borderline so it constantly switches, sigh), and connect home using my pfSense VPN, BubbleUpNP fails to find my MC serve. As far as I can tell, it's only doing automatic discovery in the VPN subnet, which is why it doesn't find my MC Server.
Whereas when I use JRemote2 and MO 4Media, they can find the MC IP using the access key or hostname. And then all the home DLNA renderers can be controlled as well.
Is there no possibility of manual server discovery in BubbleUPNP ? I looked but couldn't find one.

In the past, implementation quality of Google Cast varied widely between different Android apps, and Google CCA firmware was also less robust. 

I can attest that this was still the case in my home environment, great variability of casting reliability between apps. Can't speak about the firmware, but I think my CCAs are all on the same one. I wonder what code the other companies integrating CCA use (such as Wiim!) if they are licensing Google code or re-implementing stuff.

Be aware that off-normal activity on the server can cause DLNA CCA renderers to disappear from MC Server and hence apps.  In particular, a windows update downloaded in the background, but waiting to be installed, can wreck havoc here (no idea why, but I have seen it repeatedly).  I recently experienced an outage from my internet provider.  After the internet came back, I had to close and restart MC Server to get DLNA CCAs back to normal in MC.

I see. Windows updates really are a PITA. I am going out of the country late next week and I hope that doesn't happen while I'm there. This is why I care about VPN access to MC.

I have some advanced home automation measures to try to recover from network/Internet outages, but hadn't thought about Windows updates. I use Home Assistant with some Z-Wave smartplugs (both on UPS) to reset both the pfSense router and the cable modem, if either becomes unpingable over IP for a given time (I set it to 30 minutes, to allow for them to do lengthy firmware updates). For power outages, I haven't yet bothered to connect the UPS serial cables and detect the power outage situation - not sure exactly what I would do in those cases if I'm away from home - I couldn't just automatically shutdown the server as it wouldn't come back up on its own when the power is back (or if the outage is short and power doesn't actually run out). I suppose the pet sitter could always power things back up the next day if things shut down.

Someone in the WiiM forum just responded that DSD is not natively supported yet in the Wiim Pro/Pro Plus. They really shouldn't advertise DSD512 in the specs ! The only thing that works is passing DSD as DoP over DLNA, and using an external DSD DAC to decode that. Needless to say, I don't have an external DSD DAC. Let alone one for each zone.
I guess I'll let MC31 do the DSD to PCM conversion. I placed an Ebay bid for 11 more Wiim Pro Plus, hope it's accepted.

[madbrain]

I seem to recall others reporting success with Wiim devices recently.  The clear advantage is that they are DLNA renderers so MC sees them directly without Bubble and that should be good news for the Android apps.  Great to hear that it works gapless with MC; it would be nice if you further report your experiences.  Wiim is on my list if I ever decide to abandon those $35 CCAs.

So far, I can report a few things. The $219 Wiim Pro Plus is well built. Unlike the Chromecast Audio, it uses RCA connectors, and the cables should stick in place. As you know, the CCA uses a 3.5mm headphone jack. My cats are always playing with the wiring and have often partially disconnected the cable, creating ground loops and noise in many of the ceilings, and it's is hard to track down which in the sea of CCA cables.
It also has an Ethernet port built-in, unlike the CCA. I didn't want to use Wifi for my CCAs given the number of units I have and multi-casting. So, I bought a $15 Ugreen OTG Gigabit Ethernet NIC for each of my CCAs. That makes each CCA a sort of spider, and extremely messy wiring, especially when you have multiple of them in one spot - I have two spots, each with 6 CCAs, and two 7.1 receivers, where each CCA is connected to the multi-channel inputs, either as L/R, SL/SR, or SBL/SBR. This is how I power all those zones inexpensively. This type of receiver (without any HDMI) is almost free for the taking on Craigslist if you look.
Anyway, I couldn't be happier about the way the hardware interfaces. There is also an analog input (stereo RCA) two digital outputs (coax and optical) and a trigger output, which would come in handy to power the receiver on/off, but that only works if you have a single zone.

There is a Chromecast audio built-in, so if you like the CCA, you can continue to use the Google cast feature. It's actually an optional feature. If you turn it on, you can't disable it later without a factory reset, which is rather silly. Most Android audio apps don't support DLNA, but many support Google cast, so it's probably best to keep the feature enabled.

Since I only have one WiiM, I couldn't test the native grouping support. I successfully grouped the built-in CCA with my native CCAs, though. That probably means there will be 2 sets of groups, one CCA group and one native group.

There is Alexa support, which I haven't tried, nor did I try the voice remote. I'm not an Alexa user, and not big on voice support in general.
On the downside, the advertised DSD512 support is not actually there (yet, hopefully ?).

WiiM has an app of its own that's not just for setting up the device, but also playing music from either local servers, or streaming services. I was able to browse my MC31 Media Server using the app. It is quite slow, though, with a 10-11 seconds delay when opening a large folder (Artists, Albums).  No such delay when browsing with other apps (Bubble UPNP, JRemote2, MO 4Media). My server is hosted on an AMD 5700G, a completely silent box. Besides the slowness of the app, the Search feature does not work. So, be prepared to do a lot of scrolling if you use this app. However, if you manage to select your content in this app, it will play nicely and gaplessly.

I tried one music service with the Wiim Home app, Qobuz. It worked great. The search is instant. The playback is gapless. It even showed my previous playlist with the 400 Goldberg variations versions, which I had created with Roon. Speaking of which, I let my Roon trial expire. It is a very nice program and app, but I had a hard time accepting relinquishing manual control of my library. I was attracted to the gapless CCA support. But that was only for the Roon app. With WiiM, I'll get gapless in a bunch more apps/services.

As to how it sounds, I can't say that I am able to notice an obvious difference between it and the CCA. But I hooked it up to a zone  with a lot of resonance (12ft ceiling, ceiling speakers more than 20ft apart). I played a few SACDs with DSD->PCM transcoding, and they sounded good.

Anyway, I only had the device for about 5 hours, those are just my first impressions.

[madbrain]

Responding to myself - a few more things. The Wiim app only works in portrait mode. Found that out the hard way on my tablet with its keyboard case, which is normally in landscape mode. Too bad, the keyboard comes really handy in searches, but I'm not going to rotate my head 90 degrees to use this app. Unfortunately the Samsung tab S9 ultra keyboard case only supports landscape.
At least the Qobuz app works in landscape mode, as does JRemote2.

Speaking of remotes, since that is the subject of this forum, I saw a few odd instances with all the remote apps. Sometimes they showed the wrong album/track name, but the correct timeline, and the controls worked. The track names weren't fixed when switching to the next track. Very odd.
It looks like I can reproduce the following way :
1) play an album from MC31 onto the WiiM using JRemote2
2) use the WiiM app to play an album from Qobuz on the Wiim
3) go back to JRemote2. It's still showing track names from the album from step 1. But the play controls work, track number updates, time updates as well. Even the track name changes, but to the track number from the other album. Not sure what happens if there is a disjoint number of tracks between the 2 albums and one goes "past the end". I just tried it actually. Played a 7 track organ album in step 1, up to track 3, and a 32 track piano album in step 3. Played track 12 on that second album. Then when I went back to JRemote2, it was still showing that it was the track 3 on the organ album, but with the time scale of the piano album, while hearing track 12 of the piano album. I use JRemote to skip tracks, and it went to track 4 of the organ album and played it. Anyway, there seems to be an issue with data not updating correctly when using the Wiim from multiple apps.

I also saw another situation where playback wasn't gapless with the wiim receiver, even though I was careful to select the DLNA receiver and not the built-in Chromecast. Not sure what that was about. I switch to another remote and the same album played gapless.

Lastly, after stopping playback in one remote, a few seconds later, the playback started again, presumably because of another remote app.

So, for now, I uninstalled MO4 Media and BubbleUPNP Android app from my tablet. I may uninstall them from my phone too. I also uninstalled the BubbleUPNP server on Windows. I'll keep just JRemote2 for browsing/playing my MC31 server content. It works well both on the phone and tablet, and on my WLAN and VPN.

[madbrain]

So, after playing a few hours with the wonderful DLNA support in the Wiim Pro Plus, I decided to try Google Cast in JRemote2 just for kicks. This time I cast to the Wiim built-in CCA. It's back to non-working state - initial cast sound and that's it. Qobuz app can still cast successfully to this CCA, and is sounding great, except for gaps. But the album I'm listening to right now isn't gapless so that's acceptable. Bottom line, there are still intermittent issues with Google Cast on CCAs and with JRemote2, and many other Android apps, but not all. Not sure if I'm the only one running into them.

[madbrain]

it would be nice if you further report your experiences.

So, I tried the WiiM in my best seat in the house, in my home theater with Energy Veritas 2.3h speakers and a Marantz SR7011 receiver. I first connected the SPDIF optical output. I had to use the Wiim app to select it. Only one output can be active at a time. So, the analog out that was still connected to the other receiver for the other zone got disabled. I then use the Qobuz app to find some high res content - 24 bits 96 kHz, and cast use Google cast protocol. I played the very familiar 1981 Goldberg variations, of which I own several versions includin the SACD. But here it was high-res PCM obviously on Qobuz. I listed to 8 tracks. They all sounded great, except for the gaps. There is also a very annoying fade-in / fade-out at the start/end of each track. Most inappropriate for classical. Not sure if there is a setting in the Wiim or Qobuz app to disable it - I haven't found it. Anyway, using the receiver's DAC, these Goldberg sounded as good as I remember the DSD version sounding. I made sure to set the receiver in Pure direct and 2 channel stereo mode only (the HT has 15 speakers). Other than the gaps & fades, I really couldn't fault the playback at 24/96 using the receiver DAC.

Then, I decided to use the analog outs from the Wiim and connect them to a stereo input on the Marantz SR7011. I switched the Wiim to the analog out. This made all casting stop - I had to restart it.
Anyway, long story short : it sounded even better with the Wiim Pro Plus DAC doing the decoding. Not sure I can really explain how, but it did. This was not a blind test, obviously, much less double blind. It could be that the levels are very slightly different between DACs, and that could influence my impression. Louder is often perceived to be better. Anyway, the DAC sounds absolutely great.

I suppose after this, I could just bitstream the DSD version of the disc to the receiver from the Sony HDMI disc player for a comparison. Time to get off my couch. Actually, the disc was still in the player from the last time I demo'ed the sound system. So, I set the receiver in Pure mode, and it displayed "DSD Direct". This is using the receiver's built-in DSD DAC. The level from my Sony UBP-X800 is clearly a lot higher than with the previous two DAC tests with the PCM Qobuz version, or maybe this is just the way the SACD was mastered. When variation 1 started loudly, my cat who was listenin got really startled at how loud it was. Time to pick up the trusted Radio Shack SPL meter, which is right here on my CD/SACD shelf.

I was able to get a measurement peak 96 dB C for the first 10 seconds of variation 1 on DSD from the SACD player, with the receiver set to 0dB. Then, unfortunately, the 6 year expired 9V battery ran out, and I was unable to take the measurement with the Wiim Pro Plus DAC. I think there is at least a 3dB difference between the two, and possibly more. I unfortunately don't have another 9V battery in the house, sigh.

Without adjusting for volume, I still like the DSD version the best of the 3. With a compensating volume adjustment, in a blind listening test, I can't guess which of the 3 versions I might prefer.

Actually, it turns out the content I chose on Qobuz was the wrong one - it was a hires version of the 1981 Gouldberg, but in 24 bit 44.1 kHz, not 96 kHz. No wonder I preferred the native DSD version. But there are definitely major mastering differences, in volume.

I also happen to have the SACD ISO for that Goldberg disk. So, I streamed it to the Wiim Pro Plus using MC31, with transcode to 192 kHz PCM stereo. The volume was much lower than when bitstreaming DSD from the disk player to the receiver over HDMI. I estimate about 9 dB lower. This is either due to the DAC in the WiiM having lower volume, or some artifact in the transcoding. Anyway, I set my receiver to +9dB and started listening. Then suddenly, after one (automatic) track change, I heard extremely loud white noise through the speakers. My cat got scared and ran away really quick. I had to reboot the Wiim Pro Plus to be able to resume playback. This was the second time it happened today with DSD transcoding, but the first time, I didn't have to reboot the WiiM, and the zone I was playing in wasn't set to +9dB.

Has anyone else experienced this white noise problem ? It is a random inconsistent problem. Not sure why transcode would be any different than playing straight 192 kHz PCM files from JRiver. I don't have any of those, though. Maybe I need to do a file transcode of my SACD ISOs to PCM and try playing them to see if the problem happens again. I have never heard the white noise when transcoding within JRiver without streaming to Wiim - ie. using a local renderer.

[madbrain]

My enthusiasm for Wiim is waning a bit due to the issues trying to play DSD on it. Good thing my initial Ebay bid on ebay for 11 more units wasn't accepted. I have a reasonable counteroffer to respond to.

Anyway, I can't work around this white noise issue with on-the-fly DSD transcoding. Thinking 192 kHz might be an issue, I switched the on-the-fly DSD transcoding to PCM 24/96 kHz in MC, but unfortunately the extremely very loud white noise happened again after playing about 8 tracks. It seemed again to be at the beginning of a new track. I'm really concerned about blowing up ears/amps/speakers due to this problem, and I can't take the chance of it happening again.

Next, I did a DSD to PCM file transcoding with JRiver MC. I didn't specify any kHz sampling rate - didn't run DSP studio. This resulted in 352.8 kHz PCM stereo files. I was converting the Gould 1981 Goldberg SACD ISO to FLAC. I then played the entire 32-track album through the WiiM . I never once experienced the white noise issue. However, there were problems at the end of each track - clicks & pops during the last 3 seconds. This is not good, but nevertheless much better than the white noise I experienced with on-the-fly DSD conversion.

FYI, the WiiM DAC is supposed to accept up to 768 kHz PCM. I was pleasantly surprised it accepted the 352.8 kHz files as-is. I believe only the WiiM Pro Plus goes to 768 kHz, the Pro and Mini won't. The WiiM home Android app showed 352.8 kHz.

Right after this experiment, I played a regular album - CD 16 bit 44.1 kHz stereo in FLAC using MC31 onto the Wiim, and there were no gaps, clicks or pops at the end of any track - it was completely seamless.

I'll try converting the SACD again to a lower sampling rate than 352.8 - maybe 176.4 kHz or 88.2 kHz, and see if those clicks and pops disappear.

Edit: transcoded again to 176.4 kHz and it's playing fine - no gaps, pops, or clicks. Looks like DSD64 needs to be offline-transcoded to 176.4k on the Wiim right now. Not sure where the bug lies - on MC or Wiim side - but it's clear this combination was not tested by the Wiim folks.

[markf2748]

Thanks for all the detailed reporting on Wiim Pro Plus.  I'm pretty much limited to "redbook" 16-bit 44.1KHz, which I'm glad to hear you report works fine.

I see. Windows updates really are a PITA. I am going out of the country late next week and I hope that doesn't happen while I'm there. This is why I care about VPN access to MC.

Just a reminder that in Win 10/11 you can pause updates for up to 5 weeks (35 days), if that helps.  I don't know if pausing eliminates all problems, but it's free to try.

Re your experience of sudden loud volume white noise, MC has a setting Audio > Volume > Volume Protection.
https://wiki.jriver.com/index.php/Volume#Volume_Protection
Not sure it will protect you 100%, but may be worth checking that box while experimenting.

Re any tests involving Android apps, there may be differences between MO 4Media and JRemote2 (I am personally biased towards favoring the former).  For example, in my limited casting with JRemote2 it indicates "Transcoding 320 kbps MP3" at the bottom of the player window, while other apps as least show flac 44.1-16bit.  In any case, if you are not doing it already, then I'd suggest first testing Wiim DLNA directly from the MC server before bringing any Android app or casting into the loop.

[rec head]

I just bought my 3rd Wiim Pro and think they are pretty nice. I have old Chromecast Audio's, but they were always unreliable. It is a shame you need to get the Wiim Pro version to get CC. So far my main case has been to cast Audible to the 3 of them and it works great. Using Audible I have to cast my phone because the app doesn't support CC but it is hassle free. I have also cast music from MO4 and MC without issue. Using them as DLNA zones works well too. I find that having a CC group made for the speakers is easier than using the Wiim app to group them.

A funny note about the Wiim app is that it is just the generic app for the chipset or something. Other brands of streaming boxes use the same app.

[JimH]

For DLNA use, our IdPi would also be a good choice.  Connected to a DAC or receiver, you can play to it from MC and/or control it from a phone or other computer.

[madbrain]

Thanks for all the detailed reporting on Wiim Pro Plus.  I'm pretty much limited to "redbook" 16-bit 44.1KHz, which I'm glad to hear you report works fine.

You're welcome.

Just a reminder that in Win 10/11 you can pause updates for up to 5 weeks (35 days), if that helps.  I don't know if pausing eliminates all problems, but it's free to try.

Thanks, that is very helpful !

Re your experience of sudden loud volume white noise, MC has a setting Audio > Volume > Volume Protection.
https://wiki.jriver.com/index.php/Volume#Volume_Protection
Not sure it will protect you 100%, but may be worth checking that box while experimenting.

Thanks, I'll give it a shot.

Re any tests involving Android apps, there may be differences between MO 4Media and JRemote2 (I am personally biased towards favoring the former).  For example, in my limited casting with JRemote2 it indicates "Transcoding 320 kbps MP3" at the bottom of the player window, while other apps as least show flac 44.1-16bit.  In any case, if you are not doing it already, then I'd suggest first testing Wiim DLNA directly from the MC server before bringing any Android app or casting into the loop.

Thanks. As far as the white noise issue is concerned, I experienced it even when initiating playback directly from MC31 for Windows, selecting the Wiim DLNA source under "playing now". So, I don't think it's remote-related.

[madbrain]

There is also a very annoying fade-in / fade-out at the start/end of each track. Most inappropriate for classical. Not sure if there is a setting in the Wiim or Qobuz app to disable it - I haven't found it.

WiiM support found it for me - glad I was able to get rid of these. They responded to several other tickets as well, including the one about native DSD support, about which they said they were working on it, but they didn't provide a timetable.

[madbrain]

Using Audible I have to cast my phone because the app doesn't support CC but it is hassle free.

I have been using "cast my audio" CC feature for years as well, but found it unreliable. After some random amount of time, from a few minutes to tens of minutes, some jitter is introduced, and all audio audio remains jittery afterwards, with the only option being to stop and restart casting. Not hassle-free for me, sadly. It may be caused by some oddity with the 5 Unifi access points I'm using, only 2 of which are wired directly with Ethernet, and 3 wirelessly meshed. By comparison, casting directly from an app has different problems - some apps fail to cast, and of course there are gaps, but never jitter.

I have also cast music from MO4 and MC without issue. Using them as DLNA zones works well too. I find that having a CC group made for the speakers is easier than using the Wiim app to group them.

How hard is it to group in the Wiim home app ? I can't test this due to having only one Wiim device so far.
Do the Wiim speaker groups persist ? And do you get a DLNA renderer for the groups, so you can use them in MC ?

A funny note about the Wiim app is that it is just the generic app for the chipset or something. Other brands of streaming boxes use the same app.

Interesting. That's not good news WRT Wiim's ability to implement new features/fix bugs in the app. At the very least means some delay to deal with the third party who implements the app.

[madbrain]

Thanks, I'll give it a shot.

Since the volume protection is not part of DSP studio, I don't think it actually applies to on-the-fly DSD to PCM transcoding. Does it ? Edit: I enabled it, and unfortunately reproduced the white noise problem on the 4th track of an album. This time I was playing DSF files, transcoded to 24 bits/192k on the fly. I didn't use JRemote2, just MC on Windows, so I think remote does not play a part here in this problem.

[rec head]

How hard is it to group in the Wiim home app ? I can't test this due to having only one Wiim device so far.
Do the Wiim speaker groups persist ? And do you get a DLNA renderer for the groups, so you can use them in MC ?

Interesting. That's not good news WRT Wiim's ability to implement new features/fix bugs in the app. At the very least means some delay to deal with the third party who implements the app.

It is not hard at all to link the devices in the Wiim app. It is the speed and reliability of the linking that is in question. I'm coming from using Arylic streaming boxes that use the same app but their grouping was garbage. The Wiims are much better and I don't think I've had any problems but I think I still have a sour taste from using the app. I do believe the groups are persistent but I'm not 100% sure. Even when it is working at its best I still think that having CC groups is easier and faster. My use case is to have one group with all three devices or just one device at a time. I never need multiple different groups at the same time. I think your situation may be a bit more complex.

I just tested linking two of the Wiims and then used JRemote to play music via DLNA. It worked.

The app and devices have gotten regular updates.

[madbrain]

Even when it is working at its best I still think that having CC groups is easier and faster.

CC and CC groups have one common problem, which is the lack of gapless support. That is my main reason for buying the WiiM Pro Plus.

CCs also do not work reliably for me in all apps. One day they work, and the next day they don't. I haven't been able to figure out why, unfortunately. Seems to be something network related, but I'm at a loss.

My use case is to have one group with all three devices or just one device at a time. I never need multiple different groups at the same time. I think your situation may be a bit more complex.

Yes, it's a bit more complex. Some devices may belong to more than one group. For example, I have one group called "Downstairs audio", another "Upstairs audio", and one "Indoors audio" which is the combination of downstairs/upstairs devices. Ie. I have some devices that belong to multiple groups. Does the WiiM home allow that ?

I just tested linking two of the Wiims and then used JRemote to play music via DLNA. It worked.

Great !

The app and devices have gotten regular updates.

Yes, I have seen that. I just wonder if they have to run things by a 3rd party developer to fix the bugs. I am a software engineer and have worked with 3rd parties - it slowed things down because multiple companies don't have the same priorities.

[bob]

Responding to myself - a few more things. The Wiim app only works in portrait mode. Found that out the hard way on my tablet with its keyboard case, which is normally in landscape mode. Too bad, the keyboard comes really handy in searches, but I'm not going to rotate my head 90 degrees to use this app. Unfortunately the Samsung tab S9 ultra keyboard case only supports landscape.
At least the Qobuz app works in landscape mode, as does JRemote2.

Speaking of remotes, since that is the subject of this forum, I saw a few odd instances with all the remote apps. Sometimes they showed the wrong album/track name, but the correct timeline, and the controls worked. The track names weren't fixed when switching to the next track. Very odd.
It looks like I can reproduce the following way :
1) play an album from MC31 onto the WiiM using JRemote2
2) use the WiiM app to play an album from Qobuz on the Wiim
3) go back to JRemote2. It's still showing track names from the album from step 1. But the play controls work, track number updates, time updates as well. Even the track name changes, but to the track number from the other album. Not sure what happens if there is a disjoint number of tracks between the 2 albums and one goes "past the end". I just tried it actually. Played a 7 track organ album in step 1, up to track 3, and a 32 track piano album in step 3. Played track 12 on that second album. Then when I went back to JRemote2, it was still showing that it was the track 3 on the organ album, but with the time scale of the piano album, while hearing track 12 of the piano album. I use JRemote to skip tracks, and it went to track 4 of the organ album and played it. Anyway, there seems to be an issue with data not updating correctly when using the Wiim from multiple apps.

I also saw another situation where playback wasn't gapless with the wiim receiver, even though I was careful to select the DLNA receiver and not the built-in Chromecast. Not sure what that was about. I switch to another remote and the same album played gapless.

Lastly, after stopping playback in one remote, a few seconds later, the playback started again, presumably because of another remote app.

So, for now, I uninstalled MO4 Media and BubbleUPNP Android app from my tablet. I may uninstall them from my phone too. I also uninstalled the BubbleUPNP server on Windows. I'll keep just JRemote2 for browsing/playing my MC31 server content. It works well both on the phone and tablet, and on my WLAN and VPN.

There is no support in the DLNA protocol for multiple controllers.
When MC detects that a different controller has taken control of the rendering device, it stops being the controller and simply queries the device like every other non-controlled DLNA device for it's current status.

[madbrain]

There is no support in the DLNA protocol for multiple controllers.
When MC detects that a different controller has taken control of the rendering device, it stops being the controller and simply queries the device like every other non-controlled DLNA device for it's current status.

Thanks. I did not know that. I think I must have run into some sort of race condition when using the multiple remote apps. Maybe one of the apps failed to detect that it was no longer the controller. Or it decided to become the controller and start playback after I hit stop in the controller, for some reason. Just not sure, but it was disconcerting to press stop in one app and then hear playback resume all on its own a few seconds later. I don't even know which of the other remote apps initiated the resume, since I had 3 remote apps installed. I can say that it hasn't happened again since I went down to 1 remote app - JRemote2.

[rec head]

The Wiims allow you to link devices but AFAIK you can't create fixed groups. So every time you want to play to certain devices you need to link them. They should be persistent until a Wiim is powered off.

[madbrain]

The Wiims allow you to link devices but AFAIK you can't create fixed groups. So every time you want to play to certain devices you need to link them. They should be persistent until a Wiim is powered off.

Thanks. That sounds unfortunate. I may put all my WiiMs on UPSes in that case so they don't get powered off and lose the groups. Seems a feature request to WiiM support will be in order.

[rec head]

I have a feeling I'm going to learn a lot about these devices once you start setting them up. I'm looking forward to you trying to squeeze more out of them than I do.

[dtc]

I have been working on integrating my Wiim Mini with my Sonos system.The Wiim is connected to a DAC, integrated amp and standard speakers. It plays up to 192 KHz as long as you have an optical cable that passes 192 KHz. I also have a Sonos setup by the pool which I want to use along with the Wiim. The Sonos pool speakers are set as a group in Sonos so you only have to play to one of them and Sonos plays to all speakers in the group. So, I link the Wiim and one of the Sonos speakers in MC and the audio plays on both my standalone system and on the Sonos group. The Sonos speakers are in sync, but they do not sync with the standalone system, which I expected, since MC cannot sync 2 separate DLNA outputs. But, you cannot hear the two different systems simultaneously so they do not need to be in sync.  You do have to be sure to not send hi rez sample rates to the Sonos group, so you do have to down sample any hi rez to 44.1 KHz. I have not done a lot of testing with the various JRiver remotes and I am not sure how they work with linked outputs. But it works from my Windows PC.  Just started this experiment but the initial results are encouraging.