Schiit (MultiBit) Bifrost

I didn't try turning off the port power mgmnt. I'll try that tonight and let you know.

 

It may be hardware issue. Download one of popular linux distro and run it on LiveCD mode, then see if it recognize DAC properly.

As far as I know, W10 does not support USB Audio 2.0

 

Out of the box no, it's still Class 1, 24/96 max just like 8 and 7 because MS is stupid.

 

Per Mike (still the most concise summation of the "supercomboburrito" filter):

The below are the claims of the digital filter in the Yggdrasil: (and Gungnir Multibit/Bifrost Multibit--JS)

1. The filter is absolutely proprietary.

2. The development tools and coefficient calculator to derive the above filters are also proprietary.

3. The math involved in developing the filter and calculating has a closed form solution. It is not an approximation, as all other filters I have studied (most, if not all of them). Therefore, all of the original samples are output. This could be referred to fairly as bit perfect; what comes in goes out.

4. Oversimplified, however essentially correct: The filter is also time domain optimized which means the phase info in the original samples are averaged in the time domain with the filter generated interpolated samples to for corrected minimum phase shift as a function of frequency from DC to the percentage of nyquist - in our case .968. Time domain is well defined at DC - the playback device behaves as a window fan at DC - it either blows (in phase) or sucks (out). It is our time domain optimization that gives the uncanny sonic hologram that only Thetas and Yggys do. (It also allows the filter to disappear. Has to be heard to understand.) Since lower frequency wavelengths are measured in tens of feet, placement in image gets increasingly wrong as a function of decreasing frequency in non time domain optimized recordings - these keep the listener's ability to hear the venue - not to mention the sum of all of the phase errors in the microphones, mixing boards, eq, etc on the record side. An absolute phase switch is of little to no value in a non time domain optimized, stochastic time domain replay system. It makes a huge difference with an Yggdrasil.

5. This is combined with a frequency domain optimization which does not otherwise affect the phase optimization. The 0.968 of nyquist also gives us a small advantage that none of the off-the shelf FIR filters (0.907) provide: frequency response out to 21.344KHz, 42.688KHz, 85.3776KHz, and 170.5772KHz bandwidth for native 1,2,4, and 8x 44.1KHz SR multiple recordings - the 48KHz table is 23.232, 46.464, 92.868, and 185.856KHz respectively for 1,2,4, and 8x. This was the portion of the filter that had the divide by zero problem which John Lediaev worked out in 1983, to combine with #4 above AND retain the original samples.

This is what the competition offers:

Frequency domain optimization FIR filters with Parks-McClellan optimization. The development tools for these types of filters can be downloaded for a price range of free to $300 on the internet. Parks-McClellan is the goto filter optimization for audio design. These filters are derived with no closed form math; only successive approximation. The original samples are lost. The output is approximated. An educated guess. This optimization is ubiquitous in the front end of delta sigma dacs as well as standalone digital filters. While there is no inherent phase shift within Parks-McClellan filters, there is no optimization of phase either. The listener is left with what remains from the mixing boards, transducers, brick-wall filters, etc which can and usually do destroy proper phase/position information. Finally, it is processor efficient and economical to implement. Read cheap.

Any avoidance of the Parks-McClellan pablum requires a lot of original DSP work. Am I a prophet who received the tablets from God or some other high-end audio drivel. Hell, no. I was the producer and director of this project and worked with Dave Kerstetter (hardware-software), John Lediaev (Math), Tom Lippiat (DSP Code), Warren Goldman (Coefficient Generator and development tools) for a total of 15 or so man years. These folks either taught math at The University of Iowa, Computer Science at Carnegie-Mellon University, worked at think tanks like the Rand Corporation – you get the idea. We did this for no money - What we all had in common was that we loved audio. All other audio pros were interested in Parks-McClellan and pointed and laughed at us. That's the way it happened.

It was worth it, every hour, day, and year. So go for it if you want. For what it is, it is not a lot of money.

Tap length is 18000 in Gungnir MB and Yggdrasil, 9000 in Bifrost MB. Stopband rejection is 120dB+, IIRC. I think Marv has plots.

 

ouch my head hurts, Jason, but many thanks for the details. I am so glad you guys get it and have invested in it for us.

I feel proud I once read up on Parks-McClellan math, perhaps the wrong stuff to invest my time in.

 

So my take away is that the trickle down from Yggdrasil to Gungnir Multibit was fairly true to what Yggdrasil was (in spirit), but Bifrost Multibit has ended up differently. Less analytical, more "fluid?" Does this change how a Bifrost Multibit/Lyr2 stack would compare to a Gungnir Multibit/Mojo 2 stack? I keep comparing these 2 because the SE stack is basically half the price of the balanced stack.

 

Meh Hugo has 26000 taps Dave has 80000

 

Yeah, and, uh, remind what a "tap" is again...

 

An FIR filter is made up of a series of taps which are chained sequentially, so a 9000-tap filter has 9000 things linked together in a long chain. Digital samples enter on one side of the chain, and exits out 9000 taps later. Each of these taps does 3 things:

1. Multiply its input by some pre-determined constant (2, 3.14, -8000, whatever). These constants are what's calculated when you design a filter.
2. Add it to the output of its neighbor.
3. Pass its input to its neighbor.

The next sample is fed into the chain, and the whole thing repeats. The output sample is the sum of the output of the all the taps acting on the last 9000 samples.

This also means that it takes 9000 tap delays for the first audio output sample to appear. In the case of a 96 kHz sample rate, that's a delay of 9000/96000 = 0.09 seconds, or about 90 milliseconds. This is also almost 6 frames of a 60 Hz video signal, and that's one of the big problems of having large FIR filters: the latency makes syncing up with video difficult. In exchange, you get to have very complicated filter responses by using many taps.

Many built-in filters on commercial DAC chips actually reduce their filter length the higher the sample rate you use, which, back in the day, led to really crappy performance when the chips were playing back high sample-rate audio. Benchmark's DAC-1 resampled everything to 110kHz because they determined that the best performance of the DAC they were using was at that sample rate.

 

The machine I had problems with was a Surface Pro 3, which hides the power management setting for some reason. It's probably a misguided attempt to help the user by reducing confusion, but I'm not going to email Microsoft to confirm that. I'll figure something out eventually, or I'll buy a cheap mac on Craigslist for taking to meets.

 

Mike from Schiit, why is it important that you obtained an exact solution to the filter and not just an approximation? Don't you end up doing an "estimation" anyways when you do discrete math with finite bit precision?

You also have to worry about overflow during multiplication and addition at every single tap of the filter, or potentially a truncation or rounding at the end if higher bit precision is used for the computations. Or if you choose to do coefficient normalization, you throw away some bits of precision potentially, unless you go overboard with 64 or 128 bit double floating point precision, you will end up introducing some sort of rounding or truncating during the physical calculation of the filter output, and hence obtain an "estimation" of sorts.

Genuinely curious about the work done here, I'm focusing on DSP and image processing for my masters. It seems to me that if the estimation is "close enough" more noise will be introduced by quantization as opposed to the error of the estimation.

 

Damn. What a lovely place this is (of course CS was already).


What's the reason for JRIVER's upsampling?

 

In case this helps anyone... On my Win 7 laptop I had to right click device manager and run it as administrator, then manually update the device driver with the downloaded one to make the pc recognize the dac. As in, downloading the 1.03 drivers and running the setup exe would install the driver, but the pc would not use the new driver until I made it with admin permissions. Manually installing from device manager without admit permissions gave an access denied error. The 1.03 drivers are the only ones I can get to work on either of my pcs.

 

Luis, I think it's time to take Mike Moffat out to dinner and buy him a few beers. You've got plenty to talk about!