Upgrading an old digital audio system to bluetooth wireless?

[adrianajones]

I'm trying to upgrade an older audio theater system with Bluetooth, so I can play music from my phone. Anybody have any experience with upgrading an older systems as such?

I'm stuck trying to decide between these two brands. One is Bose and the other is from another good Amazon brand that's a bit more affordable, although the product is new on the market.

https://kinivo.com/product/btr200-hd-bluetooth-audio-receiver/

https://www.bose.com/products/speaker_accessories/bose-bluetooth-audio-adapter.html#v=bluetooth_adapter_ht_acc_black

[Audio_ELF]

Computer Audiophile - Audioengine B1 Bluetooth Receiver review Might interest you.

[master]

Actually Bluetooth is extremely limited. You are better off using something like Chromecast Audio.

 

What is the old system you are trying to upgrade?

 

Chromecast Audio pretty much supports all inputs, analog and digital, so it should work with even with old hi-fi equipment.

[markebrauer]

Actually Bluetooth is extremely limited. You are better off using something like Chromecast Audio.

 

What is the old system you are trying to upgrade?

 

Chromecast Audio pretty much supports all inputs, analog and digital, so it should work with even with old hi-fi equipment.

 

I've had my Chromecast Audio for a couple months and agree that it is great. The fact that is does not compress - or re-compress - the audio data gives it the potential for much better sound than Bluetooth. And unlike Bluetooth, once you start "casting" there can be basically no drain on the phone battery. You can also leave the room, or even turn the phone off, and the music keeps playing. And activity on the phone - calls/alarms/notifications/etc - does not interrupt the music.

 

but...

 

You need a WiFi network for Chromecast to work at all. You also need a phone new enough to support the Google casting protocols. And for the most part casting is aimed at playing music stored remotely - i.e. not on your phone - a service like Spotify, or music stored on a DLNA/UPnP server running on your WiFi network through a DLNA/UPnP app on the phone. You can cast directly from your phone but that does eat battery in a big way and requires that the phone be turned on and remain in the WiFi network.

 

That said, the latest Bluetooth is reported to sound quite good. Even the older Bluetooth devices I have sound "good enough" for my uses.

[adrianajones]

Hmm that's a lot to consider. How much more expensive is Chromecast? I'm sure it has more uses than just audio, right?

 

I've had my Chromecast Audio for a couple months and agree that it is great. The fact that is does not compress - or re-compress - the audio data gives it the potential for much better sound than Bluetooth. And unlike Bluetooth, once you start "casting" there can be basically no drain on the phone battery. You can also leave the room, or even turn the phone off, and the music keeps playing. And activity on the phone - calls/alarms/notifications/etc - does not interrupt the music.

 

but...

 

You need a WiFi network for Chromecast to work at all. You also need a phone new enough to support the Google casting protocols. And for the most part casting is aimed at playing music stored remotely - i.e. not on your phone - a service like Spotify, or music stored on a DLNA/UPnP server running on your WiFi network through a DLNA/UPnP app on the phone. You can cast directly from your phone but that does eat battery in a big way and requires that the phone be turned on and remain in the WiFi network.

 

That said, the latest Bluetooth is reported to sound quite good. Even the older Bluetooth devices I have sound "good enough" for my uses.

[markebrauer]

Hmm that's a lot to consider. How much more expensive is Chromecast? I'm sure it has more uses than just audio, right?

 

The kicker is the Chromecast Audio costs only $35 and does much of what you had to pay hundred$, if not thou$and$ for not to long ago. It's so cheap that if you have the WiFi and a cast-capable device, there's no reason not to get one.

https://store.google.com/product/chromecast_audio

 

And the Chromecast Audio really only does audio. There's a regular Chromecast that's designed for video which can also do audio but only through an HDMI connection.

[Audio_ELF]

And the Chromecast Audio really only does audio. There's a regular Chromecast that's designed for video which can also do audio but only through an HDMI connection.

Does not the application you are wanting to send audio from need to support Chromecast though? Thats vs bluetooth where literally all audio from your phone / tablet / computer can be sent.

 

Not saying one is better, just they are not quite identical.

[master]

I've had my Chromecast Audio for a couple months and agree that it is great. The fact that is does not compress - or re-compress - the audio data gives it the potential for much better sound than Bluetooth. And unlike Bluetooth, once you start "casting" there can be basically no drain on the phone battery. You can also leave the room, or even turn the phone off, and the music keeps playing. And activity on the phone - calls/alarms/notifications/etc - does not interrupt the music.

 

but...

 

You need a WiFi network for Chromecast to work at all. You also need a phone new enough to support the Google casting protocols. And for the most part casting is aimed at playing music stored remotely - i.e. not on your phone - a service like Spotify, or music stored on a DLNA/UPnP server running on your WiFi network through a DLNA/UPnP app on the phone. You can cast directly from your phone but that does eat battery in a big way and requires that the phone be turned on and remain in the WiFi network.

 

That said, the latest Bluetooth is reported to sound quite good. Even the older Bluetooth devices I have sound "good enough" for my uses.

 

Quite right on all points, except the last one. Bluetooth is limited to 340 kbps and while that's fine for streaming radio and the likes of Spotify, it's a big fail for streaming FLAC. That pretty much rules out Tidal as well as FLAC and CD rips at home.

 

Guess it all comes down to the actual content, and I am not saying I have anything against Spotify and/or MP3 rips. I however did have bandwidth issues when streaming my rips to Bluetooth speakers. That's one reason I'm so much sold on Chromecast Audio, it solved all problems and even gave new life to old hi-fi equipment.

 

Hmm that's a lot to consider. How much more expensive is Chromecast? I'm sure it has more uses than just audio, right?

 

You need to jump on it ASAP. It's a game changer in every aspect.

[Cebolla]

Guess it all comes down to the actual content, and I am not saying I have anything against Spotify and/or MP3 rips. I however did have bandwidth issues when streaming my rips to Bluetooth speakers. That's one reason I'm so much sold on Chromecast Audio, it solved all problems and even gave new life to old hi-fi equipment.

 

You need to jump on it ASAP. It's a game changer in every aspect.

Last time I looked into Chromecast Audio, I found out that it didn't support gapless playback of music files, eg, this relatively recent post on the Hydrogenaudio forums from Bubbleguuum, the developer of the excellent BubbleUPnP Android app (one of its features is that it provides Chromecast devices the ability to stream media files from UPnP/DLNA media servers):

https://www.hydrogenaud.io/forums/index.php?showtopic=110158&view=findpost&p=908991

 

Is this still the case?

[markebrauer]

Does not the application you are wanting to send audio from need to support Chromecast though? Thats vs bluetooth where literally all audio from your phone / tablet / computer can be sent.

 

Not saying one is better, just they are not quite identical.

 

Actually, the two technologies are nowhere near identical.

 

Yes, apps can have the ability to cast on their own but newer devices can also have the ability to cast any and all audio built right in. Androids (I believe starting with 4.4) have native casting. Mine is a Android 5.0 device and once I turn on the casting utility it casts the audio from web pages or music players or videos. I can, for instance, listen to the samples from the HDTracks site played through my main system, or the audio portion of YouTube videos, or the weather forecast from my local TV station's web page.

 

When playing audio that is "on" a web page, casting sets up a connection directly from the web to the Chromecast, routing the audio portion of the feed to the Chromecast Audio. The phone (or whatever) is out of the loop at that point, unless it is used as a remote to change what's playing. Very easy on the battery.

 

By installing software like BubbleUPnP or LocalCast on a an Android one can also set up a casting connection from audio files on a DLNA/UPnP server that is running on the local WiFi network.

 

When playing audio that resides on the device using a local music app, casting sets up a connection from the device to the Chromecast. In this case the phone (or whatever) is in the loop and does use battery power to keep things going. BubbleUPnP can also be used to play audio files residing on the device or in the cloud (Google Drive, Dropbox, etc) but that also appears to use phone battery.

 

As a side point, there is also an extension for the Chrome browser on a PC or Chromebook that enables casting audio from any web page.

 

I have no Apple devices so can't comment on how this stuff works with them but my understanding is that these same things can be done.

 

So, as you can see, casting is way more complicated than Bluetooth. But it is way more capable and versatile. All the explanations above are really unnecessary. While it took me a few hours of poking around and reading to understand how casting works (and I'm still not sure I have all the details correct) it took only minutes to have it up and casting things from my phone. And only a few minutes more to install BubbleUPnP to be playing files from my music server and Google Drive. It's not at all necessary to understand how it works, only that it does. And it's easy, like Bluetooth.

 

The thing only costs $35! Just buy one and have some fun.

[Cebolla]

When playing audio that is "on" a web page, casting sets up a connection directly from the web to the Chromecast, routing the audio portion of the feed to the Chromecast Audio. The phone (or whatever) is out of the loop at that point, unless it is used as a remote to change what's playing. Very easy on the battery.

 

By installing software like BubbleUPnP or LocalCast on a an Android one can also set up a casting connection from audio files on a DLNA/UPnP server that is running on the local WiFi network.

 

When playing audio that resides on the device using a local music app, casting sets up a connection from the device to the Chromecast. In this case the phone (or whatever) is in the loop and does use battery power to keep things going. BubbleUPnP can also be used to play audio files residing on the device or in the cloud (Google Drive, Dropbox, etc) but that also appears to use phone battery.

Is the battery drain present on the Android device when using the BubbleUPnP app for streaming by ChromeCast Audio from a UPnP/DLNA media server on the network (ie not from local files nor from cloud files with connection to service setup by BubbleUPnP)?

 

Incidentally, have you found if Chromecast Audio supports gapless playback when streaming music files from any source (so including more native sources, such as Google Play Music, not just the indirect methods mentioned above)?

[master]

Last time I looked into Chromecast Audio, I found out that it didn't support gapless playback of music files, eg, this relatively recent post on the Hydrogenaudio forums from Bubbleguuum, the developer of the excellent BubbleUPnP Android app (one of its features is that it provides Chromecast devices the ability to stream media files from UPnP/DLNA media servers):

https://www.hydrogenaud.io/forums/index.php?showtopic=110158&view=findpost&p=908991

 

Is this still the case?

 

Hi Cebolla,

 

I in fact use BubbleUPnP myself and stream off a NAS, UPnP/DLNA server from the NAS, and UPnP server from Foobar.

 

However, I have not seen an option for gapless playback in BubbleUPnP (don't use it myself).

 

Let me get back to you on this, I will see if it is an option on Foobar and/or BubbleUPnP. Or maybe another app with this feature.

[master]

Is the battery drain present on the Android device when using the BubbleUPnP app for streaming by ChromeCast Audio from a UPnP/DLNA media server on the network (ie not from local files nor from cloud files with connection to service setup by BubbleUPnP)?

 

No battery drain when playing off a local network device/NAS. I even tested with turning off the phone and it kept right on playing. Think of the Chromecast as a headless PC, but in this case the smartphone is not only the monitor, but also the keyboard and the mouse.

 

I haven't tested with cloud storage like Dropbox or Google Drive, but I don't see why that too will not keep the phone out of the loop. My thinking is only content stored on the phone should drain the battery. Obviously will need to test it out, but my main requirement has been playing off my local NAS as well as Tidal and Spotify to some extent.

[Cebolla]

Hi Cebolla,

 

I in fact use BubbleUPnP myself and stream off a NAS, UPnP/DLNA server from the NAS, and UPnP server from Foobar.

 

However, I have not seen an option for gapless playback in BubbleUPnP (don't use it myself).

 

Let me get back to you on this, I will see if it is an option on Foobar and/or BubbleUPnP. Or maybe another app with this feature.

I already know that gapless playback under UPnP/DLNA is supported by the BubbleUPnP app, but it requires the streamer that it is controlling to also support gapless. The UPnP/DLNA media server (such as the one on your NAS or the one provided by Foobar2000 with the foo_UPnP plugin component) being used is actually irrelevant to gapless support, as the mechanism used by standard UPnP/DLNA only involves the controller app and the streamer (aka renderer).

 

Hence, it's the Chromecast Audio streaming device itself that needs to support gapless.

[Cebolla]

No battery drain when playing off a local network device/NAS. I even tested with turning off the phone and it kept right on playing. Think of the Chromecast as a headless PC, but in this case the smartphone is not only the monitor, but also the keyboard and the mouse.

 

I haven't tested with cloud storage like Dropbox or Google Drive, but I don't see why that too will not keep the phone out of the loop. My thinking is only content stored on the phone should drain the battery. Obviously will need to test it out, but my main requirement has been playing off my local NAS as well as Tidal and Spotify to some extent.

Excellent, in which case it looks like the Chromecast Audio device caches the entire playlist being used on the BubbleUPnP app, for this to work. The music tracks in the cached playlist would contain the URL links to the actual music files being provided by the UPnP media server on the local network, so would no longer require the BubbleUPnP app to act as the go between.

 

However, @markbrauer does mention battery drain when using the BubbleUPnP app specifically when the BubbleUPnP app is also providing the internet connection to (ie logging into) the cloud services being used. This would mean that connection can only remain open with the Android device still on and the BubbleUPnP app still running.

[markebrauer]

Last time I looked into Chromecast Audio, I found out that it didn't support gapless playback of music files, eg, this relatively recent post on the Hydrogenaudio forums from Bubbleguuum, the developer of the excellent BubbleUPnP Android app (one of its features is that it provides Chromecast devices the ability to stream media files from UPnP/DLNA media servers):

https://www.hydrogenaud.io/forums/index.php?showtopic=110158&view=findpost&p=908991

 

Is this still the case?

 

I cannot claim to understand what combination of hardware and software makes gapless playback possible but...

 

I to read things indicating that Chromecast Audio was not gapless so I decided to test for myself.

 

First I used my Android running SqueezePlay which sets up the Android to emulate a hardware Squeezebox player. I also started up OrangeSqueeze app to use as a Squeezebox controller. These two interact with Logitech Media Server running on my local network.

 

I turned on the casting function on my Android 5.1 device and selected the Chromecast as the target.

 

I then queued up a number of albums that have continuous sound from track to track, live concerts and classical pieces. I could not detect any gaps. The audio was continuous. That's not to say there aren't millisecond gaps, just that I couldn't hear them and they did not detract from the music.

 

I shut those apps down and started up the Android Spotify app, with gapless set to "on". Playing some of the same material resulted in small but very noticeable gaps

 

I then tried BubbleUPnP streaming from my media server. Definitely gaps. Big ones.

 

So, is it the hardware or software?

[Cebolla]

Your test using the casting function was just a sound capture of the SqueezePlay Squeezebox emulator's playback output. So it was the SqueezePlay that was actually handling the gapless playback of the music files from the LMS, not the Chromecast Audio device!

 

From what @master has mentioned, it looks like the Chromecast Audio device actually contains a copy of the music file playlist, when it is being used to directly playback music files (ie not with the casting/sound capture function). If this is the case, then gapless playback support of the Chromecast Audio device must need to be entirely in hardware, as it needs no interaction with anything other than the server that it's getting the files from.

[master]

Excellent, in which case it looks like the Chromecast Audio device caches the entire playlist being used on the BubbleUPnP app, for this to work. The music tracks in the cached playlist would contain the URL links to the actual music files being provided by the UPnP media server on the local network, so would no longer require the BubbleUPnP app to act as the go between.

 

However, @markbrauer does mention battery drain when using the BubbleUPnP app specifically when the BubbleUPnP app is also providing the internet connection to (ie logging into) the cloud services being used. This would mean that connection can only remain open with the Android device still on and the BubbleUPnP app still running.

 

Your test using the casting function was just a sound capture of the SqueezePlay Squeezebox emulator's playback output. So it was the SqueezePlay that was actually handling the gapless playback of the music files from the LMS, not the Chromecast Audio device!

 

From what @master has mentioned, it looks like the Chromecast Audio device actually contains a copy of the music file playlist, when it is being used to directly playback music files (ie not with the casting/sound capture function). If this is the case, then gapless playback support of the Chromecast Audio device must need to be entirely in hardware, as it needs no interaction with anything other than the server that it's getting the files from.

 

From what I understand (and I think I picked this up from a TWiT TV talk) the Chromecast receives instructions from the smartphone or tablet and does all the heavy lifting itself. In other words if you are casting from the Spotify app then Chromecast actually goes online, connects to Spotify and plays the tracks. Given this scenario I can understand Chromecast connecting to the external NAS and playing the tracks as a device as opposed to caching the playlist.

 

That is why the analogy of a headless PC for the Chromecast. It does the playing, but needs input from an external device.

[Cebolla]

Not sure if you understand what I mean by 'caching the playlist'. Having an internal playlist to work with certainly doesn't stop the Chromecast Audio device from accessing an external device in order to play music files from it!

 

If the Chromecast Audio device didn't cache the playlist (ie be given a complete copy of the playlist) from the BubbleUPnP app, how else would you explain it carrying on playing all the music tracks left in the BubbleUPnP app's current playlist after the BubbleUPnP app has shut down?

[markebrauer]

Your test using the casting function was just a sound capture of the SqueezePlay Squeezebox emulator's playback output. So it was the SqueezePlay that was actually handling the gapless playback of the music files from the LMS, not the Chromecast Audio device!

 

That explains it, thanks.

[master]

Not sure if you understand what I mean by 'caching the playlist'. Having an internal playlist to work with certainly doesn't stop the Chromecast Audio device from accessing an external device in order to play music files from it!

 

If the Chromecast Audio device didn't cache the playlist (ie be given a complete copy of the playlist) from the BubbleUPnP app, how else would you explain it carrying on playing all the music tracks left in the BubbleUPnP app's current playlist after the BubbleUPnP app has shut down?

 

You are right.

 

I'm not even sure if Chromecast Audio works the same, the analogy regarding the headless PC was for Chromecast when playing something like Netflix.

 

Could be the same though.

 

My personal findings have been that Chromecast Audio takes things up a notch. It's not just in terms of features and functionality, but I have always preferred optical over both coaxial and especially USB. Chromecast Audio via optical to the DAC, AVR, etc. is what sounds best to me.

 

Lay it down to personal preference, I have mid-fi equipment at best, not the gold standard for audiophile equipment.