Extreme filtering software upscaling

[Ittaku]

30 minutes ago, Nada said:

Ringing affects signal in the audible spectrum. Just because ringing is modulated at high frequencies doesn't mean its inaudible. 

How? The ringing happens in the ultrasonic range. You're saying the ringing has effects on the audible spectrum? I said I've experimented with artificial ringing and found its effects inaudible unless the magnitude is so great that it's affecting tweeter displacement. What am I missing? I also said there are effects in the audible range as well, separate from the ringing. Are you saying the ringing in the ultrasonic range is what causes the differences in the audible range? That's not my understanding, but feel free to correct me. Class D amps need an analogue filter after the switching (it's my understanding), and I don't believe you can equate the two.

 

I'm no DSP expert so feel free to correct me by all means, though I don't expect to be spoonfed...

Edited February 3, 2019 by Ittaku

[krebetman]

On 30/01/2019 at 2:49 PM, Ittaku said:

sox -V4 input.flac -b 24 output.flac vol -2dB rate -b 99.9999 -d 32 -c 2147483647 88200

You'll have to hack sox to accept a higher bw_3dB_pc (max is normally 99.7) and there were a couple of overflows in some stack arrays that need to be expanded to cope. I hacked a few of these defaults into it to save me manually entering 32 bits and 2^31 and so on, but I've given you all the required command line options for the 30m taps.

 

Debug output:

/usr/bin/sox DBUG effects_i_dsp: make_lpf(n=30150865 Fc=0.4999996 β=21.1104 ρ=0.5 dc-norm=0 scale=1)
/usr/bin/sox DBUG rate: fir_len=30150865 dft_length=67108864 Fp=0.9999982171310080 Fs=1.000000 Fn=2.000000 att=198.68 2/1

 

Use -b 99.99996 for 78 million taps. After that you get overflows galore and it needs a major overhaul.

 

EDIT: Left out the -2dB adjustment above

Interesting.  Would you be up to sharing which arrays needed resizing, or your diffs?

[Guest rmpfyf]

2 hours ago, Ittaku said:

Gotcha. Alas I'm not a finalising kind of person. My software projects are full of half baked products that work and that's about it without any polish. I even know how I would create something that could be a standalone device without too much latency to rival the mscaler at maybe 1/3-1/2 the cost, but I'm not business nor manufacturing minded. In its current form, the 430 second latency probably might not cut it for a real time device (lol.)

 

The latency is workable, you needn't filter an entire file at once, and many of us will put up with some latency. We give up a surprising amount of quality for instantaneous convenience. 

 

The M Scaler is a the usual marketing hype from Chord - it's the latest in a class of products that has existed for eons. Each generation is better than the last by simple virtue of more computational power being available affording a more complex filter. There's not more than $1k of bits in that box (if that) and Chord is probably getting the Xilinx Artix-7 FPGA involved for well under $300. Yes, there have been other products before it, you might not have noticed them as they're usually interstage, speak I2S and aren't designed with terminations that let audiophools bleat on about whether it sounds warmer, brighter or bloated whether connected over solid silver ostrich scrotum coated BNCs or HMDI leads made out of whatever space crud is currently coating Voyager 2. 

 

An FPGA isn't a cheap nor necessarily elegant way to do it, it's just the way Chord likes to do things and reflects their core competencies. A PC is neither an efficient way to do it though whatever PC you could assemble for half the price of the Chord is likely to smash it for raw grunt and flexibility, though right now there's no known freeware software allowing us to do as much as you've discovered, and then we'd all have to put up with other scratching chins musing just how many modified John Swenson supercap-backed linear power supplies it takes to make it truly live up to it's potential. Could be workable, and what you've done exists to probe that Chord has a workable product - should be no surprise to anyone. Would you have just bought a M Scaler after all the work if so?

 

Naturally they'll sell it for what their market will pay - which with Chord product tends to be a lot - for reference, a last-generation similar thing topping out at 384kHz and used in some ridiculously expensive DACs could be had new for under A$500, which should put some of the marketing gumpf in perspective. 

 

If you're of the mind I'd get in touch with iancanada over at diyaudio and talk about a collaboration; his kit is an ideal place for such a thing, and he might even have a mind towards the hardware involved and some of the firmware development necessary.

[Guest rmpfyf]

And for what it's worth - I've never heard a M Scaler, and I'm pretty sure (having some familiarity with the approach involved) it'll sound great.

[legend]

Of course what Chord is doing is a continuum of what has gone before - audio is a very mature technology.

 

And of course they will charge what the market will bear - for the reasons above it is very hard to make money in audio these days!

 

And it does not require unobtanium or particularly expensive products to hear the effects of the M-Scaler and @Ittaku upsampling - I use  $7k Kantu speakers and $3k Ncore amps and the effects are very obvious.

[Guest rmpfyf]

1 minute ago, legend said:

Of course what Chord is doing is a continuum of what has gone before - audio is a very mature technology.

 

And of course they will charge what the market will bear - for the reasons above it is very hard to make money in audio these days!

 

I wasn't complaining about as much, just pointing it out. The M Scaler should be quite profitable for Chord, unusually so in this segment, which could be taken to suggest it's somewhat overpriced for what it is though as a long-tap interstage filter with consumer terminations at >700kHz it's currently alone in market. I'd hope it eventually gets some competition.

 

That it's an FPGA approach is a continuum; that's a very particular skill set. The filter design itself isn't hard.

 

3 minutes ago, legend said:

And it does not require unobtanium or particularly expensive products to hear the effects of the M-Scaler and @Ittaku upsampling - I use  $7k Kantu speakers and $3k Ncore amps and the effects are very obvious.

 

You've missed the point also - it doesn't require unobtanium to hear the effects of any upscaling.

[legend]

When I worked for Linn in the late 1980s the markup from parts cost to retail price (in UK) was about 5x and I gather for Sony it was about 8x.  I suspect both may be less now as fat has been cut out.

 

I also think competition for the M-Scaler won't be long coming eg from things like in this forum - which is why Chord needs to make hay while the sun shines! 

Edited February 3, 2019 by legend

[Ittaku]

1 minute ago, legend said:

When I worked for Linn in the late 1980s the markup from parts cost to retail price (in UK) was about 5x and I gather for Sony it was about 8x.  I suspect both may be less now as fat has been cut out.

When I was looking at potentially making my speaker building a business, I worked out a business model and factoring in R&D and labour overheads, delivery, marketing, etc. it actually needed to be 5x the material cost to make it worthwhile. The business never got off the ground, but the speakers kept getting built for myself, family and friends instead

[legend]

As Alan Langford of DEQX frequently says "to become a rich audio manufacturer these days you need to start as a VERY rich one".  This particularly applies to speakers where anybody with a saw/router-bench thinks they could become one!

Edited February 3, 2019 by legend

[Guest rmpfyf]

58 minutes ago, legend said:

When I worked for Linn in the late 1980s the markup from parts cost to retail price (in UK) was about 5x and I gather for Sony it was about 8x.  I suspect both may be less now as fat has been cut out.

 

I also think competition for the M-Scaler won't be long coming eg from things like in this forum - which is why Chord needs to make hay while the sun shines! 

 

 4-5x is about right for consumer electronics.

 

Would be good to see a freeware/open source interpretation... there’s pretenders but nothing accomodating silly tap length.  Bits of the pie exist though, hopefully someone strings ‘em together.

[davewantsmoore]

14 hours ago, rmpfyf said:

Xilinx Artix-7 FPGA involved for well under $300

From memory the quick search I did in the other thread I could get it for a lot less than $300   

14 hours ago, rmpfyf said:

no known freeware software allowing us to do as much as you've discovered

The "software" is kinda the easy bit .... it's "what to do with it" which is much harder (ie. exactly how do you truncate the sinc function).    Like Chord have done, in any half way practical device, not a lot of delay is going to be acceptable.

[Ittaku]

It turns out it's extremely hard to find a simple coaxial input capture card for PC... Best I can find in current models is only optical at up to 192. Still looking...

[davewantsmoore]

I use both a Lynx AES16e and a TC Electronic Konnekt 48

[Ittaku]

11 minutes ago, davewantsmoore said:

I use both a Lynx AES16e and a TC Electronic Konnekt 48

Nice thanks. I don't suppose you've seen anything that actually accepts 384?

[Guest rmpfyf]

Why input at those rates?

Edited February 4, 2019 by rmpfyf

[Ittaku]

Just now, rmpfyf said:

Why input at those rates?

If the downstream DAC is to support up to 384, then ideally a standalone device should allow passthrough rates up to that as well. You don't want people to have to downscale any existing music just to upscale it again.

[davewantsmoore]

41 minutes ago, Ittaku said:

Nice thanks. I don't suppose you've seen anything that actually accepts 384?

The SPDIF standard only calls for 6mhz ... and this is not even enough to do 88/96khz rates

 

.... so you are 'on your own' here.

[davewantsmoore]

34 minutes ago, Ittaku said:

384

You know, I didn't actually think about the sampling rates they supported before I spat out my reply .... which was a little bit dim of me - cos I should have figured you'd be looking for something faster.

[Guest rmpfyf]

6 minutes ago, Ittaku said:

If the downstream DAC is to support up to 384, then ideally a standalone device should allow passthrough rates up to that as well. You don't want people to have to downscale any existing music just to upscale it again.

 

Could do it I2S though are you looking for a PC interface?

 

Why not use a network endpoint as the input and take things at file level?

[Ittaku]

26 minutes ago, rmpfyf said:

Could do it I2S though are you looking for a PC interface?

 

Why not use a network endpoint as the input and take things at file level?

I'm considering all possible PC options for a generalised solution; not just for my use case. Ideally it should have usb, coax and optical in, and the same outputs. I2S has its place but those three will cover 99% of the hi-fi world. Though for now I should probably be concentrating on my own...

[Nada]

On 30/01/2019 at 1:49 PM, Ittaku said:

sox -V4 input.flac -b 24 output.flac vol -2dB rate -b 99.9999 -d 32 -c 2147483647 88200

You'll have to hack sox to accept a higher bw_3dB_pc (max is normally 99.7) and there were a couple of overflows in some stack arrays that need to be expanded to cope. I hacked a few of these defaults into it to save me manually entering 32 bits and 2^31 and so on, but I've given you all the required command line options for the 30m taps.

 

Debug output:

/usr/bin/sox DBUG effects_i_dsp: make_lpf(n=30150865 Fc=0.4999996 β=21.1104 ρ=0.5 dc-norm=0 scale=1)
/usr/bin/sox DBUG rate: fir_len=30150865 dft_length=67108864 Fp=0.9999982171310080 Fs=1.000000 Fn=2.000000 att=198.68 2/1

 

Use -b 99.99996 for 78 million taps. After that you get overflows galore and it needs a major overhaul.

 

EDIT: Left out the -2dB adjustment above

Can you command SOX to do multi-threading in your filtering?

[Ittaku]

4 minutes ago, Nada said:

Can you command SOX to do multi-threading in your filtering?

Not in its current guise, no, and the filter uses up to 6GB in its current incarnation running just a single thread. I'd need to rewrite large chunks of code, or code from scratch porting over the filter only to do it multithreaded. A better version would be a mulithreaded pulseaudio filter to run it live which would use my approach to latency which is to start with a small filter and expand it as you get more data. Whether that's realistically doable, and whether I'll ever get around to it, is a different kettle of fish though (probably not the last one.)

[Nada]

40 minutes ago, Ittaku said:

Not in its current guise, no, and the filter uses up to 6GB in its current incarnation running just a single thread. I'd need to rewrite large chunks of code, or code from scratch porting over the filter only to do it multithreaded. A better version would be a mulithreaded pulseaudio filter to run it live which would use my approach to latency which is to start with a small filter and expand it as you get more data. Whether that's realistically doable, and whether I'll ever get around to it, is a different kettle of fish though (probably not the last one.)

Its a resource monster! 

 

Does it all crash happened when you insert the SOX command:

−−multi−threaded | −−single−threaded

By default, SoX is ‘single threaded’. If the −−multi−threaded option is given however then SoX will process audio channels for most multi-channel effects in parallel on hyper-threading/multi-core architectures. This may reduce processing time....

[Ittaku]

8 minutes ago, Nada said:

Its a resource monster! 

 

Does it all crash happened when you insert the SOX command:

−−multi−threaded | −−single−threaded

By default, SoX is ‘single threaded’. If the −−multi−threaded option is given however then SoX will process audio channels for most multi-channel effects in parallel on hyper-threading/multi-core architectures. This may reduce processing time....

Not now that I've fixed lots of things all over the place in the code to allow 64 bit ram allocation and more... But speed isn't a problem even single threaded, as it runs the 78 million tap filter in about 1/5th the time it takes to play the track.

 

Oh but it's no faster since the filter itself still seems to be single threaded.

Edited February 4, 2019 by Ittaku

[Guest rmpfyf]

1 hour ago, Ittaku said:

I'm considering all possible PC options for a generalised solution; not just for my use case. Ideally it should have usb, coax and optical in, and the same outputs. I2S has its place but those three will cover 99% of the hi-fi world. Though for now I should probably be concentrating on my own...

 

I’d vote Ethernet then. Getting a PC to handle anything else as an input is money, and you’re effectively asking a ‘second’ PC to act as an interstate at any rate. Nothing else is going to be as quick, robust or inexpensive.

 

Plenty of similar dual PC audiophile rigs do similarly, some using fibre links though IMHO not necessary.