Tweaker's Rash

[nige2000]

Basically we need someone Linux guru to Create and write a player that will need to go through the same testing as jlp and mqn

First of all we could hear what standard SQLite sounds like on more optimised, simpler hardware. As I said if these software optimisations are reducing noise etc. that is endemic to complex hardware running a complex OS, then softwar etweaks may not be so important with better underlying hardware

Wonder what Fredericks linux would sound like on a modded pc

Why not on a better than modded PC?

Maybe
I'm in for a bit of testing on this
Should be a nice bit of cheap experimenting

[jkeny]

I don't think there's anything digital to rival mqn on a heavily modded pc atm

Yea, I remember hearing the same said of JPLAY :)

[nige2000]

I don't think there's anything digital to rival mqn on a heavily modded pc atm

Yea, I remember hearing the same said of JPLAY :)

Lol
That's what the "atm" was for

[jkeny]

Here's one of the posts that tweaked (pardon the use of the word) my interest http://www.diyaudio.com/forums/twisted- ... ost3810108

I personally tried Amanero and XMOS2 based USB receivers. While SQ is mostly affected by DAC chip itself (and its implementation, of course), on paper I2S is the better solution.
I found something really interesting, while measuring Volumio's performances (read posts above). While using i2s, jitter was not affected by changes in O.S. parameters. Using Ramplay, software mixer or different resampling methods was resulting in comparable jitter values.
That was not true with USB, changing parameters above had significant impacts on jitter values.
So, my point is, USB is OK. I2S is the way to go for the highest SQ. And since these devices offer that chance, why not using that??

I believe this guy measured jitter with an Audioprecisionn & I'd noticed he says that with using a USB DAC jitter changed with changes in OS parameters (& this is probably true of software tweaks)
PS I would have liked to have seen these jitter measurements - I Believe he is writing an article for March's Audioreview in which jitter measurements feature!!

[Fran]

Fryderyk's Linux build sounded great. I would be happy to host another ca get together to have a look at this. The idea of gentoo is that it only installs exactly what's needed for your build. So it takes a bit of time and patience (in short supply atm) but you get an exactly tailored build.

I tried it and failed, was under pressure for the laptop I was using for other tasks. I might try it on a spare SSD on the audiopc and see how it sounds.


Fran

[Fran]

Oh yeah, another thing. I think a raspberry pi is probably aiming a bit low. A lot of users complain about the slowness. I've almost pulled the trigger on the Odroid U3 a couple of times... Worth having a look at maybe?

Fran

[nige2000]

Yes raspberry too far down the food chain for me too
I'd be looking for 2 usb 3 ports 4gb ram capable and with a decent cpu

JK did you not come across something like that a few months back
I remember being tempted to get one

this looks capable

[Aleg]

Nigel

Do you mean like thse ALIX boards: http://www.pcengines.ch/alix.htm ?

A bit low on the RAM-side

Cheers

Aleg

[nige2000]

Nigel

Do you mean like thse ALIX boards: http://www.pcengines.ch/alix.htm ?

A bit low on the RAM-side

Cheers

Aleg

dunno
untravelled waters
but id get it hard to beleve in something that couldnt run a web browser fluidly

its all about what these platforms dont have, in regards unused features interrupts and noise making devices

if these platforms have no dc-dc switchers in em, no unnecessary ports,slots etc etc a skeleton OS

granted the player would need similar development as MQn and JLP

maybe if we could get Frederick on board
pick a linux board
buy a few of em and get to work on it

it would take time

[jkeny]

Guys, you're missing the point of the exercise - to keep the hardware platform used as the audio rendering device as simple a possible for the reasons that Aleg mentions - we want a single function, low power device which means fewer components on-board. We have already been exposed to this in software with MQN & JLP & have done our experiments in hardware so we know that simpler is better.

The benefits of this we already have spoken about - simpler power supply with no on-board switched mode regulators (linear regulators, battery powered is preferable) -> fewer areas that generate noise - fewer data conversions i.e no conversion from PCM to USB for receiving by a USB DAC to convert back to I2S - straight to I2S instead. In other words as direct & simple a path as possible at what seems to be the critical point in the audio chain, the audio rendering point (we have Gordon to thank for focussing our attention on this area as being the most sensitive for sound quality)

Ideally, an embedded processor is what I want to end up with - just a raw processor + DAC (& have control over how it contacts the outside world i.e what I attach) so even the Raspberry Pi is too complicated for my ultimate solution (it has too many superfluous components on-board) but it's a good first experiment. It has some flaws, agreed - the USB bus is a shared bus which seems to have some throughput issues but I'm intending to use it's I2S output which comes direct from the ARM processor & the processing power of it's ARM chip is no issue. Edit: How often have we heard the argument put forth in the JPLAY/MQN wars that audio handling is a piddly task for a modern processor? It was true but missed the point that audio handling is happening in a multi-threaded bloated OS.

For somebody who wants to use the USB ports & a USB DAC then a Beaglebone Black seems to be the platform of choice but they are all sold out. Lots of other choices - just a few:
http://www.wandboard.org/index.php/downloads
http://www.geek.com/chips/very-tiny-45- ... x-1569433/

A side note: Hey, while searching for alternatives I came across this piece of info. I've been saying for a long time that the growth area & where to invest your money is "batteries" - see here http://www.geek.com/mobile/lithium-ion- ... s-1584649/