Building the ideal(ish) Music Server

[davewantsmoore]

15 hours ago, frednork said:

Maybe an atom issue?

My understanding more of a BIOS issue.    I have seen many reports of people having the problem with core processors also.

 

Seems it all cropped up around the change-over to EFI ... although whether EFI itself is directly related I'm not sure (and don't see how it could be)

[Guest rmpfyf]

5 hours ago, davewantsmoore said:

My understanding more of a BIOS issue.    I have seen many reports of people having the problem with core processors also.

 

Seems it all cropped up around the change-over to EFI ... although whether EFI itself is directly related I'm not sure (and don't see how it could be)

Most likely BIOS... though you'd have to really really really love your motherboard to write to its manufacturer stating 'dude, where's my TSC under Linux!'

 

Worth a shot if determined, though I'd sooner not run an Atom processor.

[frednork]

Interested in feedback on the merits or otherwise of  this https://www.hystou.com/index.php?route=product/product&product_id=107  for use as a server around $500 + postage and mem and sd

 

• Universal performance: Hystou fanless mini pcs compatiable with almost all popular operating systems, such as Windows, Linux. You can use this mini computer as personal computer at home, or use it as HTPC to built your own home theater center, and also you can use it in offices, training centers, factories, internet cafe and everywhere that require computers.
• Silent operation: fanless mini pc also name as silent computer, quiet mini pc or silent desktop pc. As there is no fan inside, the pc runs totally silent all day long, make sure you can keep wholehearted in to your work.

  Processor	CPU	Intel Core i7-5550U
  	Max. Speed	3.0GHz
  	Chipset	Intel Broadwell single chip
  Memory	Technology	Dual Channel DDR3L 1600Mhz
  	Max capacity	16GB
  	Socket	2*204 pin SO-DIMM
  Graphics	Chipset	Intel® HD Graphics 6000
  	Interface	2*HDMI 4K output
  Ethernet	Lan	2* RTL8186/8111/8112 Gigabit NIC
  	WAN	Half Height Mini PCI + 2 external antennas (Optional)
  Audio	High Definition Audio Controller, SPK+MIC
  IO Interface	Serial Ports	No COM Port
  	USB interface	4 USB 3.0 ports and 4 USB 2.0 ports
  Storage	SATA	Support 1*2.5 inch SATA laptop HDD or SDD
  	mSATA	Support 1*mSATA SSD
  OS Support	Windows 7, 8, 10 and all kind Linux OS
  Power Requirement	Power Type	External power adapter mode
  	Power adapter	12V 5A
  Power Consumption	TDP	Theoretically max 15W, Real use max 8.7W
  	TDP Down	7.5W
  Mechanical	Construction	Aluminum housing
  	Mounting	Free Desk Base+Paid VESA Mounting
  	Dimensions	20.3*18*4.5CM
  	Weight	NW 1.8kg, GW 2.7kg
  Operating Environment	Temperature	0℃to 70℃
  	Humidity	10%-85%

[Guest rmpfyf]

@frednork

 

Depends how far you want to go. 

 

If you want to control EMI in a serious way you'd probably want to build yourself, get rid of the WiFi, run single-sided RAM of 1 stick only, etc. I'm not sure how you get an audio USB card in there if that's something you'd want. 

 

I have no data on the quality of clocks or power conversion on board.

 

$500+ is a lot to try. Any reviews?

Edited September 17, 2018 by rmpfyf

[frednork]

This would be for the server side so no usb card required. Cant find any reviews of this machine in an audio environment. Looks like custom motherboards so not even able to look up mb specs. 

 

I am after something fanless to run a budget roon server (maybe via snakeoil ) which has enough power to upsample if I decide to try hq player. Preferably with 2 network points to allow direct connection to another pc renderer. I thought this was cheap for a recent I7 but happy to be directed to something more economical.

[stuckinhere]

@frednork Intel nuc with 5th gen i7 (5557U) for $400 on ebay? Here 

 

 

[Guest rmpfyf]

4 hours ago, frednork said:

This would be for the server side so no usb card required. Cant find any reviews of this machine in an audio environment. Looks like custom motherboards so not even able to look up mb specs. 

 

I am after something fanless to run a budget roon server (maybe via snakeoil ) which has enough power to upsample if I decide to try hq player. Preferably with 2 network points to allow direct connection to another pc renderer. I thought this was cheap for a recent I7 but happy to be directed to something more economical.

Not so bad, then. I'd tend towards Mini-ITX just in case you wanted to expand anything, though really this isn't so bad. @stuckinhere has a point that you may fare better with not-latest-gen stuff; I'd suggest you probably want more than 2 physical cores though. Go nuts with some grunt here, it's your playback PC that needs to be tuned for lower power. 

Edited September 18, 2018 by rmpfyf

[frednork]

On 16/09/2018 at 10:40 PM, rmpfyf said:

 

Could be. Different microcode and BIOS families Atom-to-Core. 

 

Now get yourself an i5/i7 with a ton of cache and low volt spec and never look back  

 

I would ask Kith if there's any chance it's the version of SO being used. 

 

I would also play a tune you know well and use the commands in earlier posts to flip between HPET and TSC during playback, and see what you like more. Should be audible.

Asked Kith about the TCS issue reply below

 

Can confirm the same behaviour in my own setup. Pretty sure this is the cause:
 

Code:

clocksource: Override clocksource tsc is not HRT compatible - cannot switch while in HRT/NOHZ mode

Snakeoil is using what is called a 'TICKLESS' kernel. Probably this is the cause.. Give me a few days to experiment and work out a solution. This will likely use another kernel..

 

Also still looking at server options

 

any thoughts on a current Intel NUC Kit NUC7I7BNH which is similar cost to the one before

 

Pros-

can run roon rock,

ready to go

 

cons-

only one ethernet port,

has fan? ,

cant seem to easily find bios options,

only 2 core cpu

Edited September 20, 2018 by frednork

[davewantsmoore]

Ahhhh!

 

"NoHZ" = tickless mode

[davewantsmoore]

Quote

Snakeoil is using what is called a 'TICKLESS' kernel. Probably this is the cause.. Give me a few days to experiment and work out a solution. This will likely use another kernel..

I thought "Agent" Kith has an account here.... anyways.

 

I wanted to ask if he considered if the "solution" to provide HRT was actually a good one for this problem.    ie. maybe "Can I have HRT?" ... should be met with "you don't want HRT!".   

 

Reading here:  https://hk.saowen.com/a/186b0baee971cc12c83219c7d3c426e93cab59e5d183cc4c3862e8330abdf805 ... it seems to say that if your hardware timer is good, then tickless high res mode could be the best solution.

 

 

[Guest rmpfyf]

On 02/09/2018 at 6:04 PM, rmpfyf said:

HRT = high resolution timer

NOHZ = kernel configured with tickless idle (see https://stackoverflow.com/questions/9775042/how-nohz-on-affects-do-timer-in-linux-kernel)

 

Had mentioned this. Common to many audiophile builds (don't quite run it myself, there's a little more to be had in not being fully tickless, but it's the right direction).

 

Still vote partial BIOS issue - even w/tickless can get TSC and HPET running here quite happily. You will notice a change in kernel tick audibly.

Edited September 20, 2018 by rmpfyf

[frednork]

Can report that a custom kernel from agent Kith seems to have sorted the TSC issue

 

now get

 

dmesg | grep -i tsc
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 2133.242 MHz processor
[    0.208868] TSC synchronization [CPU#0 -> CPU#1]:
[    0.208870] Measured 15574328 cycles TSC warp between CPUs
[    1.458155] tsc: Refined TSC clocksource calibration: 2133.408 MHz
[    1.458218] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1ec077e4ba6, max_idle_ns: 440795309929 ns

 

Havent had a chance to listen to it yet, will report back when I do.
 

[Guest rmpfyf]

1 hour ago, frednork said:

Can report that a custom kernel from agent Kith seems to have sorted the TSC issue

 

now get

 

dmesg | grep -i tsc
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 2133.242 MHz processor
[    0.208868] TSC synchronization [CPU#0 -> CPU#1]:
[    0.208870] Measured 15574328 cycles TSC warp between CPUs
[    1.458155] tsc: Refined TSC clocksource calibration: 2133.408 MHz
[    1.458218] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1ec077e4ba6, max_idle_ns: 440795309929 ns

 

Havent had a chance to listen to it yet, will report back when I do.
 

 

So what changed (in the kernel)?

[frednork]

33 minutes ago, rmpfyf said:

 

So what changed (in the kernel)?

dunno, he called it " Periodic Timer: 300 Hz " if thats a clue

[Guest rmpfyf]

38 minutes ago, frednork said:

dunno, he called it " Periodic Timer: 300 Hz " if thats a clue

Yeah, I know what that is. Interesting choice. It's going to sound different to your last kernel.

Edited September 29, 2018 by rmpfyf

[frednork]

Finally had a chance to do some critical listening to the periodic timer 300HZ kernel. Not sure if my ears were not cooperating but i found it difficult to describe exactly what the difference was. At times I thought it may be an improvement but in the end I found the standard snakeoil Kernel using HPET timer preferable to the 300Hz kernel with the TSC timer.  Exactly what was better I must confess I couldnt put my finger on. Also compared it to an SOTM SMS200 ultra and found it very similar with very slight and relatively unimportant differences.  So considering this is the vanilla version of Snakeoil with only some changes to timer frequency  and interrupt settings thats pretty good. Great work Agent Kith!!

 

Also been dredging through this monolithic thread and was interested in latency. Its seems like the lower the better but how do you guys get it so low, mine is sky high!!!

[Guest rmpfyf]

9 hours ago, frednork said:

Finally had a chance to do some critical listening to the periodic timer 300HZ kernel. Not sure if my ears were not cooperating but i found it difficult to describe exactly what the difference was. At times I thought it may be an improvement but in the end I found the standard snakeoil Kernel using HPET timer preferable to the 300Hz kernel with the TSC timer.  Exactly what was better I must confess I couldnt put my finger on. Also compared it to an SOTM SMS200 ultra and found it very similar with very slight and relatively unimportant differences.  So considering this is the vanilla version of Snakeoil with only some changes to timer frequency  and interrupt settings thats pretty good. Great work Agent Kith!!

 

I'm not super surprised here. You've moved from a tickless kernel (where timer interrupts are delivered only as required) to one where there's a timer interrupt 300 times a second. That's 300 times every second the OS could be doing something else, and whilst having that reference isn't a bad thing it's possible to go more granular (1000Hz not 300Hz). Not all tasks rely on the kernel tick for execution, in a preemptive kernel (what SO and most audiophile OS are built on) some tasks work in lieu of the kernel tick, though not everything. A fairer comparison would have been to have the tick at maximum frequency (1000Hz) - events needing the timer have over three times the timing resolution from their reference. Tickless is better, they go as they need so you focus programming/kernel tweaking efforts on what you need. Again, I don't know the limitations of an Atom CPU as well as Core. It's certainly an option I've compiled with and one that pretty easy to try. 

 

Fundamentally you're still missing out (for unexplained reasons) on a tickless (or semi-tickless) kernel with TSC, which is a much lower latency clock source than HPET. 

 

The progression of SQ should be Really slow tick < 300Hz tick < 1000Hz tick < tickless variants. That's a rough guide, there are exceptions. If your CPU is struggling supporting reasonable latencies with a 1000Hz tick going I'd upgrade the CPU.

 

9 hours ago, frednork said:

Also been dredging through this monolithic thread and was interested in latency. Its seems like the lower the better but how do you guys get it so low, mine is sky high!!!

 

I used to get caught up on this a lot. Not so much anymore. The team that helped deliver SO was (way) ahead on this as were a few others, and frankly Atoms (for a whole host of technical reasons) aren't designed to give stunning latency numbers. You'd have to strip the OS stupidly bare and run the CPU in a way it really wasn't intended (for power and energy management) to get solid latency numbers out of an Atom, and even then a Core would stomp all over it for similar frequencies/loads.

 

Cycle latency isn't really a measure of how awesome an OS is for an audio application. You care more about jitter out of the USB port, and frankly just how full those packets are when they leave. In short, temporal consistency at the audio interface. The rest of the PC can be drunk on Long Island Iced Teas for all you care, as long as the audio interface is doing what you need it to. This is hard to directly measure using OS metrics (it's possible though you need to build a kernel specifically with the necessary tracers etc, and even then I'm not sure it's so easy). 

 

A good indirect measure is to work on tuning OS jitter - so you're less concerned with how fast your OS can execute repeated tasks, and more concerned with how consistently it can do so. Then to tune preemption and silicon latencies around your audio device. (This is a broad description). 

 

Again... this is easier with Core than Atom. The only thing Atom does really well for audio:

• Limited power makes power supply design simpler (though it's actually very hard to find an Atom board with a high-quality, multi-phase power circuit) - look carefully on a motherboard, the last bit of power conversion isn't the 12V UltraExpensiveThenModifiedToBeEvenMoreExpensive PSU you bought for your PC - it's the stage that feeds the CPU, which has a bunch of VRMs on it, which left unchecked are changing frequencies 300k times a song or so. And that output isn't beautiful, particularly when you have only a few VRMs and you're operating at low voltage (hi there Atom boards), and... 
• It's cheaper 

 

There are also a few tricks in how a kernel goes together that help considerably here that I've seen absolutely no one list openly. I'm pretty sure I'm not the only person using these, which leads me to conclude it's a material difference that those that know are keen to keep.

 

I've a friend that's former chip designer for a well-known (to this thread) microprocessor company and I'm assured that first point about power is pretty significant. There are a few things we can do (BIOS hacking, maybe microcode hacking, motherboard PSU redevelopment) but none are simple. For consumers like us it's about best compromises, consistent with the advice I'd been given at my price point a low-power Core design worked (considerably) better than any Atom board I'd had. Others may vary in their experience. 

 

If you're going to build a PC around a very low power design, honestly I'd do it around an ARM. Power is even lower and the power system design requirements are more amenable to an audiophile solution. No surprise that cats like @eltech are able to procure a basic ARM-based box on the cheap and that, with zero modification or tuning, it sounds pretty good. No surprises it's what's in your SoTM box. Imagine a SO release for ARM, then. It'd be quite the thing.

[a.dent]

7 hours ago, rmpfyf said:

If you're going to build a PC around a very low power design, honestly I'd do it around an ARM. Power is even lower and the power system design requirements are more amenable to an audiophile solution. No surprise that cats like @eltech are able to procure a basic ARM-based box on the cheap and that, with zero modification or tuning, it sounds pretty good. No surprises it's what's in your SoTM box. Imagine a SO release for ARM, then. It'd be quite the thing.

Here you go https://www.snakeoil-os.net/forums/Thread-Any-Interest-in-ARMv7-builds

[Guest rmpfyf]

1 hour ago, a.dent said:

Here you go https://www.snakeoil-os.net/forums/Thread-Any-Interest-in-ARMv7-builds

Bam, now just to find some reference hardware.

[frednork]

2 hours ago, rmpfyf said:

Bam, now just to find some reference hardware.

 

4 hours ago, a.dent said:

Here you go https://www.snakeoil-os.net/forums/Thread-Any-Interest-in-ARMv7-builds

thats great, I am up for it. what are the contenders ? assuming not pi?

[Guest rmpfyf]

15 minutes ago, frednork said:

thats great, I am up for it. what are the contenders ? assuming not pi?

Something with a simple power stage and a decent low-jitter oscillator... and the right about of peripherals. I tried an NVIDIA board and it was OK - had to lend it to someone else before I really got stuck into it - I'd wager a $50 HTPC or similar is probably going to be pretty close, particularly if the video portion can be shut off occasionally. Feed it with a nice PSU and it'd work well. There are, of course, MiniITX ARM boards...

 

Now it's not going to transcode DSD but... for playback, just fine. Maybe we could fund some dev for the SO crew to have a go?

[frednork]

21 minutes ago, rmpfyf said:

Something with a simple power stage and a decent low-jitter oscillator... and the right about of peripherals. I tried an NVIDIA board and it was OK - had to lend it to someone else before I really got stuck into it - I'd wager a $50 HTPC or similar is probably going to be pretty close, particularly if the video portion can be shut off occasionally. Feed it with a nice PSU and it'd work well. There are, of course, MiniITX ARM boards...

 

Now it's not going to transcode DSD but... for playback, just fine. Maybe we could fund some dev for the SO crew to have a go?

Sounds like a great idea. how do we make this happen?

[Guest rmpfyf]

2 hours ago, frednork said:

Sounds like a great idea. how do we make this happen?

Hope Kith's reading and says 'sure, head over to this Snakeoil OS page and follow some instructions to donate'  

 

I would hope the outcome's intended to be a cheap one, or a SMS-200 becomes compelling. 

Edited October 17, 2018 by rmpfyf

[stuckinhere]

Best site I've found for info on ARM boards is http://linuxgizmos.com

The annual roundup they do of the best open-spec boards is worth a read 

http://linuxgizmos.com/2018-reader-survey-of-116-open-spec-linux-android-sbcs/

 

 

64bit ARM board builders:

https://www.96boards.org

https://www.pine64.org (High spec low cost options + dedicated i2s pins)

 

[Guest rmpfyf]

6 hours ago, stuckinhere said:

Best site I've found for info on ARM boards is http://linuxgizmos.com

The annual roundup they do of the best open-spec boards is worth a read 

http://linuxgizmos.com/2018-reader-survey-of-116-open-spec-linux-android-sbcs/

 

 

64bit ARM board builders:

https://www.96boards.org

https://www.pine64.org (High spec low cost options + dedicated i2s pins)

 

 

Nice! Going to have a more detailed look tonight.