Print

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

[Mark_NL]

Building a JRiver music render is almost finished!
What you see is the case of a diseased render (it isn’t serviced any more but got a new one from the distributor on very good terms). The ICE Power 125ASX2 amplifier was still working, so ripped everything out except  this amp.
Now it is transformed to a 2 * 125W MC-Arm mediacenter with a DIY Sabre ES9018K2M DAC with a Xmos USB receiver and local HDD. Volume up/down and mute (used play/pause) buttons and leds are fully functional.

I just could not get it to work with a RPI, so against all recommendations tried another arm-board and used an Orange PI. (see second post below)

Thinks to do:
cleaning up the wiring,
cleaning up the script (had to brush up C anyway so maybe rewrite in it), 
try to get internal WIFI working without interference with the audio (The Orange PI has al the EMC markings but i’ll ques it are just the markings.
-  and if that succeeds  -
improve network configuration: bonding eth and wlan (active-backup), really cool would be if wlan goes in to AP mode if none of the NIC’s have a carrier...
Probably more...

[Mark_NL]

So against all recommendations i tried another arm-board: an Orange PI Plus. And the warnings were true: it tends to run hot (heatsink isn’t mandatory), had to port a GPIO LIB myself, onboard wifi interferes with audio..

But that being said, specially thanx to a member of the forum who build a old (3.4.39) but decent kernel and shared it on github, it does the job flawless where i just could not get done with a RPI-2.

This is probably due to the 4(!) USB host’s in the used socket, so network (eth/wlan) and USB ports don’t share 1 USB host.  

I think my problem with the RPI-2 / MC-arm / my-Xmos-USB-receiver combination come’s down to the single USB host on the RPI.   If the RPI is used as a pure DLNA music render it can’t handle IO in a way that the latency sensitive USB receiver can cope with. The main cause is the MC server-client setup tries to get the whole media file in as quick as possible at the start of each track. This stresses the IO scheduling through the RPI’s bottleneck.
Playback from a local HDD works fine; actually playing form the music share of the server goes very well.

To illustrate this see enclosed screen prints.
The server-share with music is mounted on the RPI (smbclient, samba is running on the server anyway) and is imported in the main library.
The print screens are form the same event (change of DSD tracks), one with “Play local file ....” enabled, the other disabled.
So in both cases the exact same mediafiles form the same location comes  out of the speakers.
If it receives the mediafiles through DLNA it stresses the IO too much and (in my case) causes drop outs...

In Conclusion:
I know it could be specific for my hard ware; but it is a kind of a pity MC raises a task: get the hole mediafile a quick as possible, which gets in it’s own way.
However i’m happy to get it working with the Orange PI, and if there are future developments for the arm-platform happy to test them!  

[bob]

I'm playing with a build that bypasses our internet buffering. That will prevent us from getting the whole file at once but will have some downsides with seekability.

[Mark_NL]

That will prevent us from getting the whole file at once but will have some downsides with seekability.

For my personal use (pure music DNLA render) seekability isn't a big issue, maybe it's possible to give it as an option ( /mediarender ?)
If you want me  to test something let me know!

BTW:
I tried a lot of things on the RPI, amongst compiling kernels that tick on 200 Hz (instead of default 100 Hz), setting it up a minimal as possible.
Just X11 no window manager.
MC is quite usable that way except for two windows (as I know off) that haven't got a done or close button : "DSP studio" and  "About Media Center..."