Author Topic: PC source with DRC capabilities  (Read 22541 times)

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
PC source with DRC capabilities
« on: May 17, 2015, 11:17:01 AM »
Happy to go into it if it helps anyone.

The first bit concerns CPU load and processing hierarchies.

Essentially, a PC has a lot to do - showing video, running background jobs, dealing with odd things on an interrupt basis for all sorts of applications (network, security, etc). For this reason an operating system kernel (the "guts of it") usually isn't built to execute things in real-time. It's built to execute things as fast as it can without missing anything, which means scheduling tasks on a priority basis. Playing audio is not a critical priority.

You can get around this to a degree by - in Linux at least - rebuilding ("recompiling") your operating system with realtime priorities, such that things get done as they happen. You've got to make two concessions to enable this: you'll need (relatively) plenty of horsepower (CPU capability, memory bandwidth... not necessarily memory), and you've got to limit what the kernel can actually do - which includes some degree of error checking when it wants to do a few more things than what you ask it (you've got to let it "drop" a few tasks). So end up running a very lightweight operating system installation, much lighter than most are used to.

At around this point you realise that streamwise decompression can also affect audio reproduction - which is why (as I've discovered under the aural microscope that is the Killer DAC) that FLAC can be used as an excellent archival tool (it compresses efficiently, contains metadata and a form of digital 'fingerprint' to ensure that what you extract is actually bit-perfect enough to prove whether data is corrupted or not, which WAV can't do) however on-the-fly decompression can limit playback quality. And you end up with either WAV (where your playback engine supports metadata in WAV) or AIFF (either support uncompressed PCM audio). Depending on system fidelity and the way your system handles load, your FLAC/PCM conversion results may differ to varying degrees. Bottom line? My home theatre PC has 4 CPU threads and there are usually more than 4 processes running on the CPU, whilst normally it'll switch quickly enough to have decompression ahead of time, it's not perfect and needs to give me results enough to play audio samples 44,100 times a second. Tough ask, not impossible. If your media PC drove a second, headless (e.g. "no video") PC that just played audio with a network connection enough to tell it what to okay and when, this might be possible (actually an ideal setup).

Getting this far already gives some substantial benefits - by comparison, a CD player has one mission in life - playing CDs! It doesn't monitor network connections, spit out video to your TV, run various disks and devices... it has one core task, a predictable and very low number of exceptions to that task (e.g. hitting stop, pause, etc) and that's about it.

The second concerns the transport path.

From the CD player to a DAC is usually PCM in Redbook PCM -> some data (header) removal in an linear process -> I2S -> analogue, with one very stable clock guiding things. A PC is obviously very different.

You can bet the clock in a PC (a) isn't as nice as what Steve or Craig put in a DAC, (b) isn't set for a master frequency that's some multiple of Redbook or "Video" audio families (44.1/48kHz), so some non-whole-number re-clocking is going on. We can get around this much by running asynchronous USB, which at least allows us to use a nice, external clock, which is how we get boards like the Amanero coming into provenance with two nice crystals of different master frequencies representing the two audio sampling frequency families. Good people will put them together with very stable power supplies and the like because at this point we're still sending data over hardware that's RF-sensitive, the only way we can do that in a PC is to run it out optical though that'd essentially be essentially a SPDIF signal, which we don't like because it contains both audio and clocking data in the same packets, and we already noted that the quality of the PC's clock isn't going to amuse Steve in any way.

Which brings us to the other side of this problem, the creation of these audio packets in a PC. A PC routes SPDIF internally (AES/EBU to be modern about it). Asynchronous USB simply ensures they get to your DAC's I2S converter without dropping any, it doesn't fix what's inside them - all that beautiful work in a good CD transport for noise isolation ensures there's minimal RF playing around with the stream of 1's and 0's. Life's very different inside a PC - there's a lot going on electrically to interfere with things. You can do a good bit here - deleting components with motors, removing WiFi cards, etc. But it doesn't stop a PC being a PC. Mine serves multimedia, which means the PC is very near a very electrically noisy Samsung TV (for now), which has really upset bliss to a good degree.

Bit-perfect in a PC is ultimately a bit of a fallacy (currently), though you can get close.

Even having the hardware as optimised as possible, there are other, interesting things to work through - finding a signal path in any operating system that doesn't do some internal signal processing is a lot harder than you'd think, and presents some interesting challenges when you're there: a "best" path means forgoing some things you'd take for granted in PC that a CD player doesn't have to do, like playing two sounds at once. Two sounds means having a software engine in the background that's fast enough to resample the sounds to a common frequency, common volume levels, common respect for a software volume control... doing this at low CPU use means quality compromises in a resampling engine. Getting rid of it all - not impossible but not easy - presents new challenges to work through, like volume control (most software mixers resample internally, and usually to 48kHz - not ideal for Redbook). Which brings around to understanding why Steve burns his CD's just so, or why good analogue controls are prized... no lost CPU cycles there, no compromises to bit-perfect-ness, no passing through your noise floor in it's entirety every time.

Living with the Killer DAC for a bit now I can actually hear differences in all the above. Real-time resampling can give a sibilance-type effect that'll have you tweaking well into the night to fix. Every time I thought I had a change licked something happens, the sound stage goes back to 2D, or vocals do and guitars don't... this and I'm running an inline rotary attenuator presently to dial things in...  which plays havoc with the local interference, and yet doesn't sound as sweet with its case ground (vocals aren't 'in the room' and the Killer loses it's magic temporarily).

My PC presently has had it's wireless removed, is a low-power fanless setup running a single SSD in a fairly dense aluminium case. It will accept a linear power supply, though I have not yet provisioned it with one (there's a Thor upstream in readiness). It runs a customised version of Ubuntu with a realtime kernel and some other, ongoing system modifications for simplicity. System processes that are not necessary are removed. Audio is in another room served by a network-attached storage device; it has dual ethernet to a very fast switch and it's quad ethernet (aggregated) to the NAS. I can get very close to bit-perfect and bypass all internal routes to the USB audio device that feeds the Killer, something I'm rolling back a little to try and get a software volume control in.

A CD player is much, much easier.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #1 on: May 30, 2015, 06:20:28 PM »
I wonder why that is?     I would have thought that a properly engineered solution with SSD storage, should have the advantage over an old spinner.     

I havent given up hope that someday someone will produce a pc style solution that is better.   So i dont have to waste time burning cd's.

Congrats on the purchase, and welcome to the forum.

For those it helps. I thought I'd share my experiences with the PC a little more. I should stress that the below represents an incomplete journey.

Good noise through a PC is about minimalism - mechanical, EMI/RF/etc, timing. This, and I wanted better performance than a Mac Mini.

The main build
So the hardware. She's very small. I use a Mini-ITX motherboard and an Intel low-power CPU (i3 4130T). Low-voltage memory, though enough to not need a swap file - 8GB is fine (and usually overkill). The machine is fanless and has no optical or mechanical drives installed - I got my case through HD-Plex, it's great quality and reasonably priced. I used a motherboard with built-in WiFi though in all honesty that's not ideal - accordingly my radios (WiFi and Bluetooth) are disabled. Dual gigabit ethernet, if you can get it, is ideal as you're simply getting into more bandwidth for data transfer, particularly if you keep your media uncompressed, or intend on using the same machine for video. On that - get a CPU that has built-in video. What's needed to boot and run it is stored on an SSD.

Update: I've since removed my wireless adapters and removed any extraneous hardware and power cable routing (e.g. you get a power cable for your hard disk which includes interfaces for three more... remove!). A significant difference in performance. Routing does make a difference, just as it does in any other device. I'll probably upgrade the power wiring internally soon; right now I'm making do with cut and insulated versions of what came with my case.

Get into the BIOS at some stage and disable anything you don't need. This is important.

Power supply
HD-Plex sells a nice and very regulated DC-AC power converter for HiFi use - which I have - and a linear power supply to match (which I'll be testing shortly). For the while I've been using a laptop power supply - not ideal, but it works. This asides all the usual rules apply - if your line power at home isn't exceptional, deal with that first. Craig talked me into a Thor and the difference was, in our home, audible. Your mileage may vary.

Where to store the media
It's far easier to have your media elsewhere, not least as SSD's aren't that big but your case will not have room for redundancy, more storage in the same case is more heat and interference. It's easy to run network-attached storage (NAS), just keep the data pipes big enough - CAT6 wiring, use a good switch (not an el-cheapo home router). Most good NAS have more than one Ethernet port and it's possible to run them as an aggregated link. Max out whatever RAM your NAS can take. Do what you need to in order to not drop any bits along the way! I'm having some pretty good success here; the usage experience is flawless - you'd not be aware the data's stored >25m away. Back to back it doesn't make difference if it's local - we don't even drop frames with Blu-ray media (ripped and stored - she hates the look of the Blu-ray player, so what discs we own are ripped and served over the network).

Choice of operating system
There's only one: Linux. You might be able to have direct access to the audio device though some interesting driver trickery in Windows, but you can't control or change operating system timing, which is partially where the magic is - it's a function of two things: (1) being able to alleviate responsibilities the operating system has, and (2) actually changing the way the operating system schedules tasks.

It's really simple: you can't rebuild Windows yourself. Windows is built with broad considerations - for some people it's a server, for some people it's an audio player, for some it's a gaming rig, for some it does a bit of everything. And it has to cover a wide variety of software and hardware. Great for general purpose use, not so great for single-minded audio greatness. It is possible to rebuild OS X to some degree (I understand Eric Hider at dB Audio Labs is doing similarly to great effect), though you're limited to spec hardware.

Linux is ultimately very flexible. And free. You'll need patience. I started with Ubuntu 14.04 because it's convenient an easy to play with, though you can start with something lighter if you know your end goals at the start (again, it's Linux, so you're free to chop anything to size). From there:

  • Uninstall any program you won't need.
  • Remove any web services you won't need.
  • Install some media playing interfaces. I run Kodi (what was XBMC) and mpd/mpc - the latter is a pure 'hit the audio hardware directly' utility and will serve as your back-to-back benchmark in comparing any work you'll do. Kodi has a nice trick in that it can be controlled via a phone or tablet app on the same network, so if your TV has any audible qualities you don't like (as per mine), you can control things fairly painlessly and with zero background noise penalty.
  • Remove Pulseaudio, the audio server - every operating system has something similar to make sure that any sound from any source can be played through any output (essentially a mixer/resampler/sequencer/effects engine), the difference in Linux is that you can actually remove it. Why? It resamples poorly, and though you can amend that to some degree, we don't need to play more than one source at a time, and we'll ensure our audio sources are Redbook anyway.
  • Edit configuration files for the Advanced Linux Sound Architecture (ALSA) - one simple tweak is required - set the mixing frequency to 44.1kHz. Redbook audio will no longer be resampled, period. You can't delete ALSA and don't want to, not least because if you're being hyper-modern about life you'll probably have made the same key oversight I made, and built yourself a system with no analogue volume control (so you'll need to do that in software). ALSA has a mixer, "dmix", but you don't want it to resample Redbook (with some trickery you can set what it does and doesn't resample, if at all - useful if what happens south of your computer doesn't deal with 44.1kHz and 48kHz frequencies equally).
  • Make sure you're ripping everything as uncompressed PCM or Craig and Steve will rightly never let you hear the end of it  :D Linux has plenty of good and free utilities for this, I use abcde - does full error/CRC checking, generates metadata, and the related ripping engine is CDParanoia - which is about as exacting as the title sounds. If you want something with AccurateRip, try Morituri.
  • Set it up to boot into something easy to use though lightweight (mine boots straight to Kodi).
  • Any other tweaks you think you'll need for ease of use.

At this point things are sounding pretty damn good, though we want friggn awesome levels of both audio and nerdism, so we push on.

Linux, like Windows (and to a lesser degree, OS X) is built to run with a number of programs and hardware configurations. It's also built generalist. Let's deal with the second first - you can build a Linux kernel (the "guts" of the operating system, per se) to be low-latency (as opposed to "get the task done when possible"): to get our bits out in order better, effectively less jitter (not quite, I did say "effectively"). A low-latency kernel is second best to a "real-time" build - a kernel that delivers on priority as requested, which is pretty much what we need for audio. Try this guide: http://ubuntuforums.org/showthread.php?t=2273355. I'd install the low-latency kernel too (that's a package in Ubuntu, you don't need to follow a guide and compile it) simply to let you go between the three options at boot and hear the difference... which should be significant (you can't do this much in Windows or OS X). There's reputedly a build of Linux called "Audiophile Linux" that gets you around this far, though you'll not have built a machine that's as flexible (e.g. if you plan on using it for video too, not ideal).

You can tweak around with PAM privileges at this point (essentially the real-time priority your computer gives certain tasks - putting audio replication first is essential).

If you've followed that particular guide and still have the necessary files you can now go further still, and remove a ton of stuff in the OS that your computer doesn't actually use. Drawbacks? If you change hardware you'll need to rebuild this much - fine if you're happy with your hardware.

So what to do:

  • Unplug anything you don't need (you do not need that flash drive/joystick/bluetooth dongle/etc to play audio etc)
  • Before the "make menuconfig" portion of the linked guide, run "make localmodconfig" as a command. There will be a few questions to answer, however it'll configure a kernel relative to the hardware installed on your system only. A (frankly) incredible amount of stuff will be left out. If you want super boot speed you can use "make localyesconfig" (essentially stuff that you might use is loaded rather than being loaded on-demand - when you're well stripped back, the latter works well).

Continue as per normal. When you next reboot your audio will sound considerably more detailed and your CPU usage should have dropped accordingly. It's entirely possible to play in great detail at this stage: "make localmodconfig" prior to "make menuconfig" will give a good baseline, though in the latter command you'll be able to nix a lot more stuff for networking, security (particularly if your computer isn't in a network or downstream of a firewall). It's an iterative process, every now and then you'll remove something the PC really needed to boot correctly, so long as you're always saving your last best configuration, you're fine.

You will end up with an operating system tailored to playing music best with the hardware you have. My PC doesn't know it has a wireless card, a built-in audio system or anything else. It knows it connects to a TV over HDMI with no audio support, and that the only audio path is over USB to the KillerDAC. Plug anything new into it and it'll shrug it's shoulders and be (broadly) digitally inert to it.

I'm still playing with it though the gains have been considerable.

Stuff I've left out
Work thus far gets bits and what not well-aligned to their digital output, namely USB in my instance, but says nothing for the cable itself - I'm working on that much. There's a difference between the 50c and $4 cables I have, though there's obviously much to go.

I'm keen to hear what the power supply upgrade does.

I've no idea what seismic isolation does to a PC. A later project will be trying to build as much to see, if anything.

Digital room correction is entirely possible. Look up DRC, DRC Designer and BruteFIR. I'm still a little behind here but have a few wicked room modes to tame. Linux has been a bit prickly to get a USB microphone interface working in; mine runs into a laptop accordingly. Having done a good bit of work to minimise CPU load, I'd be keen to limit a convolution engine to a dedicated CPU core or similar. There are nice little DSP boxes that will do this externally, though I'm yet to find (for lack of investigation) something that does I2S in/out and processes at 44.1kHz.

As for the rest of what possible, I'd welcome other's experiences, thoughts and suggestions.
« Last Edit: June 02, 2015, 07:10:07 PM by RMP »

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #2 on: June 07, 2015, 12:48:55 PM »
A few friends have read this and have asked "why not a Mac Mini".

For:

  • There's no wacky power cable routing to reroute, shield and play around with - what's there, given the hardware involved, is actually integrated pretty well.
  • Rather small and well-integrated.
  • You can actually remove the WiFi card.
  • It's possible to run other operating systems should OS X not be your flavour (for sound it isn't).
  • Plug and play, works out of the box.
  • Will take a Linear PSU.

Against:

  • It's not fanless.
  • There's stuff on the motherboard you can't remove that draws a bit of current and will play mild havoc with your ideal bit-perfect-ness (hello Thunderbolt port/chip/hardware)
  • Unless you run Linux and are a developer (or have access to one), taking the unnecessary bits out of the OS is painful. Really painful. It's been done but it's not straightforwards, and there's accordingly very little support for solutions of this nature - do it an you're on your own, or tied to a vendor that's done it for you.
  • Changing the OS probably breaks your End User License Agreement anyway, and buying a solution from someone with that much done may similarly do so.
  • There are lower power solutions out there. You don't need an Intel i5 for audio. You don't need an Intel i5 for audio and 1080P video simultaneously either.
  • No dual-link Ethernet. Can get important when you're streaming uncompressed PCM.
  • The one you'll want is A$979. You can build a completely fanless PC for less, even with a nicer DC-DC stage, that will also take a linear PSU.

Keen to hear of others' experiences.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #3 on: June 10, 2015, 06:50:26 PM »
(Sorry all to use this as a bit of a blog... though this is proving an incredible journey.)

Improvements continue with digital room correction.

I've been playing lately with Denis Sbragion's DRC to generate correction filters, and with BruteFIR to execute a convolution between PCM recordings and the generated filters. (The former is a bit prickly to compile on a Macbook - what's being used to run the correction programs, microphone acquisiton, etc - but works well once there).

To illustrate the problem a little better, rather than use REW to run sweeps I generated them manually, unusually long, recorded against them in Audacity (using a calibrated EMM-6) and then played them back (sweep + 1 channel response each in downmix) with headphones for reference. This gives a quick and easy way of appreciating the what's going on at the listening position. Whilst I've no issue reading amplitude and phase response plots (and whilst many of you might say 'duh'), this gave me a pretty salient appreciation of why some frequency content was a bit 'on the ear' (this and REW's sweeps are a bit quick at the top end).

ButeFIR makes life pretty easy - for the moment I'm not running it as a daemon on the audio engine (e.g. continuously), I'm simply taking a file of audio of interest, creating a convolved version for room response and playing it A/B. I think it could be run realtime on a decent computer with very little CPU penalty and latency - convolving an entire 5-minute track is less than 3 seconds. BruteFIR is written partly in assembler so if you're using an x86 processor, it's really fast. I prefer this over a DCX2496 or MiniDSP simply because there's no point colouring the KDAC's excellent work, BruteFIR lets me do it all digital. I guess people worried about convolver load on a CPU could build a separate computer running Linux and a convolver over asynchronous USB, though given the power of modern CPUs I don't think it's necessary (or worth the potential signal degradation/complication/cost/maintenance another source component may add). For perspective, there are people running BruteFIR on Squeezeboxes successfully; a Squeezebox isn't exactly a supercomputer.

The differences are, frankly, startling. Imaging is just amazing. I'm going to try and get it working realtime over the weekend though there's a bit to sort through in terms of having it use one CPU whilst playback uses another. Expectedly it does a better job in correcting room modes than in providing any acoustic termination/control for high frequency stuff, so it doesn't completely replace room treatment, though it's well beyond an excellent compliment. I don't know that I'd start another build without this capability.

There is a bit of work yet to do in setting target amplitude response curves. It'd be remiss to suggest that the KDAC (or anything else) has perfectly flat response or that it's engineered so (or that every audio engineer executed every production perfectly enough for reproduction to add nothing to a listening experience). Accordingly  the current target curve I've generated filters for (0 to -4dB flat slope from 150Hz to 20kHz, with some sub protection at the subsonic end) could probably use a little work to eek out a little more life. But the net effect so far really is amazing.

The nice part about being able to do it offline is that for a given sweep and recorded L/R responses, it's possible to have someone prepare filters, run the filters on some music for you, burn it to CD and effectively try some music corrected for your listening environment's characteristics. A nice way to try it, if you can agree on filter targets and test conditions.

I'm liking this DSP thing so much that I may try to take Craig's advice and incorporate a MiniDSP on my subwoofers - I'm hoping that the MiniDSP mixing at 48kHz and inserting an ADC/DAC component around the KDAC output shouldn't be an impediment for the frequencies concerned (I could, alternately, take it out digital from the PC). Ideally this might let me get a little wacky with filters and set phase alignment and amplitude characteristics just so.

On another note (heresy forthcoming) I took a gamble and replaced the I2S cable between Craig's Amanero-based box and the KDAC with a 0.25m CAT6 lead (hey, the termination are the same). The lead is solid-core, shielded pair and half the length of what replaced it. It sounds a little sweeter, though a good bit of that may be that it replaces unshielded cable directly below an electrically-noisy TV.
« Last Edit: June 10, 2015, 06:52:33 PM by RMP »

Offline rab

  • Administrator
  • Full Member
  • *****
  • Posts: 232
  • Liked: 36
Re: PC source with DRC capabilities
« Reply #4 on: June 10, 2015, 09:04:44 PM »
Hi RMP, i've been wanting to do exactly as you are doing (pre-processing my music files for DRC) for a long time, but i still have bigger fish to fry (like getting speakers built). I'm glad to hear you are doing it!

Please keep us informed of your progress.

- r.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #5 on: June 10, 2015, 11:48:56 PM »
Hi RMP, i've been wanting to do exactly as you are doing (pre-processing my music files for DRC) for a long time, but i still have bigger fish to fry (like getting speakers built). I'm glad to hear you are doing it!

Please keep us informed of your progress.

- r.

No problem and thanks. If you're able to record some sweeps in your current system (I could supply the sweep, you supply the responses and mic calibration) and supply some source material and post it somewhere online, I could probably post you back a corrected version for your room response. Let's assume we stick to freely available Redbook samples :)

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #6 on: June 11, 2015, 03:47:08 PM »
Been reading this thread actively.. Thanks for your insights so far OP..

May I ask which version of RT kernel are you using?

Also, can you build and install cyclictest, and run the following.

cyclictest -t2 -p 99 -n -i 10000 -l 10000

And show me the results? (If you are only using a single CPU just use -t1 instead of -t2)

Offline ozmillsy

  • Hero Member
  • *****
  • Posts: 2249
  • Liked: 277
Re: PC source with DRC capabilities
« Reply #7 on: June 11, 2015, 06:16:38 PM »
Nice work RMP,  DRC is definitely a big gain to be had.  Am following with interest.   Would be worth starting a thread on this in another part of the forum, so people who are interested in the topic see it (ie: not every reader follows all threads).

I have been experimenting with Dirac room eq on my XMC-1 HT processor, and have been very impressed by the results.
It's all about the music,, not the equipment.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #8 on: June 11, 2015, 08:19:25 PM »
Been reading this thread actively.. Thanks for your insights so far OP..

May I ask which version of RT kernel are you using?

Also, can you build and install cyclictest, and run the following.

cyclictest -t2 -p 99 -n -i 10000 -l 10000

And show me the results? (If you are only using a single CPU just use -t1 instead of -t2)

Sure, no problem, though bear in mind this is an area of active development on my box - there's a long way to go and hopefully we can share experiences.

I'll give you results for three installed kernels (currently processing in four CPU threads, reported accordingly):

3.13.0-52-generic:

policy: fifo: loadavg: 0.28 0.14 0.06 2/219 2169         

T: 0 ( 2161) P:99 I:10000 C:  10000 Min:      3 Act:   16 Avg:   12 Max:      42
T: 1 ( 2162) P:99 I:10500 C:   9524 Min:      2 Act:   13 Avg:   11 Max:      70
T: 2 ( 2163) P:99 I:11000 C:   9091 Min:      3 Act:   15 Avg:   15 Max:      55
T: 3 ( 2164) P:99 I:11500 C:   8696 Min:      2 Act:    9 Avg:   12 Max:     589

3.13.0-52-lowlatency

policy: fifo: loadavg: 0.87 0.45 0.18 1/228 2077           

T: 0 ( 2066) P:99 I:10000 C:  10000 Min:      2 Act:    7 Avg:   11 Max:      47
T: 1 ( 2067) P:99 I:10500 C:   9523 Min:      2 Act:   18 Avg:   11 Max:     198
T: 2 ( 2068) P:99 I:11000 C:   9091 Min:      2 Act:   10 Avg:   11 Max:      40
T: 3 ( 2069) P:99 I:11500 C:   8695 Min:      2 Act:   17 Avg:   10 Max:      42

3.18.13-rt9  (for no reason other than this was the current patch when I started)

policy: fifo: loadavg: 0.00 0.01 0.05 1/236 5153         

T: 0 ( 5148) P:99 I:10000 C:  10000 Min:      3 Act:    6 Avg:    5 Max:      13
T: 1 ( 5149) P:99 I:10500 C:   9524 Min:      3 Act:    4 Avg:    5 Max:      57
T: 2 ( 5150) P:99 I:11000 C:   9091 Min:      3 Act:    6 Avg:    5 Max:      18
T: 3 ( 5151) P:99 I:11500 C:   8695 Min:      3 Act:    4 Avg:    5 Max:      18

All tests run 2 minutes after a stable boot. I'll stress that there's a lot ripped out of the last kernel, though I'm not sure that much'd have been different. The security model, for instance, is very much simplified. I'm trying for <5ms... looking around it seems achievable.

Whilst system latencies aren't everything there's much attributable. I'm currently tuning (it's not going to be a short project) and getting rid of much in the way of running processes. It did start life as Ubuntu after all (I like the package manager, though in all honest it's moved quite far away from something that needs it). There's a lot else to run, I don't think much of what's done here is memory bandwidth intensive though it could be worth a look killing off hyper threading and seeing what's what.

I haven't actually gotten around to installing JACK and doing some testing as to it's necessity... down the road.

(CD players are much easier ;D).
« Last Edit: June 11, 2015, 08:26:42 PM by RMP »

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #9 on: June 11, 2015, 08:25:04 PM »
Nice work RMP,  DRC is definitely a big gain to be had.  Am following with interest.   Would be worth starting a thread on this in another part of the forum, so people who are interested in the topic see it (ie: not every reader follows all threads).

I have been experimenting with Dirac room eq on my XMC-1 HT processor, and have been very impressed by the results.

Nice bit of kit, the XMC-1, not wife-proof in my home, I have to run this all off a PC as subterfuge :)

Let me know where to post it (new to these forums) and I'll move it there.

Offline rab

  • Administrator
  • Full Member
  • *****
  • Posts: 232
  • Liked: 36
Re: PC source with DRC capabilities
« Reply #10 on: June 11, 2015, 09:37:40 PM »
If you're able to record some sweeps in your current system...

Well, i would, but i don't have a functioning system ATM: i'm still waiting to receive some drivers from Europe (due in just over 5 weeks  :(), and i'm having custom cabinets built for them... maybe in August/September...

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #11 on: June 11, 2015, 11:03:24 PM »
Count 'em down, Rab :)

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #12 on: June 11, 2015, 11:44:37 PM »
Sure, no problem, though bear in mind this is an area of active development on my box - there's a long way to go and hopefully we can share experiences.
Thanks.. Looks like you're either doing it from the console or X11 (locally)?

If so, can you ssh remotely into your media player from another machine, and run the tests again? The max latency looks like it's writing to the screen.. If you run this test over the network, that latency will not be there in theory... (because the constant updates is writing to a buffer instead).

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #13 on: June 12, 2015, 01:01:15 AM »
Those results were ssh'd in though bear in mind that this box doesn't just do audio (yet) and yes, there's a lightweight video engine running. It's not headless. Some thought's been given to running it so, though right now peace in this home is maintained by having a PC that serves audio, movies, Netflix, etc). Peace is only transferred when new solutions unequivocally work :D

If you like I could run these again at a lower run level whilst ssh'ing in (sans video) ough this'll have to wait a day (PC and partner are both in movie mode presently). My work so far has been about minimising the background load and dropping latencies in a net sense usefully.

I'd planned to spend some of the weekend seeing if realtime priorities in mpd and other relevant audio bits make a difference (should), and to see if there's an audible difference between maintaining these priorities despite a lightweight video output (interesting thought). Much cleaning to do in the OS too (still a silly number of processes).

Ideas?

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #14 on: June 12, 2015, 10:50:36 AM »
Ah.. So it's doing other stuffs.. Fair enough..

Offline ozmillsy

  • Hero Member
  • *****
  • Posts: 2249
  • Liked: 277
Re: PC source with DRC capabilities
« Reply #15 on: June 12, 2015, 07:41:20 PM »
Let me know where to post it (new to these forums) and I'll move it there.
I reckon the Transports sub-forum is the place for a discussion on PC source with DRC capabilities.  Tuyen can help you move existing posts to a new thread (send him a PM).
It's all about the music,, not the equipment.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #16 on: June 12, 2015, 10:33:55 PM »
Ah.. So it's doing other stuffs.. Fair enough..

Hang on - you've given me an idea. Thought maybe that latencies weren't everything, possibly it was task sequencing and a few other things.

SO. Redoing it with lightdm and kodi killed (e.g. just a blank screen) and ssh'd in (in English: no fancy video) gives some very interesting results:

3.13.0-52-generic (e.g. unmodified Ubuntu 14.04 LTS kernel)

policy: fifo: loadavg: 0.02 0.05 0.03 1/147 1881         

T: 0 ( 1878) P:99 I:10000 C:  10000 Min:      2 Act:    3 Avg:    2 Max:       5
T: 1 ( 1879) P:99 I:10500 C:   9524 Min:      1 Act:    4 Avg:    2 Max:       4
T: 2 ( 1880) P:99 I:11000 C:   9091 Min:      2 Act:    3 Avg:    3 Max:       6
T: 3 ( 1881) P:99 I:11500 C:   8696 Min:      1 Act:    3 Avg:    2 Max:       4

Naturally though when I put any load on this kernel, things became considerably more distorted. I couldn't get the averages up as much as I had them yesterday, even when I had it decoding 1080p feeds, which has me thinking I might need to look at what housekeeping the PC does of it's own accord.

3.13.0-52-lowlatency

policy: fifo: loadavg: 0.01 0.05 0.04 1/157 1888         

T: 0 ( 1885) P:99 I:10000 C:  10000 Min:      3 Act:    5 Avg:    6 Max:      10
T: 1 ( 1886) P:99 I:10500 C:   9524 Min:      2 Act:    3 Avg:    4 Max:      10
T: 2 ( 1887) P:99 I:11000 C:   9091 Min:      2 Act:    3 Avg:    4 Max:       9
T: 3 ( 1888) P:99 I:11500 C:   8696 Min:      2 Act:    5 Avg:    5 Max:       9

3.18.13-rt9... whilst running mpd and playing music (results were negligibly different when not so)

policy: fifo: loadavg: 0.00 0.04 0.04 1/176 1998         

T: 0 ( 1992) P:99 I:10000 C:  10000 Min:      4 Act:    5 Avg:    5 Max:       8
T: 1 ( 1993) P:99 I:10500 C:   9523 Min:      3 Act:    5 Avg:    4 Max:       8
T: 2 ( 1994) P:99 I:11000 C:   9091 Min:      3 Act:    6 Avg:    4 Max:       8
T: 3 ( 1995) P:99 I:11500 C:   8695 Min:      3 Act:    5 Avg:    4 Max:       7

But they do sound different. Possibly further measurements are needed to characterise why. Open to ideas.

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #17 on: June 12, 2015, 11:34:23 PM »
This is my old machine:

# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.01 0.05 0.03 1/87 1116

T: 0 ( 1115) P:99 I:10000 C:  10000 Min:      1 Act:    1 Avg:    1 Max:       6
T: 1 ( 1116) P:99 I:10500 C:   9524 Min:      1 Act:    1 Avg:    1 Max:       7

CPU is : Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz

The more I measure the latency, the less it makes sense and I gave up and only listen.. :D Because really that latency benchmark isn't really testing the latency of audio playback. Having said that, tune your system and get that tight spread.. the smaller the better (esp between min, act and avg)...

Some common stuffs
1. Disable module loading, have everything compiled into the kernel (this save addressing callbacks or whatever it's called)
2. Disable hyper threading
3. Use PS/2 keyboard/mouse

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #18 on: June 13, 2015, 01:26:39 AM »
 :o Those are some phenomenal numbers. Target set!

What's the distro? Kernel? How'd you get it all down to 87 processes?

  • Already done that :)
  • This I'll try next!
  • Really? Because USB's constantly scanned/polled?

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #19 on: June 15, 2015, 11:24:29 AM »
:o Those are some phenomenal numbers. Target set!

What's the distro? Kernel? How'd you get it all down to 87 processes?
I think that's threads, or was it processes? That's only when it's first boot up, the number of process will actually fall to 57 after a while...

e.g. I don't use freqstep (or cpufreq), disable that and I get 1 less process running, and so on.

Distro is Ubuntu 14.04.0x LTS (Forgot the last number, it's the latest). Kernel is 3.0.3-rt12. As for cutting down the processes - basically turn off anything in the kernel I'm not using (services), and any daemons not using..

Really? Because USB's constantly scanned/polled?
If it's constant, then it's not a problem.. Not sure how or why actually.. It's just mentioned in the RT kernel website somewhere, and to me it does seem to work...

The only thing I didn't follow is I'm still using a text console (not X11), it's supposed to be bad but I just find it better for me..

One other thing you may want to try is add "acpi=off" to your kernel command line.... The trouble with that is the machine cannot power off automatically when you press the power power (or power down when you do a shutdown)... It does seem to sound marginally better to me but it's too much of a hassle to disable. :(