Building the ideal(ish) Music Server

[AccuTidal]

All good Mick. I was going to do the RPi for you as a compliment, no string attached. Please shoot me a pm, if I can be any assistance to you.

Soon I will get my Accuphase DC-37, then my DDDAC will be off to @Doncentric for his magical finish. Once he is done with his magic, it will be delighted to have this DDAC circulates around W.A for those interested?

Edit: it can be heavy piece of DAC. Weight will be approx 35-40kg if not more. [emoji1]

Edited August 29, 2015 by Chanh

[TP1]

@@statman I should also say that we are trialling a new Linux distro built by a local software Guru and audio enthusiast. It allows 7 different options for players ( via a menu) including JRiver and different versions of MPD and Squeezlite. I believe it has ultra low lower kernel latency - even lower than Audiophile Linux and so far it is proving to be the ducks nuts. No need to tweak it further to get JRiver sounding great because it is already as lean and mean as currently seems possible.

There are one or two issues being sorted at the moment and @@Chanh will be the third person to trial it so we hope to be able to give more feedback over the next week or so.

[davewantsmoore]

davewantsmoore - yes, by source I mean PC (highly customized), as mentioned several times by several people the aim is to minimize noise produced by processing unit and surrounding equipment's, many of the companies producing streamers took this path, Auralic, JFDigital and many others created customized ARM based boards to optimize this aproach...

 

Ok sure.    Yes, if we're linking a 'computer' directly to a DAC via I2S .... then that is definitely the desired approach.      Yes, going with an ARM (or similar) computer ... and then a separate DSP where all the clean signal generation happens....   and then very short well engineered I2S lines straight to a DAC.

 

My "argument" (not that I'm trying to have an argument) ....  against I2S being a good idea, was in an "x86" style computer .... where we would be taking I2S form the motherboard, or from an expansion card...   and a quick poke around will show anyone how hard it is to get a reasonable signal out.

 

CPU/buffer/FPGA... for better understanding you can take this layout as an example http://www.jfdigital.com/asp_bin/UploadFile/image/20150205/20150205202616631663.jpg...

 

Sure thing.   Good approach .... but not what I though the other guys were talking about.

 

 

short I2S lines - nope, I2S lines comming out of FPGA chip aren't isolated nor differential so to prevent additional noise comming out of surrounding units (EMI/RFI) hitting those lines you wanna make sure these are short untill they hit LVDS driver where they become differential, driver is usually located near the I2S connector (in my case HDMI) and we are still talking about connections inside of source enclosure...

 

Yep, understood

 

How far do you send your differential signal?    I tried 12m, but I just ended up using SPDIF in the end.

 

USB - yes and no, I don't think/believe anybody will be able to fully optimized usb connection especially the source side, it can get as closer as possible but not good enough, that's why I mentioned in my first post that it's more beneficial to look at DAC side of the USB connection where is the majority of the influence, good USB convertor on DAC side can solve most of the bad behaviour of a PC

 

Agree    ....  DAC side is very important --- which is why changes to source side are a little bit hard to generalise about.

 

on the other hand I fully understand Tasso's and others approach trying to optimize source as not everybody has an option to optimize DAC side so it's kind of trade off...

 

Definitely.

[davewantsmoore]

I have moved away from Windows after gone through it extensively. From one PC, to dual PC setup via Ethernet, JPlaymini, dual JPlay, and hours of further OS tweaking to get it to bare minimal. Window7, Window8, Window Server 2012.... After all, found Linux and since have never look back.

 

I have spent most of my time with Linux for audioPC...  especially a decade ago it was the much better solution.    Been half Linux / Mac for the past few years ....  but making the move to Windows now as I'm heading down the Jriver route   (due to good support for DSP which I use for my active crossovers .... and very high quality video rendering).

 

It feels somewhat dirty   (ewww. windows)

 

 

Of course... this (using windows, jriver, etc.) requires a DAC which isn't super sensitive to the source to get high quality.

[TP1]

I have spent most of my time with Linux for audioPC...  especially a decade ago it was the much better solution.    Been half Linux / Mac for the past few years ....  but making the move to Windows now as I'm heading down the Jriver route   (due to good support for DSP which I use for my active crossovers .... and very high quality video rendering).

 

It feels somewhat dirty   (ewww. windows)

 

 

Of course... this (using windows, jriver, etc.) requires a DAC which isn't super sensitive to the source to get high quality.

 

 

 

Have you tried Jriver in Linux?   The latest incarnation is sounding quite reasonable. 

[realysm42]

@@statman I should also say that we are trialling a new Linux distro built by a local software Guru and audio enthusiast. It allows 7 different options for players ( via a menu) including JRiver and different versions of MPD and Squeezlite. I believe it has ultra low lower kernel latency - even lower than Audiophile Linux and so far it is proving to be the ducks nuts. No need to tweak it further to get JRiver sounding great because it is already as lean and mean as currently seems possible.

There are one or two issues being sorted at the moment and @@Chanh will be the third person to trial it so we hope to be able to give more feedback over the next week or so.

 

Hey Tasso, I've never used a different OS other than Windows. Would I be able to install it and easily revert back if I didn't like it?

 

Or does anyone know of an FAQ that answers these kind of questions please?

[davewantsmoore]

Of course... this (using windows, jriver, etc.) requires a DAC which isn't super sensitive to the source to get high quality.

 

or... to the extreme.... a "2 PC" setup like jplay, hqplayer, or other custom ways to do it.

 

(where one PC is highly optomised / lower power)

Edited August 29, 2015 by davewantsmoore

[TP1]

Hey Tasso, I've never used a different OS other than Windows. Would I be able to install it and easily revert back if I didn't like it?

 

Or does anyone know of an FAQ that answers these kind of questions please?

 

I  think we need to catch up and  and demo  the options.   I have been simply swapping drives for different operating systems so no need to wipe anything to compare.  Those better versed in  these matters have everything on one drive or NAS using different partitions but that is a bit beyond me at this stage.

[davewantsmoore]

Have you tried Jriver in Linux?   The latest incarnation is sounding quite reasonable. 

 

Yes, but it does not yet support the features I mentioned.

 

On Linux I use hqplayer, which has the audio features I need, but not the video support....     also depends on which dac is used as to whether any of these things make a worthwhile difference for me.

[kukynas]

I wouldn't know what system Accuphase use to isolate noise from USB sources but I do know that they rejected all " conventional" approaches and chips like Xmos as being inadequate and developed their own interface. 

 

funny you mentioned it  , in my view they just did what everybody else would do if they'd like to stay imune to the source, SA9227 USB chip, Spartan6 FPGA source devider, and as said in my first post reference Sabre DAC chips which makes that (relative) imunity possible...you will find simillar approach in new Gustard X20 DAC

 

designer and builder of my dual differential sabre DAC board took little bit different approach with detachable USB module and opamps in output stage so I can choose my prefered solution...

 

 

 

How far do you send your differential signal?    I tried 12m, but I just ended up using SPDIF in the end.

 

due to fact my streamer sitting next to my DAC I didn't have to use more than 1m long HDMI cable...

[davewantsmoore]

funny you mentioned it  , in my view they just did what everybody else would do if they'd like to stay imune to the source, SA9227 USB chip, Spartan6 FPGA source devider, and as said in my first post reference Sabre DAC chips which makes that (relative) imunity possible.

 

(Y) ....  are you aware if they (accuphase) have the ASRC turned off in the DAC chips?   As mentioned I got interested in providing my own clock to the chip... which I did, but I found it hard to improve things as I don't have lots of test equipment / skills   (ie.  I am not an electronics guru).

 

I would be surprised if accuphase are simply using the 'jitter eliminator' inside the ESS ..... but I also have no idea.   Do you know?

 

 

due to fact my streamer sitting next to my DAC I didn't have to use more than 1m long HDMI cable...

 

Ok.  (Thanks) ...   I was just using the teleporter modules... which was fine....  but I wasn't able to gain a worthwhile improvement over SPDIF in my situation.

[kukynas]

Dave - I think they do using PLL of the chips otherwise you won't see that master clock xo between sabre chips, in my view best option, gustard takes oposite aproach and feeding master clock from FPGA

I mentioned somewhere here or in other post that change of the xo isn't enough to improve things otherwise something wrong with your circuit so you shouldn't be surprised on the other hand xo is very sensitive to noise and transient current so you can improve things by installing/changing better regulator circuit if your current one isn't up to spec...

hope Tasso don't mind as we are bit OT....

[TP1]

funny you mentioned it , in my view they just did what everybody else would do

...

Companies with serious R&D teams have developed technology you will never find with a Google search. I have lost count of the latest and greatest crazes in DAC design from hitherto unknown designers including DIY variations which have not lived up to expectations.

I made the post about the Accuphase to clear the air about the purpose of developing the digital source and not to be distracted by the issue of DAC interface. Why is this important? Because the development of CA has been held up for years by that attitude, much to the appreciation of Antipodes Auralic and others

[kukynas]

Tasso - I'm glad you bring it up because Accuphase is nice example how the things should be done and how others should learn, funny part was that we are talking about effect of imunity again... maybe lost in translation of my czenglish 

 

Dave - teleporters are great for that purpose... so do I gave up, but from different reason, my streamers wasn't able to send PCM and DSD over same lines so I could either listen to one or the other, ended up using AES/EBU and happy with it, don't need more than DSD64... 

[alcarp]

Hi @@davewantsmoore ... I tried sending you a pm and get this message:

Is your mailbox full?

 

The member davewantsmoore cannot receive any new messages

[Guest myrantz]

Here's a rough stats of my miniITX process after a few hours of playback (approx 7 hours)..

top - 21:18:44 up  6:47,  1 user,  load average: 0.50, 0.36, 0.40
Tasks:  54 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.3 us, 30.8 sy,  0.0 ni, 68.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   4034636 total,    99772 used,  3934864 free,        0 buffers
KiB Swap:        0 total,        0 used,        0 free.    54272 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
   42 root     -94   0       0      0      0 S 16.9  0.0  66:21.25 irq/7-ehci_+
   43 root     -51   0       0      0      0 S 11.3  0.0  36:29.41 irq/10-
    3 root     -96   0       0      0      0 S  1.3  0.0   2:33.49 ksoftirqd/0
  484 root      20   0  175976  13256   6900 S  0.7  0.3   2:40.46 squeezelite
  503 root      20   0  176084  13272   6884 S  0.3  0.3   3:07.49 squeezelite

This is a C&P when I'm doing DSD. Note that the third line "sy", which means system CPU time, that's approx 30%. And if you look at the process list you'd see why. PID 42 is the main culprit - EHCI basically means USB 2.0 (I'm using the onboard USB filtered by that elfidility thingy for this test)... I have NFI why IRQ10 (PID 43) is so high TBH, this appears to be a bug on the motherboard or the kernel I'm using.

 

Anyway, the load is so high is because squeezelite use very little buffering. It constantly need to write data to the USB bus almost all the time (many small write vs one big write). Think of this as the opposite of memory play.

When you look at the CPU time of squeezelite, and compared to EHCI, you'd see the operating system is busy most of the time dealing with USB I/O... Redbook (44.1/16) will use less (approx 10% CPU)..

 

Looking at the load average, we can see this isn't that much of a problem (I'm not doing any additional processing like resampling, or DSD->PCM conversion). And if I am doing additional processing - then obviously a low power, low processing Atom may well struggle unless I increase buffering.

 

This relatively high CPU while generally ok, is likely to have an impact on the overall responsiveness of the kernel.

 

Imagine if we can get rid of that USB overhead, bypassing it entirely (or find a motherboard that don't incur such a high cost with USB operations when doing minimal buffering) - the loadavg will go even lower.

 

Obviously an audio sound card (e.g. Asus Essense ST/STX) with a good S/PDIF output will eliminate all that. However it doesn't do DSD. :lol:

 

Having said all that, USB ain't all bad... It's just one extra layer of encoding/decoding which one can try and see if it's worth eliminating. 

 

[acg]

Here's a rough stats of my miniITX process after a few hours of playback (approx 7 hours)..

top - 21:18:44 up  6:47,  1 user,  load average: 0.50, 0.36, 0.40
Tasks:  54 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.3 us, 30.8 sy,  0.0 ni, 68.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   4034636 total,    99772 used,  3934864 free,        0 buffers
KiB Swap:        0 total,        0 used,        0 free.    54272 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
   42 root     -94   0       0      0      0 S 16.9  0.0  66:21.25 irq/7-ehci_+
   43 root     -51   0       0      0      0 S 11.3  0.0  36:29.41 irq/10-
    3 root     -96   0       0      0      0 S  1.3  0.0   2:33.49 ksoftirqd/0
  484 root      20   0  175976  13256   6900 S  0.7  0.3   2:40.46 squeezelite
  503 root      20   0  176084  13272   6884 S  0.3  0.3   3:07.49 squeezelite

This is a C&P when I'm doing DSD. Note that the third line "sy", which means system CPU time, that's approx 30%. And if you look at the process list you'd see why. PID 42 is the main culprit - EHCI basically means USB 2.0 (I'm using the onboard USB filtered by that elfidility thingy for this test)... I have NFI why IRQ10 (PID 43) is so high TBH, this appears to be a bug on the motherboard or the kernel I'm using.

 

Anyway, the load is so high is because squeezelite use very little buffering. It constantly need to write data to the USB bus almost all the time (many small write vs one big write). Think of this as the opposite of memory play.

When you look at the CPU time of squeezelite, and compared to EHCI, you'd see the operating system is busy most of the time dealing with USB I/O... Redbook (44.1/16) will use less (approx 10% CPU)..

 

Looking at the load average, we can see this isn't that much of a problem (I'm not doing any additional processing like resampling, or DSD->PCM conversion). And if I am doing additional processing - then obviously a low power, low processing Atom may well struggle unless I increase buffering.

 

This relatively high CPU while generally ok, is likely to have an impact on the overall responsiveness of the kernel.

 

Imagine if we can get rid of that USB overhead, bypassing it entirely (or find a motherboard that don't incur such a high cost with USB operations when doing minimal buffering) - the loadavg will go even lower.

 

Obviously an audio sound card (e.g. Asus Essense ST/STX) with a good S/PDIF output will eliminate all that. However it doesn't do DSD. :lol:

 

Having said all that, USB ain't all bad... It's just one extra layer of encoding/decoding which one can try and see if it's worth eliminating. 

 

That is interesting Myrantz.

 

There are a few guys using my dac/pc combination that have experimented heavily with the timing of the USB protocol.  They ended up with expensive clocks on the PCIe USB card and dac USB input board and their efforts were largely toward a more accurate synchronisation of the clocks at either end.  Because of how the USB protocol works (warning - gross over-simplification following!) the PC basically spits the data out at a predetermined rate to the other end of the cable.  This rate is basically the packet rate (i.e. the number of times a second that it sends a chunk of information down the line) and is fixed.  However the amount of information that is put in each packet determines the data transfer rate.  Think of it like there are trains leaving Central Station every ten minutes...the number of people on each train (or packet) determines the people transfer rate even though the trains/packets leave with the same regularity.  The receiving end of the USB cable basically sends messages back to the host side along the lines of  "whoa back too fast" or "pick it up slacker" and the computer side adjusts the amount of information that it puts into each "packet" so that things stay synchronised and information is not lost through under or overruns.  So the idea of these USB clock synchronisation guys was to "tune" the clocks at each end of the USB cable to as closely aligned as possible so that the amount of information put into each packet is held as constant as possible in an effort to minimise these little messages to speed up or slow down, thus theoretically reducing electrical overhead at both ends of the connection.

 

Well they swore black and blue that it worked and that the sound improved but when the main proponent took his pc creation and modified dac to the manufacturer it did not sound as "good" as a simple grounding trick with the USB card (the trick is lifting the USB card from chassis ground - which may need to be used with other grounding modifications in any particular system) and so they walked away with their tail between their legs after a lot of talking themselves up.  The main proponent has shifted his "angle" and is now offering heavily modified pc's with high quality clocks throughout...again he swears that they make a difference...but it remains to be seen in my opinion.

 

Either way, the info I gave above in the first paragraph is useful in getting an overview of how the USB protocol works.  It is basically always ticking over sending packets down the line.  When there is no information to send the packets are empty, but they are still being sent.

[Guest myrantz]

That is interesting Myrantz.

...

Either way, the info I gave above in the first paragraph is useful in getting an overview of how the USB protocol works.  It is basically always ticking over sending packets down the line.  When there is no information to send the packets are empty, but they are still being sent.

I may well be walking away with the my between my legs too. Done that often enough to not get ashamed by it really.

But at the end of the day, that's how USB works, obviously you can improve the CPU usage by sending larger chunks of data over, or to use a higher power CPU that makes this less of a problem, but to use your argument - it's just a band aid... If you look back at the top stats again, you'd see "68.9 id".. That means idle.. So the idea is to increase that to close to 100%.. Just so to get a ideal OS that's always ready to execute an instruction when called to.

 

Technology moves ahead very very quickly.. The above is with USB 2.0 audio devices, maybe 3.0 devices will be better. As it is, DC-37 via USB is pretty good, so despite the slight drawbacks, it's still pretty acceptable.. 

 

At the end of the day - I2S is really for people who want to go beyond "pretty acceptable".. One man's version of ideal(ish) is another man's version of foolish. 

[acg]

 

At the end of the day - I2S is really for people who want to go beyond "pretty acceptable".. One man's version of ideal(ish) is another man's version of foolish. 

 

I am unfamiliar with the I2S audio protocol.  What is it about it that makes you think it may offer a solution?  (Serious question)

[Guest myrantz]

I am unfamiliar with the I2S audio protocol.  What is it about it that makes you think it may offer a solution?  (Serious question)

Why I think it's a solution? Coz it's not USB (serious answer)...

If you use a hardware audio card (and not a emulated one like USB), the overheads are lesser. Try using a hardware audio card and see if the CPU is anywhere as close to the USB ones shown above.

 

Similarly, I2S signals has less overheads than other forms of communications (e.g. it has no error checking, no session creation, and no such things as ack or nack). Bitclock pulsing for each bit in the data line, and a word clock telling where that information is for the left channel or the right channel.. That is it... Less layers of encoding/decoding (see earlier pic from Pink Faun).

[AccuTidal]

I have a few guys joining me tonite with the UK audiophile. Perhaps, a demonstration of USB vs I2S into the same DAC and the realistic observations can be post here?

If it is not too late for @realysm42 and , please drop by tonight for this gtg. We might even demonstrate to you that different Ethernet cable will sounds differently, and it is very obviously noticeable too.

Anytime from 6pm on ward is fine. Snack and beverage are in the Shed! [emoji6]

[kukynas]

I have a few guys joining me tonite with the UK audiophile. Perhaps, a demonstration of USB vs I2S into the same DAC and the realistic observations can be post here?

awaiting your result  , this could be very interesting gtg, streamer will be the same for both cases or different for USB and I2S? will be connection of I2S single ended or differential? 

 

thanks...

[davewantsmoore]

.... and so they walked away with their tail between their legs after a lot of talking themselves up.  The main proponent has shifted his "angle" and is now offering heavily modified pc's with high quality clocks throughout...again he swears that they make a difference...but it remains to be seen in my opinion

 

Using external clocks may make a difference, but the reason isn't due to quality of the clock itself.      It is because the clock is (might be) fed with it's own separate power supply .....  and so the garbage which a clock sends back into the power supply doesn't go where we don't want it.

[davewantsmoore]

At the end of the day - I2S is really for people who want to go beyond "pretty acceptable".. One man's version of ideal(ish) is another man's version of foolish. 

 

I am wondering why people think that creating an I2S signal inside the computer, and then sending it to a DAC.....   will be higher performance, than the computer sending a USB packet .... and the receiver (in a more optimized environment)  created the I2S signal for the DAC ?!

 

It can be done, sure.... but it is a lot of effort ..... for what reward?

 

 

Why I think it's a solution? Coz it's not USB (serious answer)...

 

Never mind then.

[davewantsmoore]

I don't see such CPU time using USB audio here (low latency)

Edited August 31, 2015 by davewantsmoore