Print

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

[Denti]

I see that using Raspberry Pi with JRiver Linux version is now possible. A couple questions:

1. If I have MC Linux installed on the Raspberry Pi, should I get full audio functionality so long as it's connected to a MC server elsewhere on my network?

2. Do I need to get the HiFiBerry Digi+ board (http://www.hifiberry.com/digiplus/) to be able to output 24/192 to my external DAC? Or can I do this via USB on the regular Raspberry Pi?

3. Is there a good walk through for installation for someone who has no Linux experience?

[JimH]

We have it running but it isn't publicly available yet.  It's too early to be able to say much about it.

[Denti]

We have it running but it isn't publicly available yet.  It's too early to be able to say much about it.

What does the "it" here refer to? What isn't publicly available?

[mwillems]

I think the "it" in Jim's comment is an ARM build of JRiver. The currently released version of JRiver for Linux's official requirements are an x86 processor with SSE2, which rules out the Pi for the moment.

Raspberry Pis are not x86 compatible computers, so just because software is linux-compatible does not mean it will run on the Pi.  Pi's can run modified versions of linux that are designed to work on ARM processors, and can run software that is built to run on ARM.  That's currently a somewhat limited group of OS's and software.  As the wiki notes "The ARM11 chip at the heart of the Pi is based on version 6 of the ARM. The current releases of several popular versions of Linux, including Ubuntu will not run on the ARM11. It is not possible to run Windows on the Raspberry Pi [emphasis added]."  The Debian project has a fork especially for the Pi, but it's not exactly the same OS as mainstream Debian.   

[astromo]

An R-Pi version was first mooted on Interact (that I recall anyway) back in July:
Build for arm processors

Then Hendrik said he was having a dabble. Check the thread. That goes back to August.

It's been rather quiet. And I've noted that Jim and the JRiver crew prefer to undersell themselves and then deliver the goods to a timeplan that they have confidence in.

There's one thing I am sure of though, if/when an ARM build is ready for release it will be mostly functional and you'll know about it. You'll be a person of value because you'll (hopefully) be at the forefront helping with user feedback.

Given the development these guys have been pushing over the last year or so, they're going great guns rolling out Mac, Linux, the Id, Pono (work in progress). The first 2 have video capability which was a pleasant surprise that it came around so soon.

That all being said, I enjoy reading about what's next and it's a positive that the devs get a prod every now and then. Catch you come test time. I've got a little R-Pi that would be cool to get MC on to..  

[Denti]

Thanks, guys. Googling turns up threads on other forums where people appear to have successfully installed MC on a R-Pi... that's what got me curious.

[astromo]

Thanks, guys. Googling turns up threads on other forums where people appear to have successfully installed MC on a R-Pi... that's what got me curious.

Seriously?

Please provide at least 1 link. How did they fare?

[JimH]

I think someone posted a few months ago (here, too) about using a Pi as a DLNA Renderer with MC's DLNA Server.  The server was running on an Intel based machine.

[Denti]

http://yabb.jriver.com/interact/index.php?topic=89044.0

http://www.audioaficionado.org/cd-players-digital-music-servers/28147-raspberry-pi-jriver-music-server.html

[mwillems]

http://yabb.jriver.com/interact/index.php?topic=89044.0

http://www.audioaficionado.org/cd-players-digital-music-servers/28147-raspberry-pi-jriver-music-server.html

In the first thread the poster is using the RPi as a DLNA renderer, the RPi is not running JRiver.  He's using JRiver on another computer to stream music to the RPi.  I suspect that something similar is happening in the other thread, but it's a little harder to follow.

[Denti]

In the first thread the poster is using the RPi as a DLNA renderer, the RPi is not running JRiver.  He's using JRiver on another computer to stream music to the RPi.  I suspect that something similar is happening in the other thread, but it's a little harder to follow.

I don't think I ever understood what the advantages/disadvantages to using DLNA are. Can someone explain this to me?

I have an old HTPC that I use as my "server." It's got MC installed and all the music is there on HDDs. Then I have a Nuc in the other room with MC installed. When I play music from that Nuc I'm using MC, but getting the library from the server. If I didn't have MC installed, I could still play *to* the NUC from the server. What changes, other than what MC is actually playing?

[JimH]

If you can use MC on both sides, you don't need to use DLNA, but a lot of devices (TV's and Blu-ray players, for example) support DLNA.

[Denti]

If you can use MC on both sides, you don't need to use DLNA, but a lot of devices (TV's and Blu-ray players, for example) support DLNA.

So a NUC with some DNLA renderer software would work, even without MC installed? Any sound quality drawbacks?

I ask to consider building a R-Pi and have a way to play MC while waiting for the software to be released.

[JimH]

Yes, any DLNA theoretically should work. 

[Denti]

Yes, any DLNA theoretically should work. 

Sound quality the same? The first link I posted suggests it's not perfect. Why wouldn't it be basically the same?

[JimH]

The sound quality will be related to whatever file type is delivered to the Renderer.  If the Renderer is capable of high quality and the Server isn't converting, high quality files will be played.

[6233638]

The Raspberry Pi 2 is now available and seems to be a huge upgrade, at the same price as the original: http://www.raspberrypi.org/raspberry-pi-2-on-sale/
It also supports Windows 10? http://dev.windows.com/en-us/featured/raspberrypi2support

[Hendrik]

If there is a ARM version of MC at some point in the future, its quite likely that it will in fact require ARMv7, since thats a much more modern instruction set, which would disqualify the original RPi. Luckily for everyone, the RPi 2 is ARMv7, so hooray on that!

[dmarkovi]

The ODROID-C1 looks interesting as well. I may pick one up just to play with.

[mwillems]

The ODROID-C1 looks interesting as well. I may pick one up just to play with.

I would advise waiting a month or two; I have a C1, and it's not particularly useful right now as the software support is not really "all the way there."  You basically have to use Hardkernel's official linux or android images if you want modestly functional hardware acceleration, and the device isn't really useful as a media player without hardware acceleration.  And even using the official android or ubuntu images, they're still missing a fair amount of basic functionality (hardware acceleration not working for many common video codecs, not all wireless dongles function correctly, Gb ethernet link throttled to 100Mb because of an unfixed networking issue, no CEC support, no HDMI passthrough, extremely limited USB DAC support).  They're working hard on it, but they're a tiny team with a very small community, nothing like the support and community that the Pi has.  If you look at some of their prior boards that are a year or two into their development cycle (e.g. the U2/U3), those boards still have some pretty serious software issues not resolved that may never get resolved.

If I had known the Pi 2 had these specs and would be more or less fully backward compatible with the original Pi, I'd have never picked up the ODROID.  As it is, I'll probably try and find a non-GUI use for it.

All that said, if you want video playback using codecs for which the C1 has hardware accelaration (e.g. h.264) it can handle 720p video fairly well, and does close to fine with 1080p.  Gizmo works pretty well on the android version.  The whole thing's just not ready for primetime yet.

[dmarkovi]

Thanks for the info. Been looking for something to replace my Amazon Fire TV box and now that I have a master license I thought an inexpensive Linux box is the way to go.

A Linux box with theater view that plays 1080p x265 for under $100 would be amazing.

[eezetee]

Thanks for the info. Been looking for something to replace my Amazon Fire TV box and now that I have a master license I thought an inexpensive Linux box is the way to go.

A Linux box with theater view that plays 1080p x265 for under $100 would be amazing.

+1  (rather +a few for kids room, patio, office area) - I think i'll need 4-5 of these and likely another server to process all the requests

[PrinterPrinter]

Hello people,
Any news on the ARM version? MC on RPI would absolutely rock!

I go RPi to Run Volumino and Rune Audio and output via a toslink add on board (HiFiBerry Digi+)- but their software volume implementation is quite weak (compared to MC)

I await in anticipation...

[mwillems]

It's available now:

http://yabb.jriver.com/interact/index.php?topic=97630.0

Here's a quick start guide to setting it up:

http://yabb.jriver.com/interact/index.php?topic=95578.0

[JimH]

It's on the Linux board now.  It was released a couple of days ago.

[PrinterPrinter]

Thanks Guys - this is truly exciting!

Does this means that MC on RPi2 will use the same R128 Volume algorithm as the windows versions?
Will it be able to support convolution filters? Or is that too much for the RPI?

Thank you!

[JimH]

We don't really know its limits yet.  R128 will work.  I don't know whether convolution will.  It's possible.

[mwillems]

Thanks Guys - this is truly exciting!

Does this means that MC on RPi2 will use the same R128 Volume algorithm as the windows versions?

Yes volume leveling works perfectly.  Analyzing audio files will take a long time on the pi, so I would recommend analyzing them on a regular computer and writing the info to the tags before moving them to the pi, but the playback volume leveling works great.

Will it be able to support convolution filters? Or is that too much for the RPI?

I haven't tested this, and it's hard to predict how well it would work for any given application.  Like anything else involving convolution, it probably depends entirely on the length/complexity of your filters, and the number channels you're convolving.  If it were me, I would start with low tap filters while testing and work up.