Casting to Raspberry Pi

[aurobindosaha]

Hi Streamer Gurus,

Need your expertise to understand the following situation.

Context: I use Swara Streamer that runs RuneAudio. Swara Streamer is a RaspberryPi HATs on Corrson DAC and has excellent linear power supply.

I send Google music to it through Bubbleupnp. And I wish I can stream more sources. (See below)

Questions:
1. The reason I needed to bring Bubbleupnp in between a streaming service and Swara Streamer is because Google Music can not cast directly to RaspberryPi. However Google music can directly cast to my Google Home mini device. There must be a reason why Google can not directly cast to Pi, even though all sits on same WiFi.


2. Such streaming ... either directly or through Bubbleupnp fails for Jio music or Amazon music. Another bummer.
Any idea why it fails? (Error displayed: no http stream found)

3. Am I losing SQ in the pipeline (Google Music>Bubbleupnp>Pi>DAC) ?

4. For some reason, RuneAudio app can not read my Bubbleupnp library, nor Bubbleupnp can read RuneAudio MDP. Any idea how to fix it?

 

[manju_rn]

Dunno about Swara Streamer, but would suggest to try Volumio, any MPD client can control it. I use HI fi cast to control volumio hosted in RPI. Volumio is a headless (buiilt on raspian) and automatically detects most of the DAC.

 

[z@m]

Your setup is attempting a complex protocol dance with two left feet.

I've encountered varying grades of success with volumio, musicbox, kodi, streaming apple music, spotify, tunein, gaana, etc. on an RPi+I2S dac but am yet to find some combination that is reliable enough for a senior parent to use without hassle.

If you've spent more than a fair amout of time exploring workarounds only to realize that that's what they'll always remain - fickle workarounds, welcome to the club. For all it's hype and seeming popularity, the RPi's ARM doesn't handshake very well (pun!) on account of its proprietary nature.

Seeing as you're invested in Google's offerings, maybe consider pairing them with a chromecast/cc-audio for hassle-free integration? It might cost you the use of your dac but you'll achieve the prime aim: tinker-free streaming. Or you could restrict the ARM to dac duty and assign networking to a x86 device like iball's splendo or Intel's compute stick.

 

[amit11]

3. Am I losing SQ in the pipeline (Google Music>Bubbleupnp>Pi>DAC) ?

Yes, losing SQ. Most android have 48 khz instead of 44.1
Secondly some DSP is being done by Google music app itself.

The problem with chromecast audio is we cannot stream YouTube.

In my opinion android simply does not cut for hifi.


PS: i think both my above points may not be valid.. i had read in the past about these issues hence i mentioned. I was reading recently so these issues might not be there now.

 

[aurobindosaha]

Your setup is attempting a complex protocol dance with two left feet.

I've encountered varying grades of success with volumio, musicbox, kodi, streaming apple music, spotify, tunein, gaana, etc. on an RPi+I2S dac but am yet to find some combination that is reliable enough for a senior parent to use without hassle.

If you've spent more than a fair amout of time exploring workarounds only to realize that that's what they'll always remain - fickle workarounds, welcome to the club. For all it's hype and seeming popularity, the RPi's ARM doesn't handshake very well (pun!) on account of its proprietary nature.

Seeing as you're invested in Google's offerings, maybe consider pairing them with a chromecast/cc-audio for hassle-free integration? It might cost you the use of your dac but you'll achieve the prime aim: tinker-free streaming. Or you could restrict the ARM to dac duty and assign networking to a x86 device like iball's splendo or Intel's compute stick.

Hi z@m

Nice analogy. Thanks. I atleast know others have tried this and is facing similar challenges.

I will try volumio. RuneAudio is littles dated, and there are hardly any updates now a days.

By the way, I like your suggestion about Chromecast, but output of Chromecast is analogue ... Meaning the DAC operations are already happening within the chromecast device. I do not know how good is that DAC. I would like to use the one I have, hence digital output is a must need for my streaming device.

But thank you for sharing your thoughts.

Thanks
Auro

 

[aurobindosaha]

Yes, losing SQ. Most android have 48 khz instead of 44.1
Secondly some DSP is being done by Google music app itself.

The problem with chromecast audio is we cannot stream YouTube.

In my opinion android simply does not cut for hifi.


PS: i think both my above points may not be valid.. i had read in the past about these issues hence i mentioned. I was reading recently so these issues might not be there now.

Hi amit11,
Thanks for your reply. But I am still not very convinced. On your point about SQ, the Android will is not doing digital to analogue conversions ... Right. Android is sending 0s and 1s (digital) data to RaspberryPi and the DAC which HATs on the Raspberry Pi does the conversion. Isn't it? So how am I losing on SQ? If you say digital recording quality of music in Google Music is worse than others, then I agree, the source is problematic ... And I will be better of choosing another source.

You emphasize on Android not fit for Hifi .... But the role of Android is just to get digital signal from internet and send it to Pi. If it's role is mare transportation of digital signal and no conversion, then why is it so important for SQ?

You mentioned, you can not stream YouTube using Chromecast. I have no experience with Chromecast but my device which is a RaspberryPi can receive YouTube audio easily using Bubbleupnp. Bubble upnp is a dlna enabled app that connects what I share via YouTube or Google Music to RaspberryPi.

Thanks
Auro

 

[amit11]

Android is sending 0s and 1s (digital) data to RaspberryPi and the DAC which HATs on the Raspberry Pi does the conversion. Isn't it? So how am I losing on SQ?


You emphasize on Android not fit for Hifi .... But the role of Android is just to get digital signal from internet and send it to Pi. If it's role is mare transportation of digital signal and no conversion, then why is it so important for SQ?

The problem lies what android does before sending 0 and 1.
Most android phones (if not all) have native audio drivers for 48 khz and not 44.1 khz. So the audio is first converted from 44.1 to 48. That itself is the stupidest thing which shows that android does not have the vision neither the art in its design.

Secondly, in terms of streaming, there is no standard inherent functionality which allows any music app or for that matter their own you tube app to stream at the touch of a button. Just to stream people have to install various apps will act as music players, each having its own variety.


Thirdly any player on android, does digital processing before outputting either analog or even outpouring digital 0 and 1. That is to say the streaming is not bit perfect.

Fourthly i nevet came across a decent app on android which plays music in a decent manner. Point #1 is the main culprit which is a deal breaker. (44.1 to 48).

Fifth i had even tried USB audio pro which has a separate driver for 44.1. But still it did not cut.

In short my experience is Android is more technical in nature and not for musicality. If you might have used apple ipods in the past, or airplay then you can get the feeling that android cannot be compared.

 

[aurobindosaha]

Now I understand. Good explanation. Thank you Amit.

If I download high quality flacs from sites like hdtrack.com, copy that to usb drive and attach that to RaspberryPi (that is I will not doing any streaming) .... Will that solve these issues?

But in this imperfect world of streaming - what is your recommendation? How should we be using streaming service so that SQs are not degraded?

Thanks
Auro

 

[aurobindosaha]

B

The problem lies what android does before sending 0 and 1.
Most android phones (if not all) have native audio drivers for 48 khz and not 44.1 khz. So the audio is first converted from 44.1 to 48. That itself is the stupidest thing which shows that android does not have the vision neither the art in its design.

Secondly, in terms of streaming, there is no standard inherent functionality which allows any music app or for that matter their own you tube app to stream at the touch of a button. Just to stream people have to install various apps will act as music players, each having its own variety.


Thirdly any player on android, does digital processing before outputting either analog or even outpouring digital 0 and 1. That is to say the streaming is not bit perfect.

Fourthly i nevet came across a decent app on android which plays music in a decent manner. Point #1 is the main culprit which is a deal breaker. (44.1 to 48).

Fifth i had even tried USB audio pro which has a separate driver for 44.1. But still it did not cut.

In short my experience is Android is more technical in nature and not for musicality. If you might have used apple ipods in the past, or airplay then you can get the feeling that android cannot be compared.

By the way I was reading about the DAC used in my phone ... Xiaomi Mi Note 4. They use 32 bit ES9018K2M DAC from Texas Instruments 192kHz/24 bit sampling, which they claim 4 times better than CD quality.

Details here
https://www.mi.com/en/minote/hifi/

Thanks
Auro

 

[amit11]

If I download high quality flacs from sites like hdtrack.com, copy that to usb drive and attach that to RaspberryPi (that is I will not doing any streaming) .... Will that solve these issues?

But in this imperfect world of streaming - what is your recommendation? How should we be using streaming service so that SQs are not degraded?

Direct usb should be better. However again the next thing is how good the player in PI is. Whether it does any change by digital singnal processing (DSP) or not.

The audio chip in your phone has 44.1 and 48 both. I assume android is passing it 44.1. However the chip is upsampling 4 times, That's why they are claiming 4 times better than CD. However its far from true. Why? Bcos that depends on how they upsample 4X times. The formulas, mathematics etc used Changes the audio sound, which can be likeable or irritating. That's why there are so many chips and dacs, which apply this creativity in various ways.

Which is best way to stream? Difficult to answer as i myself am searching for the answer. But for sure android is a no-no. I use apple and airplay with airport express ( 15 year old model airport express, not the latest ones). I find that to my satisfaction. Other many solutions which i tried, 10 minutes and they are out of my room. With apple i dont have to download any app for streaming. It can stream anything that can be played on it. Even youtube, saavn, ... you name i and it can stream.... why? Bcos that's how apple was designed. (Unlike android... which does not have the art and such kind of vision)

 

[bornfi]

Hi Streamer Gurus,

Need your expertise to understand the following situation.

Context: I use Swara Streamer that runs RuneAudio. Swara Streamer is a RaspberryPi HATs on Corrson DAC and has excellent linear power supply.

I send Google music to it through Bubbleupnp. And I wish I can stream more sources. (See below)

Questions:
1. The reason I needed to bring Bubbleupnp in between a streaming service and Swara Streamer is because Google Music can not cast directly to RaspberryPi. However Google music can directly cast to my Google Home mini device. There must be a reason why Google can not directly cast to Pi, even though all sits on same WiFi.


2. Such streaming ... either directly or through Bubbleupnp fails for Jio music or Amazon music. Another bummer.
Any idea why it fails? (Error displayed: no http stream found)

3. Am I losing SQ in the pipeline (Google Music>Bubbleupnp>Pi>DAC) ?

4. For some reason, RuneAudio app can not read my Bubbleupnp library, nor Bubbleupnp can read RuneAudio MDP. Any idea how to fix it?

My long journey with digital media suggests that any wireless connection degrades the quality. Unless I am missing something, your Raspberry Pi is a computer and you should also have an internet browser using which you can access any content you want and that would be the best way to enjoy the music.

Again, this is my personal opinion. Try both wired and wireless connection, I am sure you will hear the difference and if that difference is not that great enough to shift to a different way you enjoy your music, remain stuck to wireless as it is convenient.

All these wireless interconnectivity is about monopolising the market such as Apple's Airplay does not work on all devices however; I am confident, that somewhere in the network protocol they all use the same tech with different kinds of locks and protection. The common/universal gateway is USB and you will somehow have to harness that route.

 

[amit11]

What usb passes over wire, with bursts of information each millisecond, airplay does it over the air without the bursts. In my opinion the 1 millisecond bursts do not bring out the musicality... it sounds flat and lifeless. It may not be in all cases but yes this is still under maturity. I would say that bluetooth though it may compress the sound, is more mature and musical then a standard usb implementation.

 

[z@m]

@aurobindosaha

By the way, I like your suggestion about Chromecast, but output of Chromecast is analogue ... Meaning the DAC operations are already happening within the chromecast device.

While sub-optimal from an SQ standpoint, the CCAudio features optical output. If your PiHat DAC accepts toslink, you're looking at a suitable solution.