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

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #20 on: June 15, 2015, 04:39:58 PM »
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.


Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #21 on: June 16, 2015, 01:13:29 PM »
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...


Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #22 on: June 17, 2015, 12:56:05 AM »
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 :)

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #23 on: June 17, 2015, 10:44:05 AM »
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...

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #24 on: June 17, 2015, 12:50:22 PM »
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.


Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #25 on: June 17, 2015, 02:54:00 PM »
@*$^#!(&*#%@#@!&#^$

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

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #26 on: June 17, 2015, 04:17:48 PM »
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)...


Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #27 on: June 17, 2015, 04:20:58 PM »
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.

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #28 on: June 18, 2015, 11:24:55 AM »
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).

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #29 on: June 19, 2015, 10:51:59 AM »
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?

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #30 on: June 19, 2015, 04:43:04 PM »
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.




Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #31 on: June 20, 2015, 10:50:18 PM »
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.

Offline ozmillsy

  • Hero Member
  • *****
  • Posts: 2163
  • Liked: 245
Re: PC source with DRC capabilities
« Reply #32 on: June 21, 2015, 11:58:03 AM »
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.
It's all about the music,, not the equipment.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #33 on: June 21, 2015, 06:51:47 PM »
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.

Offline ozmillsy

  • Hero Member
  • *****
  • Posts: 2163
  • Liked: 245
Re: PC source with DRC capabilities
« Reply #34 on: June 21, 2015, 09:54:42 PM »
It's the same digital connection - it's just changing the software engine generating the bits that feed it.
Same answer.
Quote
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. 

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

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

Quote
...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?   
It's all about the music,, not the equipment.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #35 on: June 22, 2015, 07:59:09 PM »
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).


Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #36 on: June 22, 2015, 10:13:07 PM »
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.


Offline ozmillsy

  • Hero Member
  • *****
  • Posts: 2163
  • Liked: 245
Re: PC source with DRC capabilities
« Reply #37 on: June 22, 2015, 11:22:57 PM »
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.

Quote
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.
« Last Edit: June 22, 2015, 11:27:51 PM by ozmillsy »
It's all about the music,, not the equipment.

Offline RMP

  • Newbie
  • *
  • Posts: 26
  • Liked: 16
Re: PC source with DRC capabilities
« Reply #38 on: June 24, 2015, 04:06:24 AM »
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 ;)...

Offline treblid

  • Sr. Member
  • ****
  • Posts: 391
  • Liked: 15
Re: PC source with DRC capabilities
« Reply #39 on: June 24, 2015, 10:15:40 AM »
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)...