Print

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

[bob]

http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-20.0.66-armhf.deb

This is a full version of MediaCenter for Debian Wheezy on ARM that will timeout on June 10th 2015 for your testing pleasure.

We may or may not release an end user package for ARM in the future. Much will depend on if it requires any support outside of generic linux support.

This is compiled to run on the RPi model B as a minimal system (arm6l). It will also run on an arm7 box (i.e. cubox) but is not and will not be optimized for that platform.

Feedback welcome.

[mwillems]

This is compiled to run on the RPi model B as a minimal system (arm6l). It will also run on an arm7 box (i.e. cubox) but is not and will not be optimized for that platform.

I've got Pi's and a few Arm7 boards to test with, and will report back.  Are you interested in any specific info?  Do you want us to limit our testing to Wheezy, or do you want reports from other Linux distros (I've got sd cards with Debian Jessie, Ubuntu, and Arch around the house)?

Excitement. 

[bob]

I've got Pi's and a few Arm7 boards to test with, and will report back.  Are you interested in any specific info?  Do you want us to limit our testing to Wheezy, or do you want reports from other Linux distros (I've got sd cards with Debian Jessie, Ubuntu, and Arch around the house)?

Excitement. 

You can test with other distros but I'm most interested in the Wheezy tests since like the x86 version it will be the only officially supported distro (it if happens at all).

I'm most interested to see if there are any things that don't work or crash on arm compared to the same configuration on x86.

Thanks...

[shadowlight]

Assuming same xwindows requirement is required for the arm version.

[mwillems]

Ok, first system test result:

ODROID U3 with Debian Wheezy (official ODROID image). The processor is an ARM 7 cortex board, the same one that was used in the Galaxy s3 a few years back: http://www.hardkernel.com/main/products/prdt_info.php?g_code=g138745696275 .  It's almost fast enough to use as a desktop replacement board, but has some buggy features.

Mediacenter20 runs on the U3, audio works, but when launched directly from an X session on the U3, the main MC window is completely blank and no amount of resizing causes it to fill in (tested in xterm, lxde, and xfce).  However, I can launch MC successfully through ssh xforwarding or through VNC, and when launched that way the window is fully rendered.  That suggests the issue is in the U3's graphics stack/frame buffer somewhere, which wouldn't surprise me at all (it has difficulty with XFCE's compositor and several other things).  

Once I managed to get to a fully drawn window through VNC and configure media network, I verified that MC audio playback works fine, and setup network control.  That allowed me to verify that MC is running successfully on the U3 even when launched locally in "blank window" state.  To summarize:

Working on U3:
1) Local audio playback through pulse (I saw no hardware devices in the JRiver device enumeration?)
2) Remote control through Gizmo or Eos (playback, volume control, and track skip tested)
3) DLNA remote control of audio from another instance of MC (although I got a segfault while doing this at one point, but couldn't reproduce it)
4) Connecting as a library client to a library server, and playing back served audio

Not Working on U3:
1) Local window drawing
2) Video playback (throws a "something went wrong with playback," and fails gracefully, whether tried in VNC or via remote control or a local "blank" version) [EDIT: Video is not supposed to be working per Hendrik]
3) Moving the window (local or VNC bugs out like crazy) [EDIT: Holding ALT while dragging resolves this]

Working but not well on U3:
1) Resizing the window (works on some edges, not others)
2) X forwarding through SSH (extremely, extremely laggy, more so than forwarding other x software in the same session). [EDIT: this is expected behavior when using ssh X-forwarding per bob]

I'll be testing next on an ODROID C1 (also arm 7) and a regular Raspberry Pi, I'm keeping Wheezy on the U3 for now, let me know if there's anything else you want me to test on it.

For reference, the U3's JRMark:

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 5.882 seconds
    Single-threaded floating point math... 10.583 seconds
    Multi-threaded integer math... 2.979 seconds
    Multi-threaded mixed math... 5.369 seconds
Score: 766

Running 'Image' benchmark...
    Image creation / destruction... 2.549 seconds
    Flood filling... 2.732 seconds
    Direct copying... 3.754 seconds
    Small renders... 1.728 seconds
    Bilinear rendering... 1.843 seconds
    Bicubic rendering... 0.449 seconds
Score: 1685

Running 'Database' benchmark...
    Create database... 2.873 seconds
    Populate database... 8.043 seconds
    Save database... 1.065 seconds
    Reload database... 0.495 seconds
    Search database... 6.366 seconds
    Sort database... 4.431 seconds
    Group database... 2.781 seconds
Score: 825

JRMark (version 20.0.66): 1092

[mwillems]

Ok, next system test result:

ODROID C1 with Ubuntu 14.04.   There is no official ODROID image for Debian Wheezy on the C1, and they have a custom x driver and custom kernel, so it's non-trivial to install an unsupported distro, so my choices were basically Ubuntu or Arch for testing, and I figured Ubuntu was at least Debian based.

The C1's processor is an ARM 7 cortex board (quad core) http://www.hardkernel.com/main/products/prdt_info.php.  It's a relatively new board priced to comepte with the Raspberry Pi.  It has far more processor and GPU power than the Pi, but it's still working out some serious kinks.

Mediacenter20 runs on the C1, but that's about it.  It has the same problem as the U3 when launched directly from an X session: the main MC window is completely blank.  Just like the U3, I can launch MC successfully through ssh xforwarding or through VNC, and when launched that way the window is fully rendered.  [EDIT: I managed to get a local fully rendered window using an experimental framebuffer driver in Arch for the C1, so the blank window may indeed be a result of the graphic implementation on the ODROIDs]

However, once I managed to get to a fully drawn window through VNC and configure media network, I could not get audio playback to function either locally or through remotes.   MC Audio would appear to start playing: playing now would change to the correct track and it would act as though it were playing except the track time would not increment.  In some cases I might get a half second of audio before it cut out.  Then the player would hang at 0 seconds indefinitely, although it would respond correctly to a stop command. I tried all available devices, and even tried plugging in a USB DAC to see if I could get traction.  No sound from MC.  I tested with other media playback software (Kodi) and audio worked fine, so the hardware is at least basically functioning.

EDIT: To get audio working on the C1: 1) make sure you have the latest kernel, 2) check that your /etc/asound.conf matches the post linked here: http://forum.odroid.com/viewtopic.php?f=117&t=9137#p71677, 3) choose one of the two hw: outputs, and 4) set output format to resample to 48KHz.  

To summarize:

Working on the C1:
1) Remote control through Gizmo or Eos (start, stop, volume control, and track skip tested, they all "worked" except for the absence of sound)
2) Connecting as a library client to a library server and displaying library.
3) DLNA advertising and connecting to a DLNA server
4) Audio Playback with some extra configuration (see above)

Not Working on C1:
1) Local window drawing
2) Video playback (throws a "something went wrong with playback," and fails gracefully, whether tried in VNC or via remote control fora local "blank" version) [EDIT: Video is not supposed to be working per Hendrik]
3) Moving the window (local or VNC bugs out like crazy) [EDIT: Holding ALT while dragging resolves this]

I'll be testing next on a regular Raspberry Pi (probably not until tomorrow); I can also try the C1 again with Arch just to see if that might make any difference?  Let me know if there are any other steps you want me to take to troubleshoot the C1.

For reference the C1's JRMark:

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 9.140 seconds
    Single-threaded floating point math... 14.030 seconds
    Multi-threaded integer math... 4.736 seconds
    Multi-threaded mixed math... 7.228 seconds
Score: 541

Running 'Image' benchmark...
    Image creation / destruction... 2.551 seconds
    Flood filling... 4.568 seconds
    Direct copying... 5.207 seconds
    Small renders... 2.345 seconds
    Bilinear rendering... 2.629 seconds
    Bicubic rendering... 0.560 seconds
Score: 1232

Running 'Database' benchmark...
    Create database... 4.151 seconds
    Populate database... 11.856 seconds
    Save database... 1.251 seconds
    Reload database... 0.474 seconds
    Search database... 10.795 seconds
    Sort database... 8.607 seconds
    Group database... 5.162 seconds
Score: 508

JRMark (version 20.0.66): 760

[Hendrik]

Just as a quick note, Video Playback is not supported on ARM at this time.

[mwillems]

Just as a quick note, Video Playback is not supported on ARM at this time.

Not surprising given the ultra-board-specific hardware acceleration situation; I won't continue testing that 

[bob]

Assuming same xwindows requirement is required for the arm version.

Exactly the same.

[bob]

Try moving the window with ALT-Left click drag instead of Left click drag.
That uses the system instead. It's always smooth for me.

Your playback issues.
1) I've not seen the hardware devices on my 2 arm devices either.
2) The output format detection on your ARM could be buggy. Try fixing it to a know supported output format.
3) X forwarding with MC is slow. It's because the main window contains dozens to hundreds of windows depending on your view. It works better without ssh as the transport.
4) MC only supports 32 bit color. Perhaps that's your main window issue? Do you have the xfonts-75dpi installed??

[mwillems]

Try moving the window with ALT-Left click drag instead of Left click drag.
That uses the system instead. It's always smooth for me.
[...]
2) The output format detection on your ARM could be buggy. Try fixing it to a know supported output format.

I'll test both of these when I get home

4) MC only supports 32 bit color. Perhaps that's your main window issue? Do you have the xfonts-75dpi installed??

I do have xfonts-75dpi installed: I installed all identified dependencies, except for the two one 32 bit c++6 lib and p11-kit-modules, which don't appear to exist in the wheezy/'buntu ARM repos (although p11-kit does exist).  So I installed:

Code: [Select]

libx11-6 libc6 libasound2 libuuid1 libssl1.0.0 libidn11 libxcb1 libxau6 libxdmcp6 zlib1g libxext6 libgtk2.0-0 libp11-kit0 libstdc++6 p11-kit libgl1-mesa-glx libcanberra-gtk-module xdg-utils xfonts-75dpi xfonts-100dpi lame vorbis-tools musepack-tools[Edited to provide correct dependencies, thanks bob]

And could not find direct ARM equivalents of

Code: [Select]

p11-kit-modules lib32stdc++6
Both odroid devices claim to support 32 bit color (although the C1 apparently has some issues with it: http://forum.odroid.com/viewtopic.php?f=117&t=8361).  I'll verify tonight what my actual color depth settings are.  If I can't get anywhere with the official C1 Ubuntu image, I'll probably try it with Arch instead as they've got a couple experimental framebuffer drivers in their repos that might produce different results, and I'm much more familiar with ALSA configuration in Arch than in Ubuntu.  

1) I've not seen the hardware devices on my 2 arm devices either.

An interesting note that may be related: I began work on setting things up on two Raspberry Pis last night (one with Debian, one with Arch), but didn't have time to test beyond getting them running.  I noticed when I was repackaging the deb to install on the Arch Rapsi that it threw a non-critical error related to Alsacap and stripped it out; that may have something to do with why we're not seeing hardware devices?  I'll include the exact error in my Pi write-up later, but I thought I'd mention it.

[bob]

I'll test both of these when I get home

I do have xfonts-75dpi installed: I installed all identified dependencies, except for the two c++6 libs and p11-kit-modules, which don't appear to exist in the wheezy/'buntu ARM repos (although p11-kit does exist).  So I installed:

Code: [Select]

libx11-6 libc6 libasound2 libuuid1 libssl1.0.0 libidn11 libxcb1 libxau6 libxdmcp6 zlib1g libxext6 libgtk2.0-0 libp11-kit p11-kit libgl1-mesa-glx libcanberra-gtk-module xdg-utils xfonts-75dpi xfonts-100dpi lame vorbis-tools musepack-tools
And could not find direct ARM equivalents of

Code: [Select]

libstdc++6 p11-kit-modules lib32stdc++6

Both of my devices have libstdc++6 installed. I'm not sure why you can't find it..

Code: [Select]

pi@raspberrypi ~ $ dpkg -l | grep libstdc
ii  libstdc++6:armhf                      4.8.2-21~rpi3rpi1                       armhf        GNU Standard C++ Library v3


Both odroid devices claim to support 32 bit color (although the C1 apparently has some issues with it: http://forum.odroid.com/viewtopic.php?f=117&t=8361).  I'll verify tonight what my actual color depth settings are.  If I can't get anywhere with the official C1 Ubuntu image, I'll probably try it with Arch instead as they've got a couple experimental framebuffer drivers in their repos that might produce different results, and I'm much more familiar with ALSA configuration in Arch than in Ubuntu.  

An interesting note that may be related: I began work on setting things up on two Raspberry Pis last night (one with Debian, one with Arch), but didn't have time to test beyond getting them running.  I noticed when I was repackaging the deb to install on the Arch Rapsi that it threw a non-critical error related to Alsacap and stripped it out; that may have something to do with why we're not seeing hardware devices?  I'll include the exact error in my Pi write-up later, but I thought I'd mention it.

alsacap hasn't been recompiled for arm. I'll look into that. It's not related at all to what you see in the Audio Devices listing.

[mwillems]

You're right Debian's package catalog clearly shows it in the armhf arch.  Probably a brain cramp on my part during installation last night; I'll sort that out when I get home.  It may have just been a typo and/or confusion with the other c++6 lib.

[bob]

ALSA on the RPi exposes the hardware devices if they are external. I plugged in a Dragonfly USB and got the usual front: and other entries.
The internal devices however aren't exposed outside of the default: and sysdefault: which I believe are routed through the system mixer.

[mwillems]

Update on Odroids:

Window Issues:  I checked the color depth and both ODROID's were allegedly running at 32 bit, but both still gave a blank window when MC was started locally.  I managed to partially troubleshoot the issue by installing Arch for the ODROID C1.  Arch for the C1 has two options for the proprietary video drivers: an x11 version and a framebuffer version (they conflict, so it's one or the other).  With the x11 version most desktop software works correctly, but MC draws a blank window.  With the frambuffer version, most software doesn't render correctly, but MC draws in perfectly.  So it looks like my original suspicion about the ODROID graphics stack/framebuffer may have been correct?  I don't know much about linux graphics programming, but I'm happy to try additional steps to see if it helps.  Using your alt+drag method worked to control window activity.  

Audio Issues on C1: I tried every available output format on the native HDMI audio output and two different USB DACs to see if I could get sound.   No dice.  With the integrated HDMI output, some output formats failed with an error, some attempted to play and then hung on 0 seconds or 1 second.  Most frustrating was the fact that I'd get about a second of audio with the "hanging" settings suggesting that MC was capable of outputting, but something was going wrong.  Kodi and MPD played to the HDMI output.  

The USB DACs showed up as hardware devices in the device enumeration (As you suggested they would), so I also tried them.  Unfortuanately when trying to play directly to hardware devices with MC, the C1 locked up (hard lock that required a power cycle).  I repeated this three times to be sure, but addressing the hardware devices directly locked up the C1 each time. Kodi and MPD played to the USB DAC's without issue.  

Dependency issues: I had libstdc++6 installed already, I was just confused. I'll edit my notes above so anyone following after will know what to install.  I'll also update my reviews above to reflect new info.

Arch: if anyone out there wants to install on Arch ARM, I'm using a modified version of the PKGBUILD in the mainstream AUR.  If you need tips, ask and I'll tell you what I changed.

[mwillems]

Next system a Raspberry Pi Model B+ overclocked to 1000MHz running Raspbian Wheezy and then Arch:

I saw no differences in behavior between running MC on the Pi with Wheezy and Arch; both OS's behaved exactly the same in my tests, so I'm providing a unified description below.

I got Mediacenter20 to run on the Pi when started through xforwarding or VNC, but not when started directly on the Pi.  When I attempted to launch MC from the Pi itself, it segfaulted.  This was be related to the 32 bit color depth issue as the Pi defaults to 16.  I added the following two options to config.txt and MC started right up on the next boot:

Code: [Select]

framebuffer_depth=32
framebuffer_ignore_alpha=1

[Above edited to reflect solution to my initial segfault problem]

The Pi also happily ran MC on both OS's when initiated remotely.  

Once MC loaded, I could configure media network, and the audio playback options that I tested all worked correctly (although playback of FLACs from a library server had the CPU chugging along at 30% to 50%  during playback).  I tested both the integrated HDMI output and an external DAC.  Both worked well, and directly addressing hardware outputs worked great.

To summarize:

Working for me on the Pis:
1) Remote control through Gizmo or Eos (start, stop, volume control, and track skip tested)
2) Connecting as a library client to a library server and displaying library.
3) DLNA advertising and connecting to a DLNA server
4) Audio playback of FLAC and MP3 through HDMI and a USB DAC
5) Local and remote MC launch

Not working:
1) It does not appear to be suitable to use as a library server (which isn't surprising); playback from full mc clients was mostly ok (although there was some flakiness), but when I tried to do local playback on an android device from Gizmo, playback was extremely choppy.  This is not surprising as serving audio to gizmo requires transcoding, so it was predictable that the Pi would have challenges.

I should have a Pi2 showing up in a few weeks, so I'll test that when it arrives.

For reference the Pi's JRMark (overclocked to 1000MHz):

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 20.608 seconds
    Single-threaded floating point math... 35.483 seconds
    Multi-threaded integer math... 41.705 seconds
    Multi-threaded mixed math... 75.143 seconds
Score: 110

Running 'Image' benchmark...
    Image creation / destruction... 7.415 seconds
    Flood filling... 13.464 seconds
    Direct copying... 11.245 seconds
    Small renders... 5.799 seconds
    Bilinear rendering... 19.243 seconds
    Bicubic rendering... 5.591 seconds
Score: 351

Running 'Database' benchmark...
    Create database... 18.205 seconds
    Populate database... 44.811 seconds
    Save database... 3.410 seconds
    Reload database... 1.176 seconds
    Search database... 38.452 seconds
    Sort database... 21.393 seconds
    Group database... 17.679 seconds
Score: 148

JRMark (version 20.0.66): 203

[JimH]

Next system a Raspberry Pi Model B+ overclocked to 1000MHz running Raspbian Wheezy and then Arch:

JRMark (version 20.0.66): 203

Wow.  That might be a new low water mark.  But it played audio OK?  Amazing.

[Mark_NL]

Nice!

I was hoping for the development in this direction to be able to build a DIY audio player around a ES9018 DAC with a nice application on it.

What would be the (easiest) way to great sound quality with MC on a RPi?
RPi, I2S => DAC
RPi, USB => XMOS, I2S => DAC

For now I'm able to test it with a hifiberry DAC, will do so this weekend

[mwillems]

Wow.  That might be a new low water mark.  But it played audio OK?  Amazing.

I had to overclock it.  At stock clocks, music playback was using something like 80% of the cpu and dropping out occasionally.  With the overclock, I listened to a few songs, swapped tracks, started, and stopped, etc.  Everything took a few seconds to happen, but playback seemed fine once it started.  I plan to set up a RasPi as a music player in my office, so I should have more in depth field testing at some future point.

The GUI isn't super usable.  Just starting MC on the Pi pegs the CPU to 100% for about 30 or 40 seconds before things calm down.  But using Gizmo to control it works pretty well.  I haven't tested it with the /mediaserver switch yet; that may perform even better without all the window drawing, which might make it more usable at stock clock speeds.

Nice!

I was hoping for the development in this direction to be able to build a DIY audio player around a ES9018 DAC with a nice application on it.

What would be the (easiest) way to great sound quality with MC on a RPi?
RPi, I2S => DAC
RPi, USB => XMOS, I2S => DAC

For now I'm able to test it with a hifiberry DAC, will do so this weekend

The easiest way to get great sound, in my opinion is to connect it to an external DAC that has its own power soruce or a battery buffer. As long as you have an external DAC that isn't drawing power from the Pi's power supply you should be fine.  My experience is that trying to drive USB powered devices off of the Pi results in flaky performance all the way around (devices don't necessarily work well, and sometimes the Pi powercycles because of current dips).  In my opinion the interrconnection method won't matter as much as the power source.  I used a plain old USB DAC with a rechargeable battery and it sounded great.

If you're buying stuff, I would recommend against getting an RPi 1 for the reasons noted above (it's up to the task of running MC, but just barely); wait for the RPi 2 to come back into stock (same price 6x the power).  If you already have an RPi1, try and see what you think.

I may write a brief software setup tutorial over the weekend, but the basics are all above here: do a vanilla NOOBS install of Raspbian, install the dependencies listed above, install MC, edit your config.txt to add the framebuffer settings (and maybe overclock it if you don't mind living on the edge), and you're done.

[Mark_NL]

If you're buying stuff, I would recommend against getting an RPi 1 for the reasons noted above (it's up to the task of running MC, but just barely); wait for the RPi 2 to come back into stock (same price 6x the power).

Followed your advice and ordered a RPi 2 (They claim to have it in stock).

As said i’m going to test this weekend, so keep us updated and a brief HOW-To would be nice.
’ll try to get the digital sound out of the GPIO (I2S) – If that’s possible we talk about it  in a separate thread. (Thanx)

[mwillems]

Followed your advice and ordered a RPi 2 (They claim to have it in stock).

As said i’m going to test this weekend, so keep us updated and a brief HOW-To would be nice.
’ll try to get the digital sound out of the GPIO (I2S) – If that’s possible we talk about it  in a separate thread. (Thanx)

The Rpi2 is new, but uses most of the same hardware as the old board, so it's allegedly compatible with all of the old accessory hardware, so it should work with your hifi-berry.  I don't have one yet myself, so I can't provide any specific steps for the RPi2 yet. 

FYI, in case there's any confusion, I don't work for JRiver, I'm just a user, but I'm happy to help.

[bob]

Wow.  That might be a new low water mark.  But it played audio OK?  Amazing.

Ours is about 120.

[bob]

Update on Odroids:

Window Issues:  I checked the color depth and both ODROID's were allegedly running at 32 bit, but both still gave a blank window when MC was started locally.  I managed to partially troubleshoot the issue by installing Arch for the ODROID C1.  Arch for the C1 has two options for the proprietary video drivers: an x11 version and a framebuffer version (they conflict, so it's one or the other).  With the x11 version most desktop software works correctly, but MC draws a blank window.  With the frambuffer version, most software doesn't render correctly, but MC draws in perfectly.  So it looks like my original suspicion about the ODROID graphics stack/framebuffer may have been correct?  I don't know much about linux graphics programming, but I'm happy to try additional steps to see if it helps.  Using your alt+drag method worked to control window activity.  

Audio Issues on C1: I tried every available output format on the native HDMI audio output and two different USB DACs to see if I could get sound.   No dice.  With the integrated HDMI output, some output formats failed with an error, some attempted to play and then hung on 0 seconds or 1 second.  Most frustrating was the fact that I'd get about a second of audio with the "hanging" settings suggesting that MC was capable of outputting, but something was going wrong.  Kodi and MPD played to the HDMI output.  

The USB DACs showed up as hardware devices in the device enumeration (As you suggested they would), so I also tried them.  Unfortuanately when trying to play directly to hardware devices with MC, the C1 locked up (hard lock that required a power cycle).  I repeated this three times to be sure, but addressing the hardware devices directly locked up the C1 each time. Kodi and MPD played to the USB DAC's without issue.  

Dependency issues: I had libstdc++6 installed already, I was just confused. I'll edit my notes above so anyone following after will know what to install.  I'll also update my reviews above to reflect new info.

Arch: if anyone out there wants to install on Arch ARM, I'm using a modified version of the PKGBUILD in the mainstream AUR.  If you need tips, ask and I'll tell you what I changed.

Not sure what your issue is with this. MC uses a very straightforward non-tricky method of accessing the audio device. You might want to fix the output format to a specific value (ie S16_LE).

[mwillems]

Not sure what your issue is with this. MC uses a very straightforward non-tricky method of accessing the audio device. You might want to fix the output format to a specific value (ie S16_LE).

On the C1, I tried fixing the output to S16_LE, and tried each of the other modes in turn.  S16_LE played for a second or so, and then hung without additional playback on the C1.  Everything other than S16_LE failed outright (error: something went wrong with playback).  This was when addressing the Pulse device; when addressing hardware devices with external DACs, I just got lock ups. I also tried resampling to 48K to see if that was the issue, but no joy.

The C1 is a very new platform (launched in December), and they've had some pretty significant hardware/firmware problems so far. Most relevant, the audio and video devices have been defaulting to goofy permissions/ownership (among other a/v issues), and that may not have been worked out.  They provide a custom recompilation of Kodi and a few other multimedia packages, so I may be getting sound in those because of those customizations.  

I started investigating that angle last night (manually resetting device permissions, etc.), and noticed that I haven't been able to get any system sounds to play on the C1, which is suspicious.  There are also some complaints on their forums about lack of sound outside of Kodi.  I'll try a few "non-supplied" audio players tonight and see if they have the same problem as MC.  I'll also try some additional ALSA configuration steps to see if it helps.

Sound output is working fine on the U3, which is by far the more mature of the two platforms; so this may just be growing pains for the C1.

[bob]

On the C1, I tried fixing the output to S16_LE, and tried each of the other modes in turn.  S16_LE played for a second or so, and then hung without additional playback on the C1.  Everything other than S16_LE failed outright (error: something went wrong with playback).  This was when addressing the Pulse device; when addressing hardware devices with external DACs, I just got lock ups. I also tried resampling to 48K to see if that was the issue, but no joy.

The C1 is a very new platform (launched in December), and they've had some pretty significant hardware/firmware problems so far. Most relevant, the audio and video devices have been defaulting to goofy permissions/ownership (among other a/v issues), and that may not have been worked out.  They provide a custom recompilation of Kodi and a few other multimedia packages, so I may be getting sound in those because of those customizations.  

I started investigating that angle last night (manually resetting device permissions, etc.), and noticed that I haven't been able to get any system sounds to play on the C1, which is suspicious.  There are also some complaints on their forums about lack of sound outside of Kodi.  I'll try a few "non-supplied" audio players tonight and see if they have the same problem as MC.  I'll also try some additional ALSA configuration steps to see if it helps.

Sound output is working fine on the U3, which is by far the more mature of the two platforms; so this may just be growing pains for the C1.

Sound works totally fine on the cubox-i out the optical port. I don't have to mess with any settings.

[mwillems]

Sound works totally fine on the cubox-i out the optical port. I don't have to mess with any settings.

Sound works fine on the Pi and the ODROID U3; easy output with literally no configuration required.  It's just the C1 that's being a bummer.

I'll keep hacking on the C1 for a while and see if I can figure it out.  

If there are any other things you'd like me to test on any of the three platforms, let me know, I'm happy to test.  I'll report back if I stumble into anything else.

[mwillems]

Ok so I got audio on the C1 working.  It was a combination of issues, some of which are still a little baffling to me.  

After noticing the absence of system sounds, I tested five other players and three could play sound (Kodi, MPD, and Deadbeef) and two could not (Audacious and Gnome Player). Audacious and Gnome Player exhibited the exact same symptoms as MC: they'd start to play and then hang, with no sound output.  

So I started digging around on Odroid's forums, and they apparently updated their custom kernel three days ago, and the update was supposed to resolve some audio issues.  So I tried that, but by itself that didn't solve anything. I also saw a recommendation to edit the /etc/asound.conf as shown here: http://forum.odroid.com/viewtopic.php?f=117&t=9137, so I tried that.  

Between the new kernel and the new asound.conf, aplay -L gave me six audio output choices for the built in HDMI output (I'd previously only had two), and two of the six had hw: prefixes!  Pulse and the Default (ALSA) output still didn't work no matter what combination of settings I tried.  The hw: outputs also initially threw errors, but on a hunch I tried resampling the output to 48KHz, and then the hw outs both worked.

So to summarize, the hw outs only work with resampling to 48KHz, but no combination of audio output settings and resampling produced audio output through the Pulse or default outputs. Audacious and Gnome Player still don't work at all.  So that all leads me to believe that the C1 is still pretty "in progress" at this stage.

Bizarre.  Works great now  

[Mark_NL]

Up and running without any troubles;

The music comes out of the HiFiberry DAC+, volume control seems to work
Haven't time to do a lot of testing right now (without risk getting killed by my girlfriend)

@ mwillems; PI 2 (standard 700 MHz) JRMark 404

[mwillems]

Up and running without any troubles;

The music comes out of the HiFiberry DAC+, volume control seems to work
Haven't time to do a lot of testing right now (without risk getting killed by my girlfriend)

@ mwillems; PI 2 (standard 700 MHz) JRMark 404

That's a pretty sweet JRMark.  My Pi2's are supposed to show up today, so I'll see what I can squeeze out with overclocking 

[shadowlight]

Exactly the same.

Thx Bob.  Hopefully we are moving towards total headless requirements in the near future.

[mwillems]

Just got my Raspberry Pi 2 in the mail, booted up Raspbian, and got MC running on it in about ten minutes.  It required the same config.txt settings as the Pi B+. Everything in JRiver that's supposed to work works except for the maximize and minimize buttons on the main window, but those are a little flaky on some of my Linux builds too, so that's not ARM-specific.

Performance is, as expected, significantly better.  Launching MC just pushes CPU utilization to 35% for five or ten seconds instead of pegging it out for 30 seconds.  At idle utilization is 5% or less.  Playback utilization is only about 25% (or 18% with the built in overclock option enabled).  It can even handle audio transcoding/streaming to Gizmo, which is awesome (although it eats between 35% and 60% of CPU doing it, so I wouldn't try to do two streams at once, or anything)

With stock settings I got a JRMark in the low 400's like Mark_NL did, but with the built-in overclock option (i.e. 1000MHz) and some cpu frequency tuning, I got a JRMark of about 563, which is not too shabby for a $35 Arm7 board where everything just works out of the box.  So an overclocked Pi2 has about 2.5 as much JRiver performance as a Pi 1.  Additionally, the overclock/tuning makes a significant difference over stock settings on the Pi2 (25% increase in performance).

The Pi 2 is fast enough to comfortably use with JRiver IMO, and is almost fast enough to use as a general purpose computer in limited contexts  (I'm posting on it right now).  The Pi1 was definitely not fast enough to use for normal computer tasks, and JRiver seemed to be pushing it's capabilities a little.  I wouldn't want to use the Pi2 as my only interface with JRiver, but if I had to, I could;  There's about a half-second of lag after any click affecting playback, but the wait is short enough that you don't start wondering if the click actually registered, etc.  Scrolling performance is not the best, but I don't have all my thumbnails built either, so it's hard to say what that will end up like.

[JimH]

The Pi 2 is fast enough to comfortably use with JRiver IMO, and is almost fast enough to use as a general purpose computer in limited contexts (I'm posting on it right now).

Nice!  Thanks for the great report.

[Hilton]

I'm looking forward to playing with this!

What do you mean IF it's officially released on ARM?    

Ordered a Pi 2 and case to play around with.. arrrrgh too many projects and not enough time!



PS. Maybe I can build that MC20 embedded speaker after all..........

[mwillems]

PS. Maybe I can build that MC20 embedded speaker after all..........

The only hitch right now is that JRiver for ARM/Linux can't really take a direct audio input (no ASIO line in or WDM); So it would need it to be a DLNA/Airport-only speaker.  

The problem with that approach will is syncing two speakers well enough for stereo (unless the same pi is controlling both speakers); it sounds like you've made some strides getting sync working through airport, but is it a fine enough sync for that?

[Hilton]

The only hitch right now is that JRiver for ARM/Linux can't really take a direct audio input (no ASIO line in or WDM); So it would need it to be a DLNA/Airport-only speaker.  

The problem with that approach will is syncing two speakers well enough for stereo (unless the same pi is controlling both speakers); it sounds like you've made some strides getting sync working through airport, but is it a fine enough sync for that?

Yeah but that's not such a problem really.
For line in you can use a wolfson sound card http://www.adafruit.com/product/1761
or similar.
There's no need to use MC for external line in really.
For that matter you could just have a switch and switch the amp input between the Pi and a line in.

I've thought about the stereo thing a little.
The AirPlay sync is actually pretty good and would be usable for stereo for non-critical listening.
The tolerance in the AirPlay protocol is 2ms I think which is fine for casual listening.
(AirPlay sends a sync packet every second)
 
But you could also just have a stereo speaker too depending on what your trying to do.
You could also have a master speaker and a slave that's just got amp input. (as you suggested)
Lots of ways to handle that depending on what your trying to do.

The Pi with MC20 and a HiFiberry amp could be interesting.

Add a high capacity rechargeable battery for portable use.
A Power socket.
USB Wifi.
Power Over Ethernet
That just about caters to every use scenario.

It would be possible to run a Pi and the HiFiBerry amp from power over Ethernet and just have an Ethernet cable into the speaker.

Lots of different possibilities.

[mwillems]

Yeah but that's not such a problem really.
For line in you can use a wolfson sound card http://www.adafruit.com/product/1761
or similar.
There's no need to use MC for external line in really.
For that matter you could just have a switch and switch the amp input between the Pi and a line in.

I think we may have been thinking about different things; you're talking about using MC as a source in the speaker for remote audio?  That would work fine subject to the sync issues we discussed above/below.  I was thinking about using MC's DSP stack to tune a speaker, which wouldn't work right now without an input into MC.

But you could also just have a stereo speaker too depending on what your trying to do.
You could also have a master speaker and a slave that's just got amp input. (as you suggested)
Lots of ways to handle that depending on what your trying to do.

The Pi with MC20 and a HiFiberry amp could be interesting.

Add a high capacity rechargeable battery for portable use.
A Power socket.
USB Wifi.
Power Over Ethernet
That just about caters to every use scenario.

It would be possible to run a Pi and the HiFiBerry amp from power over Ethernet and just have an Ethernet cable into the speaker.

Lots of different possibilities.

I have a Pi running off of a rechargeable battery with a little class D amp pumping audio to a pair of speakers in my bedroom right now.  It's basically a pi-driven boom box.  The Pi doesn't need much power at all, the amp is the real power eater, but the D amps only use a few watts at idle, which is great.

[Hilton]

I think we may have been thinking about different things; you're talking about using MC as a source in the speaker for remote audio?  That would work fine subject to the sync issues we discussed above/below.  I was thinking about using MC's DSP stack to tune a speaker, which wouldn't work right now without an input into MC.

I hadn't thought about that use case.  I was thinking more like the current DLNA/AirPlay speakers that also have a line-in so you can bypass the DLNA/AirPlay.  I guess your talking about competing with other miniDSP type devices for active speakers, which MC could do if your just using a single Pi for a pair of speakers and using MC20/DLNA or AirPlay. But yeah no input for MC.

[Hilton]

My first experiment will be to install the Pi into an old Logitech iPod speaker dock and power it from the batteries.

This is from the ShairPort-Sync readme (which just happens to run on Debian Arm)
Playback synchronisation is allowed to wander a small amount before attempting to correct it. The default is 88 frames, i.e. 2 ms. The smaller the tolerance, the more likely it is that overcorrection will occur. Overcorrection is when more corrections (insertions and deletions) are made than are strictly necessary to keep the stream in sync. Use the --statistics option to monitor correction levels. Corrections should not greatly exceed net corrections.

[mwillems]

My first experiment will be to install the Pi into an old Logitech iPod speaker dock and power it from the batteries.

Pi's are very sensitive to power supply issues, especially with connected peripherals, so make sure the battery can supply 5V and at least 2amps.

I also just put together an install guide for MC on the Pi over here if you're interested: http://yabb.jriver.com/interact/index.php?topic=95578.0

[mwillems]

So I've done some more testing with the Pi 2's and came across a few more findings.

Memory management issues: I noticed this while testing a Pi2 with Raspbian, but the same issue seems to apply to the Pi 1 on Raspbian also.  When scrolling through thumbnail views on the device, Media Center seems to be sucking up a lot of memory, which depending on memory allocation, tends to slow the system down pretty drastically after a little while.  On a Pi 2, I saw MC eating over 300MB of RAM.  Now that's not a lot in a normal PC context, but when the device only has 512Mb or 1Gb of ram (and that ram is split between main memory and graphics),  that's a boatload.  MC seems to float up to the 300 MB range and stay there on both the Pi 1 and Pi 2

On the Pi 2, I was testing with an even split between main memory and GPU, so I had about 512Mb of main ram. Just running the base system and lxde left me about 395MB available for use.  With aggressive scrolling I could get MC's use up to 330 and change.  It seems to level off around there, but at that point everything is running pretty slow, because there's not much remaining RAM and sdcard swap space is pitifully slow.  When I backed off the split to 3/4 in favor of main memory, MC still ate about 300MB and change, but there was a few hundred MB of RAM left over so I never got a serious slowdown.

When I tested this issue on an RPi 1, everything really ground to a halt though.  The default split for the Rpi 1 only leaves about 430 MB in main memory, meaning that the amount available after system use is only about 330 or so, which made for a difficult experience when doing extended scrolling in MC.

The obvious solution from the user side is backing off the video RAM to free up more main memory, but below a certain threshold that also starts hurting scrolling performance.  For the RPi 2 the "sweet spot" split seems to be 3/4 or so, but I'm not sure there's a "good" split for the R Pi 1.  Just thought I'd raise the issue in case there's anything that can be done on the dev side.  

To reproduce: load a large library and navigate to a thumbnail view, and then scroll through at a medium speed (allowing the thumbs to populate, etc.)

Better Performance on Arch:  I also installed Arch ARM and JRiver on a Pi2, and it worked great.  In fact I managed to get a dramatically better JRmark (635).  I repeated it a few times to make sure it wasn't a fluke, but it was legit.  It may be because Arch is just running plain old Arm7hf optimized packages instead of Raspbian's packages which are primarily still optimized for Arm6.  If that's the explanation, Raspbian performance may also improve as they port things across and recompile.  A taste of things to come.  The actual user experience is only slightly better on Arch (scrolling slightly smoother, but still not actually really smooth), but I wanted to mention it because it means things may get better as optimizations roll in.  

[bob]

So I've done some more testing with the Pi 2's and came across a few more findings.

Memory management issues: I noticed this while testing a Pi2 with Raspbian, but the same issue seems to apply to the Pi 1 on Raspbian also.  When scrolling through thumbnail views on the device, Media Center seems to be sucking up a lot of memory, which depending on memory allocation, tends to slow the system down pretty drastically after a little while.  On a Pi 2, I saw MC eating over 300MB of RAM.  Now that's not a lot in a normal PC context, but when the device only has 512Mb or 1Gb of ram (and that ram is split between main memory and graphics),  that's a boatload.  MC seems to float up to the 300 MB range and stay there on both the Pi 1 and Pi 2

On the Pi 2, I was testing with an even split between main memory and GPU, so I had about 512Mb of main ram. Just running the base system and lxde left me about 395MB available for use.  With aggressive scrolling I could get MC's use up to 330 and change.  It seems to level off around there, but at that point everything is running pretty slow, because there's not much remaining RAM and sdcard swap space is pitifully slow.  When I backed off the split to 3/4 in favor of main memory, MC still ate about 300MB and change, but there was a few hundred MB of RAM left over so I never got a serious slowdown.

When I tested this issue on an RPi 1, everything really ground to a halt though.  The default split for the Rpi 1 only leaves about 430 MB in main memory, meaning that the amount available after system use is only about 330 or so, which made for a difficult experience when doing extended scrolling in MC.

The obvious solution from the user side is backing off the video RAM to free up more main memory, but below a certain threshold that also starts hurting scrolling performance.  For the RPi 2 the "sweet spot" split seems to be 3/4 or so, but I'm not sure there's a "good" split for the R Pi 1.  Just thought I'd raise the issue in case there's anything that can be done on the dev side.  

To reproduce: load a large library and navigate to a thumbnail view, and then scroll through at a medium speed (allowing the thumbs to populate, etc.)

Each thumb is a window with an image. They are going to eat memory.

Better Performance on Arch:  I also installed Arch ARM and JRiver on a Pi2, and it worked great.  In fact I managed to get a dramatically better JRmark (635).  I repeated it a few times to make sure it wasn't a fluke, but it was legit.  It may be because Arch is just running plain old Arm7hf optimized packages instead of Raspbian's packages which are primarily still optimized for Arm6.  If that's the explanation, Raspbian performance may also improve as they port things across and recompile.  A taste of things to come.  The actual user experience is only slightly better on Arch (scrolling slightly smoother, but still not actually really smooth), but I wanted to mention it because it means things may get better as optimizations roll in.  

It's the optimization of the packages. This was mentioned on the Pi forums. The only part of raspbian that's arm7 for the pi2 is the kernel.

[mwillems]

Each thumb is a window with an image. They are going to eat memory.

I assumed it was related to the number of images displayed; what I didn't know was if it was caching/retaining images not currently on the screen to any meaningful extent (i.e. a few pages in either direction or something).  If it's just showing what's on screen and screen adjacent, then it is what it is.

The good news is that I couldn't get it to eat more than 330MB or so even fiddling with it to maximize the number of thumbs on screen.   It just means that the Pi 1 won't be a great choice for direct GUI use, but we probably already knew that.

It's the optimization of the packages. This was mentioned on the Pi forums. The only part of raspbian that's arm7 for the pi2 is the kernel.

I read that too; they're not sure what they're going to do about Raspbian in the future(whether they'll actually port it to 7, or just use vanilla Debian arm7hf instead). Arch ARM just quietly dropped the kernel into their existing Arm7hf library without much deliberation.  As is often the case, Arch is a glimpse into Debian's future (warts and all)  

[hvoerman]

Better Performance on Arch:  I also installed Arch ARM and JRiver on a Pi2, and it worked great.  In fact I managed to get a dramatically better JRmark (635).  I repeated it a few times to make sure it wasn't a fluke, but it was legit.  It may be because Arch is just running plain old Arm7hf optimized packages instead of Raspbian's packages which are primarily still optimized for Arm6.  If that's the explanation, Raspbian performance may also improve as they port things across and recompile.  A taste of things to come.  The actual user experience is only slightly better on Arch (scrolling slightly smoother, but still not actually really smooth), but I wanted to mention it because it means things may get better as optimizations roll in.  

Could you please describe (perhaps a guide) how you got this setup working? I'm strugling with Arch on de RPI2 for some days now. I got it working a bit, I can even start LXDM. But now my challenge is to get the .deb file installed on Arch. I found some outdated methods. Perhaps there's another way to install MC20 to Arch?

My aim is to create a RPI2 with MC20 and Kodi as my media center for bit-perfect audio playback (using MC20) and for watching movies (using Kodi).

Thanks also for the Debian Wheezy Guide. That really helped me a lot.

[mwillems]

Could you please describe (perhaps a guide) how you got this setup working? I'm strugling with Arch on de RPI2 for some days now. I got it working a bit, I can even start LXDM. But now my challenge is to get the .deb file installed on Arch. I found some outdated methods. Perhaps there's another way to install MC20 to Arch?

My aim is to create a RPI2 with MC20 and Kodi as my media center for bit-perfect audio playback (using MC20) and for watching movies (using Kodi).

Thanks also for the Debian Wheezy Guide. That really helped me a lot.

How familiar are you with the Arch User Repository build system?  Basically all I did was take the PKGBUILD from the mainline JRiver Arch User Repository Package, and modified it to work on Arm.  Download the tarball from the link above, and then modify the PKGBUILD file as shown (or just replace it entirely):

Code: [Select]

pkgname=jriver-media-center
_debpkgver=20.0.66
pkgver=$_debpkgver
pkgrel=1
pkgdesc="The Most Comprehensive Media Software"
arch=('armv7h')
url="http://www.jriver.com/"
license=('custom')
depends=('alsa-lib' 'gcc-libs' 'libx11' 'libxcb' 'libxau' 'libxdmcp' 'util-linux' 'libxext' 'gtk2' 'p11-kit')
optdepends=('mesa-libgl: nouveau video support' 'nvidia-libgl: nvidia video support' 'xorg-fonts-75dpi:' 'xorg-fonts-100dpi:' 'vorbis-tools:' 'lame:')
source=("http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-$_debpkgver-armhf.deb" 'License.txt')
sha256sums=('9fe4cd47fa8f14ed282a64085aa59afdbc2139f68c10e1f5d1be9ee75f84e7ef' 'ee00f430918df6be37777a61e12812875b5583379c78daaa969bae7383a41fbd')

package() {
  cd "$srcdir"
  bsdtar xf data.tar.xz -C "$pkgdir"
    install -Dm644 "License.txt" \
    "$pkgdir/usr/share/licenses/$pkgname/COPYING"
}

Once that's done, just run makepkg like any other AUR package and it should make an Arch compatible package.  See the following Arch wiki link for general instructions on making packages from the AUR: https://wiki.archlinux.org/index.php/Arch_User_Repository

Bob, feel free to split this if you think it's wandering OT.  

[morrison]

Im happy with this thread 

Test it on Samsung Tab 8.4 Pro CM12 latest nightly with Linux Deploy chroot environment  Debian wheezy armhf.
White window over VNC. Worked with X server, remote from my SteamOS machine. 1920x1200 a bite laggy, but basically usable. Audio doesn't work, but I see  msm8974taikocdp [ALSA] device in settings.

Bench (Snapdragon 800 @ 2.3)

Clipboard doesnt work, so main scores:

Math 824
Image 2616
DB 854

JRMark 1431

[hvoerman]

MOD: I had 'play from memory' active in MC20. This seams to cause the 'out of memory'. I first increased the swapfile to 512M. This made MC stay alive but it stuttered from time to time. After I disabled the play from memory option and (after reading about it on a forum) decreased buffering to 2 seconds, MC did not suddenly stop anymore. Hopefully this helps others to get their audiophile setup in place.

============

I'm using MC on RPI2 Debian Wheezy now for a few days to play audio (also high bit depth and sample rates) throug a USB DAC. I must say I'm impressed with what the little box in combination with MC shows, great performance!

The only somewhat annoying thing, is that once every so much seconds/minutes the sound has cracks/tickles/static. With some menu options the sound completely 'crashes' into random noise and after that most of the times MC crashes. On a  terminal i have messages like:

Code: [Select]

Message from syslogd@rpi2-mc at Feb 22 21:49:01 ...
 kernel:[ 9185.722565] flags: 0x80008(uptodate|swapbacked)

Message from syslogd@rpi2-mc at Feb 22 21:49:01 ...
 kernel:[ 9185.740654] page:ae2133e0 count:-1 mapcount:-2 mapping:  (null) index:0x0

Message from syslogd@rpi2-mc at Feb 22 21:49:01 ...
 kernel:[ 9185.747649] flags: 0x410(dirty|reserved)

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.763530] flags: 0x400(reserved)

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.774331] page:ae213360 count:0 mapcount:-1 mapping:  (null) index:0x0

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.781775] flags: 0x414(referenced|dirty|reserved)

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.797691] flags: 0x400(reserved)

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.808762] page:ae213460 count:0 mapcount:-1 mapping:  (null) index:0x0

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.816086] flags: 0x414(referenced|dirty|reserved)

Message from syslogd@rpi2-mc at Feb 22 21:49:02 ...
 kernel:[ 9185.832446] flags: 0x400(reserved)
Will there be an updated version of MC for RPI2 in the near future? I (as written in an earlier post) would very much like a RPI2 with MC20 to be able to replace my current mediacenter PC.

Are there any specific 'audiophile' things that need testing?

RPI2 has following config.txt items active:

Code: [Select]


hdmi_drive=2

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=2
gpu_mem=256


framebuffer_depth=32
framebuffer_ignore_alpha=1

Perhaps this can use some further tweaking?

Thanks for giving MC for ARM a change!

[hvoerman]

I'm still using MC20 on RPI with Wheezy.

For testing purposes I run mediacenter20 from an xterm, to catch the messages. Tonight MC20 crashed with the following:

Code: [Select]

Found 0 devices (devices will be listed below)

Total time: 14 ms
Result: 0

(mediacenter20:18933): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-button-images after class was initialised

(mediacenter20:18933): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-label-select-on-focus after class was initialised

(mediacenter20:18933): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-scrolled-window-placement after class was initialised

(mediacenter20:18933): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-can-change-accels after class was initialised

(mediacenter20:18933): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-menu-popup-delay after class was initialised

(mediacenter20:18933): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-menu-popdown-delay after class was initialised
sh: 1: mediacenter: not found
Found 0 devices (devices will be listed below)

Total time: 13 ms
Result: 0
Segmentation fault


What I did before was update the library (setting tags right) using my windows machine, connected to the RPI2 with MC20. Possibly things got messy after some bit changes as in the library audio | files a lot of paths showed broken. I got (sort of) random names. Perhaps this helps in the further developement of MC20 for ARM.

[bob]

Next system a Raspberry Pi Model B+ overclocked to 1000MHz running Raspbian Wheezy and then Arch:
...

Where do you set the overclock, in the boot config.txt?
I just booted my pi 1 sdcard and it works fine. My overclock was set to 900 in config.txt for the pi 1. Will that just work for the pi 2?

[mwillems]

Where do you set the overclock, in the boot config.txt?
I just booted my pi 1 sdcard and it works fine. My overclock was set to 900 in config.txt for the pi 1. Will that just work for the pi 2?

You set the same variables in config.txt as you would for a pi 1, but the recommended values for those variables are different for the pi 2.  For example, the pi 2 is clocked at 900MHz at stock (unlike the Pi 1), so setting the arm_freq to 900 wouldn't even be an overclock, and depending on your other clock settings might effectively be an underclock.

The overclock settings I use were included as an option in the NOOBS raspi-config, and as a commented example in the stock config.txt for the Pi 2:

Code: [Select]


arm_freq=1000
sdram_freq=500
core_freq=500
over_voltage=2

Note that those differ from the turbo setting for the pi 1 (the overvoltage is different).  Those are stable on both the pi 2's I have, and won't void the warranty (because they were an option in the raspi_config script).  You may also need to change your cpufrequency scaling governor for best performance.

For some thoughts on more extreme options see:
http://haydenjames.io/raspberry-pi-2-overclock/

But I found his more aggressive settings to be unstable.

[bob]

You set the same variables in config.txt as you would for a pi 1, but the recommended values for those variables are different for the pi 2.  For example, the pi 2 is clocked at 900MHz at stock (unlike the Pi 1), so setting the arm_freq to 900 wouldn't even be an overclock, and depending on your other clock settings might effectively be an underclock.

The overclock settings I use were included as an option in the NOOBS raspi-config, and as a commented example in the stock config.txt for the Pi 2:

Code: [Select]


arm_freq=1000
sdram_freq=500
core_freq=500
over_voltage=2

Note that those differ from the turbo setting for the pi 1 (the overvoltage is different).  Those are stable on both the pi 2's I have, and won't void the warranty (because they were an option in the raspi_config script).  You may also need to change your cpufrequency scaling governor for best performance.

For some thoughts on more extreme options see:
http://haydenjames.io/raspberry-pi-2-overclock/

But I found his more aggressive settings to be unstable.

Thanks. I was impressed that it just ran. It compiled about 10 times faster than the pi 1.