The KillerDAC Audio forum
General HIFI => Transports => Topic started by: RMP 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.
-
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 (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.
-
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.
-
(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.
-
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.
-
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 :)
-
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)
-
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.
-
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).
-
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.
-
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...
-
Count 'em down, Rab :)
-
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).
-
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?
-
Ah.. So it's doing other stuffs.. Fair enough..
-
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).
-
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.
-
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
-
: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?
-
: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. :(
-
Interesting - we rock the same OS and a not-too-different kernel. Really good to meet you :)
Of interest - what size does your kernel compile down to? Currently at around 5,500kb though I've some Logitech and ACPI support in there still.
I'm thinking I'll leave GRUB in the system and eventually setup two boot options - Music and Multimedia - simply reflecting different missions.
There's a good bit of system processes duplicated in a hyperthreaded system, and I'm going a bit batty trying to disable that - no BIOS option on my system, getting close though. Seems it needs a bit more than a boot option.
-
My kernel is 2465040 bytes. Not sure size matters that much though? As I think the bzImage can be compressed. So while my image may well be smaller, it's because I'm using better compression (and you may have none).
I think I have ACPI code compiled in, although I only enable the "Button", which allows me to power off the machine by pressing the power button. To disable ACPI I do this in the BIOS or in the boot up command line.
Hyperthreading in theory is good, because the CPU will use smarts to switch between two execution paths (IIRC).. But it's the unpredictability that may be an issue. Some tasks are better with HT on and others better with it off.. it all depends, and you can try both and see how it goes...
-
Kernel size simply gives a good indication of how much you took out. Though yeah, that's compressed, mine isn't.
Rapidly iterating towards the button.
HT really depends on the task. I've two serious Linux boxes for work that crunch numbers 24/7; owing to a number of factors they're quicker with HT off.
Still working at it :)
-
Kernel size simply gives a good indication of how much you took out. Though yeah, that's compressed, mine isn't.
One other thing you can do with reducing the size is to disable debugging. I think with the RT branch it's enabled by default. Turn that off and bam!
Give the version 3.0.3-rt12 a go. Will be interested if you can discern a change (regardless if it's placebo or not) with the newer (or even older versions)...
Player I'm using mpd (not the v18 RT branch)... Havn't really look at DRC yet, the problem with MPD is I probably need to utilise JACk if I want to any form of DRC...
-
trebild, you're a legend - I love the internet. I'd be focussing on removing a lot from the kernel but had overlooked debugging.
Since we've been engaged here I've dropped a whole 2Mb uncompressed from the kernel size. Not bad. I boot with two Ethernet interfaces on IPv6 at 5.1 seconds or so (and falling). Yet to sort out the device/IRQ priorities etc, haven't disabled hyperthreading yet, however with respect to latencies...
policy: fifo: loadavg: 0.00 0.01 0.01 1/114 1025
T: 0 ( 1021) P:99 I:10000 C: 10000 Min: 0 Act: 1 Avg: 1 Max: 2
T: 1 ( 1022) P:99 I:10500 C: 9524 Min: 0 Act: 1 Avg: 1 Max: 3
T: 2 ( 1023) P:99 I:11000 C: 9091 Min: 0 Act: 1 Avg: 1 Max: 3
T: 3 ( 1024) P:99 I:11500 C: 8696 Min: 0 Act: 1 Avg: 1 Max: 3
And that's much better :)
It's noticeably snappier at the command line. Got a bit of work to do - I get audio out of Kodi no problem, though aplay at the command line is proving a bit trickier. It does sound better, considerably more detailed.
I've got a calibrated mic here (it's got a decent noise floor though), I'd swear each time the kernel changes markedly I get frequency response changes. One would wonder if they'd be beyond the sensitivity of what I can measure.
DRC? You'd need Jack, I'm not having much fun with ALSA and BruteFIR... however you could just convolve tracks on demand - four minutes of audio takes under five seconds to convolve, and then you just play the convolved track. Works well. Can post my BruteFIR config to this end if you're interested.
-
@*$^#!(&*#%@#@!&#^$
Seems I'd inadvertently disabled SMT in an earlier version of the kernel build, so it went down from 2/2 cores/threads to 1/1. Which screamed for speed everywhere until I ran lightdm and some video, and then it wasn't as much fun. Hmm.
(Back to the drawing board...)
-
That's the trouble with a low latency system. If you have too many things running, it will struggle.. To help alleviate that, you can increase the timer frequency (it's the one that's 100 Hz, 200 hz, 300 Hz, 1000 hz).. RT by default uses 100, try 300 and see how that goes.
Again apparently if you use PS/2 keyboard/mouse, it'd be better compared to a USB. That's what the docs says though as I never confirmed that myself.
Some say using just 1 core is better (lower power consumption), so if one has 2 or quad core, they only keep one running (setting acpi=off will do the same effect)...
-
Screaming fit over. Editing the kernel boot line to have "maxcpus=2" seems to constrain response times nicely. nproc confirms that I'm still running off two physical cores, not hyper threading on one. So far the kernel is built with SMT on (obviously) and the relevant optimisations for SMT, but no support for Hyperthreading optimisations.
This is still with the USB keyboard and mouse plugged in, and no priority optimisation done beyond the kernel RT patch. I'll do as you suggest next and hit up the power settings in detail (I've had a quick cut of them).
policy: fifo: loadavg: 0.00 0.01 0.01 1/135 1046
T: 0 ( 1045) P:99 I:10000 C: 10000 Min: 1 Act: 2 Avg: 1 Max: 4
T: 1 ( 1046) P:99 I:10500 C: 9524 Min: 1 Act: 2 Avg: 1 Max: 4
Boot times are a little longer than the stock kernels and a tad slower than with hyper threading enabled, there's probably a bit more fat in there. 113 processes in top, 112 of which are asleep. More to do in running through init, init.d, etc to clean up.
Probably some more to do in cleaning up cronjobs, etc too. All suggestions welcome.
-
With the USB kb/mouse thing.. Just disconnect it when not in use, and problem solved..
So now with latency down, do you perceive a difference?
That total number of process should die down after a few minutes.. you can run "ps aux" to look at all the programs running. Anything in square brackets [] means it's kernel, and everything not means it's in user space. As for cleaning up cronjobs, just disable it (there's at least 2 - atd and crond)..
Note that the latency measured by cyclictest isn't really the latency in delivering audio packets to the audio device, so while there is a corelation, as aways, it's hard to pin anything down)...Sorta like a measurement mic (mono) isn't actually capturing what you're hearing (stereo).
-
The latency does die down a bit after a few moments running.
It's interesting, the difference, because it's not a 'conventional' analogue abberation. It's essentially the time-alignment of digital packets before they're sent off asynchronously somewhere else to be, well, time-aligned prior to digital-to-analogue conversion. It's a weird take on jitter; not least because the spectral distribution *probably* has a hump at the system clock (1kHz) and a weird-ish distribution beyond it as the next 1/1000th of a second of audio is 'dealt with'. (This line of thought doesn't read nearly as well as it does in my mind).
And yet the sound is markedly different at low latency. There's more detail but also a frequency response change. No DRC employed at this stage, just going A-B wih uncorrected tunes. It does sound more realistic though thinner. Maybe thinner is realistic. I was using a live Boz Scaggs track at some point for comparison because I know the artist's work well and I've been in the particular venue a few times before. At lower latency the audience clapping initally sounded much thinner, but then again, it's not a recording of a bloke in the 10th row, is it, and Boz's vocals sound considerably more detailed.
Not every step (removing something else) has been a forwards step, oddly - though we're growing an aural appreciation as we go, and frankly having a quibble about content well within the worst of room gain's contribution is a bit like trying to find a needle in a haystack... via slingshot whilst riding a horse blindfold :D
I'll get back having done a bit more.
How'd you travel with your experiences?
-
How'd you travel with your experiences?
Nothing. Can't really do much when I get to 1.
I've seen moved away from all this and now on a completely different path - PXE booting, HD-Plex power supply, Juli@ I2S output (pending)...
The latency is now all over the shop.. Good thing is, once everything is properly in place the whole room will look a lot neater and cleaner than it is right now. :D Real time DRC is out of the equation because the CPU simply don't have the horsepower to do it. So anything I have to do, I have to do before playback.
-
You're a brave man :) on the Juli@. Between time and cost, Rawl's Amanero-based solution is quite nice (that and I'm on a motherboard with no PCIe slot).
PXE offers some interesting possibilities, good job, it's beyond my abilities. I've got the HD-Plex power supply too (arrived a few days ago), it's quite a nice item.
I'm nearly done chopping out bits of the kernel. One day I might compile some of the milestone kernels and see if there's any notable frequency response difference to substantiate what I'm hearing, though possibly the entirety of the different isn't reliably there. It'd be interesting to run a scope on the I2S output and check bit differences on the same track.
Really sure realtime DRC is out? BruteFIR is really fast; seems to be quite lightweight.
-
Different digital connections are unlikely to show you any bit differences at all.
The pereived sonic differences can in large part be attributed to jitter induced distortions.
-
Different digital connections are unlikely to show you any bit differences at all.
It's the same digital connection - it's just changing the software engine generating the bits that feed it.
The pereived sonic differences can in large part be attributed to jitter induced distortions.
I'm guessing they'd have to be mostly so; there's going to be a few lost bits here and there in a computer transferring audio data in near-RT on-the-fly, the majority will concern timing.
Possibly the question best asked is 'where's the earliest place we'd see differences", if any. I'm keen for a test without a need for a placebo.
Scoping the async USB might be smart (assuming I could setup a spare PC to read it as an input). I2S is just farther down the chain. Whilst I've a fair idea what I'm hearing I'm (by definition) not an impartial audience! If possible I'd like some data to substantiate what I'm hearing. I recently got into a decent argument with someone who believed that all anomalies in an ideal system could be cured by frequency response correction. Whilst potentially true, 'potentially' is a very liberal statement, not least as computers are quite far from ideal...
...this said the room-gain-corrected stuff sounds miles better, it's terrifically obvious, it's simply about substantiating the rest of the work.
When I'm done I'll post some config files others could use.
-
It's the same digital connection - it's just changing the software engine generating the bits that feed it.
Same answer.
I'm guessing they'd have to be mostly so; there's going to be a few lost bits here and there in a computer transferring audio data in near-RT on-the-fly, the majority will concern timing.
Our (computer) systems are engineered not to lose bits. While it can be possible, it's very unlikely. Happy to see your results.
Whilst I've a fair idea what I'm hearing I'm (by definition) not an impartial audience! If possible I'd like some data to substantiate what I'm hearing.
Very good ! I'm not impartial either. :) There are methods we can use, to validate what we hear. Having a small set of reference tracks is pretty critical. While I wouldnt want to discourage you from trying to validate with measurements, half the challenge is the range of things to be measured isnt insignificant.
At the end of the day, the most important attribute any of us can have, is to learn to trust our ears. I've found that bias does tend to wear off over time.
I recently got into a decent argument with someone who believed that all anomalies in an ideal system could be cured by frequency response correction. Whilst potentially true, 'potentially' is a very liberal statement, not least as computers are quite far from ideal...
I dont think it is true. There's all kinds of distortions that we can hear, that doesnt necessarily translate into FR measures. 2 x systems can both measure flat, but sound very different due to various distortions.
...this said the room-gain-corrected stuff sounds miles better, it's terrifically obvious, it's simply about substantiating the rest of the work.
Room correction certainly can be very obvious , and is worth pursuing further for digital systems.
I might have missed it, but with your room corrected 16 bit files, how do you ensure enough headroom so you dont get clips? Reducing volume too much loses resolution, is this a trade off? DRC gives more benefit, than the lost resolution?
-
Our (computer) systems are engineered not to lose bits. While it can be possible, it's very unlikely.
Not exactly, they're engineered to transfer bits and have all sorts of error correction employed in many, but not all applications to ensure that schedulable actions (e.g. a file copy) can be verified correct. Some applications have parity checking in hardware. Streaming realtime audio isn't an application with either hardware or software checks to speak of. Granted, the number of lost (mostly flipped) bits are small, but we're talking of an application that's a bit 'Nth degree'. It's a decently noisy environment too - the audible difference in removing radios from my chassis was, frankly, night and day.
Very good ! I'm not impartial either. :) There are methods we can use, to validate what we hear. Having a small set of reference tracks is pretty critical. While I wouldnt want to discourage you from trying to validate with measurements, half the challenge is the range of things to be measured isnt insignificant.
At the end of the day, the most important attribute any of us can have, is to learn to trust our ears. I've found that bias does tend to wear off over time.
I'm relatively sure that any acoustic method I have of measuring this will be pointless, I'll be chasing differences within my devices' noise floors. Not ideal.
I've got a few tracks and the like, I'm acutely aware of my will to want to find truths where they may not exist. Lots of blind testing with friends and partner. You're right, one becomes more discerning, I'm actually happy when I think something's worse and others confirm it impartially (something of a head check).
I dont think it is true. There's all kinds of distortions that we can hear, that doesnt necessarily translate into FR measures. 2 x systems can both measure flat, but sound very different due to various distortions.
I agree with you, though the guy in question was emphatic in his beliefs! I'm with you, not everything that's an audible limitation can be captured as aberration in frequency response.
Room correction certainly can be very obvious , and is worth pursuing further for digital systems.
I'd not build a system without it in future. Currently challenged with getting it working realtime with manageable, predictable, low system latencies.
I might have missed it, but with your room corrected 16 bit files, how do you ensure enough headroom so you dont get clips? Reducing volume too much loses resolution, is this a trade off? DRC gives more benefit, than the lost resolution?
From a psychoacoustic perspective, time alignment of various components of a multi-channel signal (e.g. stereo) is far more important than small differences in relative energy level, not least as sufficient differences in time alignment can give a perceived loss of frequency response. In tuning mine this became an interesting and salient variable; not unlike when subs and speakers reach phase at key frequencies. Some of us, and I guess I fall into this camp, aren't blessed with system locations that are as acoustically favourable as those of others.
I understand what you mean by clipping, insofar as the inverse of the amplitude response needs to be applied to capture the intended energy content per a given frequency; if the amplitude response is way off, the correction is likely to be extreme. So far nothing obviously audible; typical corrections are sub-hundreds-of-Hz and the most obvious corrections are against excessive gain - so the effect tends to be quite pleasant. The convolution engine I use is set to clip in worst-case scenarios. Presently I've not managed to adversely clip anything to the best of my knowledge (we'd be talking -ve amplitude response for a signal already near max amplitude). I'm able to have it throw an error if I feed it an incorrect file format and it reads zero response at a given frequency (thus an infinite correction), and frankly the filter I'm employing isn't extreme (one could be stricter with it and probably run into the issues you're suggesting with aplomb).
-
Good news on the RT kernel front...
RT branch for version 4 is live: https://www.kernel.org/pub/linux/kernel/projects/rt/4.0/
It's actually available since last month, but I was too tied up recently to notice.. Anyway better late than never.
-
I understand what you mean by clipping, insofar as the inverse of the amplitude response needs to be applied to capture the intended energy content per a given frequency; if the amplitude response is way off, the correction is likely to be extreme. So far nothing obviously audible; typical corrections are sub-hundreds-of-Hz and the most obvious corrections are against excessive gain - so the effect tends to be quite pleasant.
Bass suckouts and nulls are common place in most rooms, requiring boost to fix. You'd have an extremely kind room, if you didnt need to fix any big dips in the bass region.
Since most 16bit files are mastered with little to no headroom, room correction (needing boost) generally causes clipping. Intelligent DRC systems overcome this, by upsampling into larger range address space, and leaving themselves significant headroom to make adjustments. Convolving in 16 bit address space, doesnt have this luxury.
Presently I've ot managed to adversely clip anything to the best of my knowledge (we'd be talking -ve amplitude response for a signal already near max amplitude).
Pretty simple task to check your convolved files. Any number of tools will do it.
-
Bass suckouts and nulls are common place in most rooms, requiring boost to fix. You'd have an extremely kind room, if you didnt need to fix any big dips in the bass region.
Since most 16bit files are mastered with little to no headroom, room correction (needing boost) generally causes clipping. Intelligent DRC systems overcome this, by upsampling into larger range address space, and leaving themselves significant headroom to make adjustments. Convolving in 16 bit address space, doesnt have this luxury.
Pretty simple task to check your convolved files. Any number of tools will do it.
Of course there are antinodes, note I said "typical corrections" ;)
It's entirely possible to linearise amplitude responses below unity. It's possible to run a -ve gain adjustment prior to filtering to provide some effective headroom pre-linearisation, it's possible to pass data in higher bit depths. BruteFIR is nicely flexible; it allows pre gain adjustment (I run not a lot as I've a bit of work on signal levels), it'll pass through - and process in 32-bit depth (another 16 bits aren't necessary, but it's easier on the CPU). It'll even dither outputs if asked. Building a sophisticated system as you suggest is entirely feasible... it's bloody good free software! I'm some ways down this road; there's a bit to tune. It's helpful that the Amanero takes a 32-bit input.
Kinda mindful that there are practical limits to amplitude response correction, I used to run convolution in scientific applications and we'd deduced (through extensive testing) that in one particular application we'd use an effective 'amplitude response floor' of 0.4 - anything below it wouldn't be linearised (e.g the spectral content would be discarded, and the linearised signal wouldn't feature content for the frequencies affected). Obviously this isn't possible for audio signals (the missing content would affect the linearised signal, well... audibly) but similarly it's not feasible to linearise content with excessively low filter amplitude response, or usual issues with gain etc rear their head. So we end up with broadly flat (or whatever the target is) response in the linearised signal with some dips where the system response was excessively low.
Accordingly one can generate a filter to varying degrees of strictness; the DRC webpage has a nice number of examples to this end.
From a psychoacoustic perspective we probably put too little importance on phase response correction in multichannel signals - it's something that can't be experienced in an EQ (either in spectral resolution or accuracy). It's audibly awesome.
Good news on the RT kernel front...
RT branch for version 4 is live: https://www.kernel.org/pub/linux/kernel/projects/rt/4.0/
It's actually available since last month, but I was too tied up recently to notice.. Anyway better late than never.
Bloody hell! I was just getting used to what I had ;)...
-
Bloody hell! I was just getting used to what I had ;)...
You and me both.. :D Not much difference in 4 really (it's really just a rename of 3.20) but hey it's a biger number.
My new mini-ITX based machine has an average latency of 50 ms (or was it us) now :o... Will be interesting to subjectively compare this against my old machine sometime down the road and see if that number has any bearing at all (after all, cyclictest isn't actually testing the latency of audio packets/frames delivery)...
-
Of course there are antinodes, note I said "typical corrections" ;)
Absolutely, and we agree that requiring boost is 'typical' for most rooms.
It's entirely possible to linearise amplitude responses below unity.
Goes without saying, and the question is how far down are we taking it? Acknowledging that if we start with a 16 bit file, and if we end with a 16 bit file, then it doesnt matter what the tools are doing in between - there will be a loss of resolution, and/or dynamic range (if we employ limiters to prevent clips).
It's possible to run a -ve gain adjustment prior to filtering to provide some effective headroom pre-linearisation,
Not just possible, its mandatory if you want to avoid clips, if acknowledging that boost is typically required.
it's possible to pass data in higher bit depths. BruteFIR is nicely flexible; it all-ows pre gain adjustment (I run not a lot as I've a bit of work on signal levels), it'll pass through - and process in 32-bit depth (another 16 bits aren't necessary, but it's easier on the CPU).
What matters is what bit depth you start and end with. Upsampling into larger address range is all well and good, if you are going to leave it in large address range and play it back at the higher sampling rate.
If we are going to dither back down to 16bit, then upsampling doesnt help us avoid resolution loss.
16bit doesnt actually give us alot of room to move. Give ourselves 6db of headroom, and we're down to 15 bits max range, low level info in the data starts to disappear into the noise floor.
It's helpful that the Amanero takes a 32-bit input.
Yeah, but our dacs are 16bit.
Kinda mindful that there are practical limits to amplitude response correction,
[snip]
So we end up with broadly flat (or whatever the target is) response in the linearised signal with some dips where the system response was excessively low.
I'd hope we're not only mindful, but we are checking whether our resulting files contain clips. How much adjustment are you limiting yourself to? And how close to target curve are you able to get?
From a psychoacoustic perspective we probably put too little importance on phase response correction in multichannel signals - it's something that can't be experienced in an EQ (either in spectral resolution or accuracy). It's audibly awesome.
There's not alot of EQ solutions that do apply phase filters as part of equalisation, Dirac does, and I'm getting good results with it. But,,,,the most comprehensive way to attain coherency, is to do per driver level phase and FR equalisation. The results can be very very good.
I tend to think that DRC pretty much mandates high resolution dacs. Then again,,,,, the pros could well outweigh the cons.
-
I don't think we're disagreeing anywhere!
Maintaining resolution in bit depth means expanding the address space, doing some math, being intelligent about what's packed back into the address space available into the DAC. The Amanero requires a 32-bit input, however yes, the last 16 are truncated into the TDA.
And I do get what you're suggesting about 16 bits being limiting when against large amplitude response. though the tradeoff 16 to 15 or even 14 bits can be practically small (music tastes, background noise... I'm not going to doubt that in an ideal listening scenario + a nice glass of red that they don't matter). There's not quantitative measure to compare loss in SNR against linearisation effects... the question really is 'does it sound better'? Depends on the listener, depends on the install. A bit like suggesting that I have 24-bit DACs, though I like the sound of this 16-bit item a good bit more, and even more when it's corrected. Some 24-bit material (I have some 2L stuff) on the right DAC gives a really impressive 'black', and 24 bits is probably overkill enough to sacrifice 1 or 2 bits to linearisation against what my ears can actually hear... though again... I like the compromise I have now much more. As you suggest, pros vs cons.
You can get around the headroom space argument (e.g. clipping) simply by limiting amplitude gain in linearisation. Fixes the peaks, keeps the troughs. The rest is about finding a happy medium... there are no silver bullets. An interesting experiment might be to write a filter that corrects phase response only, and leaves amplitude response alone. I'd suggest it's possible given the right software... though frankly it's been a while since uni and it's possibly a task for someone else and a copy of MATLAB or Octave.
I'd stress again that it's important to know where to go mild on the filter.
DIRAC is a development of DRC; it does some nice things in terms of taking practical measurements for multiple listening locations rather than applying theoretical assumptions, though at the listening position the results should be no different.
Doing is per driver would be awesome - (more talented) people have using the same solution I've employed, and their configuration scripts look pretty bloody awesome compared to mine. Here's an earlier version without any attenuation thrown in - this simply convolves a file 'test.pcm' to one called 'out.pcm' (the final config runs realtime to system devices). Getting a 32-bit PCM file in the right format is pretty straightforward, you'd need to use something like SoX with "-t f32" for format parameters. It's also possible to change conversion formats internally. You can see the way it's laid out, it's pretty easy to expand this beyond two drivers and do a great deal with it... "filter-l.pcm" and "filter-r.pcm" are what's generated with DRC. This is very little modified from the default DRC config file.
(In posting it here I'm hoping someone will throw rocks at it!)
## DEFAULT GENERAL SETTINGS ##
float_bits: 64; # internal floating point precision
sampling_rate: 44100; # sampling rate in Hz of audio interfaces
filter_length: 4096,16; # length of filters
#config_file: "~/.brutefir_config"; # standard location of main config file, it's here (which is default) but doesn't seem to like this NOT being commented out
overflow_warnings: true; # echo warnings to stderr if overflow occurs
show_progress: true; # echo filtering progress to stderr
max_dither_table_size: 0; # maximum size in bytes of precalculated dither
allow_poll_mode: false; # allow use of input poll mode
modules_path: "."; # extra path where to find BruteFIR modules
monitor_rate: false; # monitor sample rate
powersave: false; # pause filtering when input is zero
lock_memory: true; # try to lock memory if realtime prio is set
sdf_length: -1; # subsample filter half length in samples
convolver_config: "~/.brutefir_debug"; # location of convolver config file
## Filter definition ##
coeff "drc_l" {
filename: "filter-l.pcm";
format: "FLOAT_LE"; # file format
attenuation: 0.0; # attenuation in dB
blocks: -1; # how long in blocks
skip: 0; # how many bytes to skip
shared_mem: false; # allocate in shared memory
};
coeff "drc_r" {
filename: "filter-r.pcm";
format: "FLOAT_LE"; # file format
attenuation: 0.0; # attenuation in dB
blocks: -1; # how long in blocks
skip: 0; # how many bytes to skip
shared_mem: false; # allocate in shared memory
};
## INPUT DEFAULTS ##
input "l_in", "r_in" {
device: "file" {path: "test.pcm"; };
sample: "FLOAT_LE";
channels: 2;
};
output "l_out", "r_out" {
device: "file" {path: "out.pcm"; };
sample: "FLOAT_LE";
channels: 2;
delay: 0,0;
dither: false;
};
## FILTER DEFAULTS ##
filter "l_filter" {
from_inputs: "l_in";
to_outputs: "l_out";
process: 0; # process index to run in (-1 means auto)
coeff: "drc_l"; # -1 means "copy"
delay: 0; # predelay, in blocks
crossfade: false; # crossfade when coefficient is changed
};
filter "r_filter" {
from_inputs: "r_in";
to_outputs: "r_out";
process: 0; # process index to run in (-1 means auto)
coeff: "drc_r";
delay: 0; # predelay, in blocks
crossfade: false; # crossfade when coefficient is changed
};
-
I don't think we're disagreeing anywhere!
Not sure what there is to disagree about. You've said yourself, we make choices based on compromise. I am still interested to see the specifics of what you're actually doing.
And I do get what you're suggesting about 16 bits being limiting when against large amplitude response. though the tradeoff 16 to 15 or even 14 bits can be practically small (music tastes, background noise... I'm not going to doubt that in an ideal listening scenario + a nice glass of red that they don't matter).
Ever used a digital volume control that bit stripped, and compared it to an analog volume control? The degradation in sound due to loss of resolution with the DVC is shocking, and these losses shouldnt be understated. I dont believe we are on the same page WRT the practical losses associated with 16bit vs 14bit. We could argue the analog VC is influencing our perceptions (making it sound nice), but the interesting thing is what happens to the sound when you knock off volume on the DVC, it becomes coarse.
There's not quantitative measure to compare loss in SNR against linearisation effects... the question really is 'does it sound better'? Depends on the listener, depends on the install.
Depends how you compare, we can easily fool ourselves with a flawed approach to validating the changes in sound/perceptions.
A bit like suggesting that I have 24-bit DACs, though I like the sound of this 16-bit item a good bit more, and even more when it's corrected. Some 24-bit material (I have some 2L stuff) on the right DAC gives a really impressive 'black', and 24 bits is probably overkill enough to sacrifice 1 or 2 bits to linearisation against what my ears can actually hear... though again... I like the compromise I have now much more. As you suggest, pros vs cons.
Yes, but, let me throw a wild thought out there. Perhaps digital equalization is a lazy mans tool, to fix the flaws in a system and room ??
It's a question, not statement. I dont mean to ask it in an inflamatory way.
Some will tell you, that it's impossible to fix room issues without EQ. I'm not convinced about that at all, it's just easier to EQ.
Are we still agreeing? 8)
Perhaps the pros of setting up a system in the traditional way (the hard way), using manual methods to tame room/system issues, far and away outweigh the cons of relying on digital equalization? I ask this question, having experimented with both (and acknowledging that digital EQ in the 16bit space does have compromises).
1 of the fantastic things about the Killerdac, is it allows me to easily make any number of changes (to the dac) to tailor the sound. I've run my Kdac in 4 different homes/rooms now, each time I have moved, I have had to retune my 2ch hifi system around the new room. Retune can mean any number of changes, but can and has included tweaking the source (the dac).
It's not just a great sounding dac, it's a flexible one, that can be bent to suit what your system/room needs. This is the real beauty and strength of it. Now we could say, yeah but we could do the same to other dacs. Not really, they are not typically built in a way where the user expects to make changes. It's bloody difficult to work on most dacs.
You can get around the headroom space argument (e.g. clipping) simply by limiting amplitude gain in linearisation. Fixes the peaks, keeps the troughs.
Is that what you are doing? Not all that interested to discuss what is possible, I'm more interested to discuss your process, and what equalisation modifications you are actually trying. It's still unclear. Your config file doesnt tell me.
Lets say you are limiting. This doesnt mean everything is fixed. Limiting just helps avoid digital clipping. e.g. If your room requires a 6db boost at 200hz, and the limiting prevents your equalization tool giving you 6db boost at 200hz, because the material has loud music in that range, then you are still faced with a room issue (i.e. the practicality is, you still have a dip in the room response at 200hz).
A potentially better approach, is to figure out why there is a 200hz room response dip in the first place? Repositioning speakers, or applying room treatments to minimise reflections, are techniques to tame room nodes.
An interesting experiment might be to write a filter that corrects phase response only, and leaves amplitude response alone.
Why? A phase filter will fix anomalies introduced by amplitude changes, when changing the amplitude of some frequencies, but not others.
i.e. an amplitude change only at 100hz, will impact the phase accuracy of the frequencies around 100hz that havent had (the same) amplitude change.
Make no amplitude changes, the phase filter has nothing to do.
Tools are good, provided we have a good understanding of why we are using them.
-
Ever used a digital volume control that bit stripped, and compared it to an analog volume control? The degradation in sound due to loss of resolution with the DVC is shocking, and these losses shouldnt be understated. I dont believe we are on the same page WRT the practical losses associated with 16bit vs 14bit. We could argue the analog VC is influencing our perceptions (making it sound nice), but the interesting thing is what happens to the sound when you knock off volume on the DVC, it becomes coarse.
Yep. Have used both. No doubt a good analogue control is better. Don't have the luxury given the way the system is used, unfortunately. I'm left, at present, with a digital control - though I wouldn't call what it does pure bit-stripping. If purely bit-stripping then yes, things will get coarse very quickly.
Yes, but, let me throw a wild thought out there. Perhaps digital equalization is a lazy mans tool, to fix the flaws in a system and room ??
It's a question, not statement. I dont mean to ask it in an inflamatory way.
Some will tell you, that it's impossible to fix room issues without EQ. I'm not convinced about that at all, it's just easier to EQ.
Are we still agreeing? 8)
That's fact and not a wild thought - though for most of us not building anechoic chambers to listen in, it's reality. We're due for renovation here soon however I am still one member in a home that suits more than one, and I often don't get the deciding vote! From a pure physics perspective I'd contend that it'd be very difficult to fully correct the entire frequency range digitally, and it's very difficult to get flat response low-down through room engineering (in most homes)... though this really depends on your target. Is 'flat' what's sought?
I'll admit to my target response starting out kinda flat and having had some tweaking since. Tastes differ here. Usual accuracy vs musicality debates etc.
Perhaps the pros of setting up a system in the traditional way (the hard way), using manual methods to tame room/system issues, far and away outweigh the cons of relying on digital equalization? I ask this question, having experimented with both (and acknowledging that digital EQ in the 16bit space does have compromises).
I take a different look at it - one complements the other, and though you certainly could use digital methods to alleviate the need to do any work traditionally, you'd be lucky if your corrections (in amplitude response particularly) weren't obtuse enough to blow your headroom. I started with digital methods here after spending a few weeks on placement, orientation and room condition. There's of course more that can be done, though we're a reno away from some of it.
1 of the fantastic things about the Killerdac, is it allows me to easily make any number of changes (to the dac) to tailor the sound. I've run my Kdac in 4 different homes/rooms now, each time I have moved, I have had to retune my 2ch hifi system around the new room. Retune can mean any number of changes, but can and has included tweaking the source (the dac).
It's not just a great sounding dac, it's a flexible one, that can be bent to suit what your system/room needs. This is the real beauty and strength of it. Now we could say, yeah but we could do the same to other dacs. Not really, they are not typically built in a way where the user expects to make changes. It's bloody difficult to work on most dacs.
Agreed; component changes will affect frequency response (and other factors). For now though I'm not intending to work on mine (I have other problems to solve, other areas where there are more immediate gains).
Is that what you are doing? Not all that interested to discuss what is possible, I'm more interested to discuss your process, and what equalisation modifications you are actually trying. It's still unclear. Your config file doesnt tell me.
In part yes, though I'm linearly dropping some amplitude first - gives a little more room for correction.
I'd stress that this is the config file for the convolving engine, not the filter generation.
Lets say you are limiting. This doesnt mean everything is fixed. Limiting just helps avoid digital clipping. e.g. If your room requires a 6db boost at 200hz, and the limiting prevents your equalization tool giving you 6db boost at 200hz, because the material has loud music in that range, then you are still faced with a room issue (i.e. the practicality is, you still have a dip in the room response at 200hz).
A potentially better approach, is to figure out why there is a 200hz room response dip in the first place? Repositioning speakers, or applying room treatments to minimise reflections, are techniques to tame room nodes.
Agreed, though two things here: (1) as mentioned this is why there's an amplitude reduction upstream and (2) it's not solely about amplitude response - the aforementioned dip comes with a phase component, two in fact, and there's a significant advantage in their alignment alone. Something a traditional EQ can't often do.
I'm aware of my room modes - right now there's little I can do. Some physical restrictions, some technical restrictions, mostly wife restrictions. It'll come. It won't be perfect when done, and that's what the digital system corrects. I don't believe you can do it all digitally, or that you should.
Why? A phase filter will fix anomalies introduced by amplitude changes, when changing the amplitude of some frequencies, but not others.
i.e. an amplitude change only at 100hz, will impact the phase accuracy of the frequencies around 100hz that havent had (the same) amplitude change.
Make no amplitude changes, the phase filter has nothing to do.
It's possible to create a digital filter for phase only, or with a phase correction only at one frequency. It'll look like a series of complex numbers where the real components are all unity (1) and the imaginaries are whatever the correction is designed to be. In a discrete Fourier transform sense, these are convolved independently as a vector component.
I'd simply be interested to hear the digital phase correction independent of the amplitude correction, because, as you point out, in an psychoacoustic sense the two are not easily separated.
Tools are good, provided we have a good understanding of why we are using them.
Indeed so.