Jump to content

Tasso

Building the ideal(ish) Music Server

Recommended Posts

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. 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

 

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)

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites


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...

Share this post


Link to post
Share on other sites

.... 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Edited by davewantsmoore

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×