Bushmaster MKII input signal purity level indicator

[StanleyB]

It seems that I forgot to remove one of my engineering codes from the firmware in the 2nd production of the MKII. It's a piece of code that I wrote to check the purity of the incoming signal on each digital input socket of the MKII.
Normally I wouldn't bother about leaving an engineering code in the FW, but the blinking of the LEDs in certain conditions might cause users to feel alarmed what might be wrong. So I'll give a quick breakdown for those who might come across the purity code in operation.

The code will only be activated when the DAC is put in the LED dimming/sleep mode. So when music is playing, the LEDs are OFF. But if there are any signal errors (not to be confused with audio buffering periods from such things as the Squeezebox) the dimmed LED on the input that is active will increase in intensity. So small errors will be very faint, whilst big errors will lighten up the LED to the full. You can get it to operate by changing tracks on a CDP. It will also get triggered by high bitrates or sampling rates signals that are sent down a not so good or excessively long cable. Or it can get triggered if the cable is not plugged in properly.

It's a unique feature that you won't find on any other DAC. But I am not keen to see anyone copying it. So I'll probably take it out the next time.

[HighFidelityGuy]

Now that's a clever feature! I'm running mine with the LED's off now and I've not noticed any blinking yet, so that's a good sign I guess. I'll keep an eye out though.

[Canetoad]

Mine blinked yesterday when changing from a 16/44.1 flac file to a 24/96 one. Now I know why.

[MartinT]

That's a good feature, Stan, and relatively hidden if it only kicks in on dimmed/sleep mode. I wish you had made it standard (on my 1st production run Mk. II).

[HighFidelityGuy]

I've discovered how to demonstrate this feature in my system by playing 192KHz Flac files. They make the input LED go full on disco strobe and the music is all distorted and crackly. It seems that something in my digital signal chain doesn't like 192KHz files. 96KHz files work perfectly. It's as if I don't quite have enough bandwidth to allow anything beyond 96KHz.
My hiFace EVO and it's driver are supposed to be 192KHz compatible, as is the Bushmaster MkII. So unless something is wrong with one of them, which I doubt, then perhaps I have a dodgy cable.
I'm using a bloody expensive and very short Wireworld USB cable between my PC and EVO, so my guess is my Supra Trico coax cable is to blame. Looking at it's connectors they don't seem to be terminated very well. I think I'll invest in a Mark Grant G1000HD BNC to phono cable to see if that solves the problem.

[HighFidelityGuy]

Hmm, well it doesn't seem to be my coax cable. I remembered that I had one of Mark's Belden cables spare and I get the same problem with that. I've tried moving my EVO to a USB3 socket and swapping to a different USB cable and that didn't help either.

[StanleyB]

It seems that something in my digital signal chain doesn't like 192KHz files. 96KHz files work perfectly. It's as if I don't quite have enough bandwidth to allow anything beyond 96KHz.
My hiFace EVO and it's driver are supposed to be 192KHz compatible, as is the Bushmaster MkII.

The LEDs are only supposed to light up that bright when there is no clock signal to be detected from the source, or if the clock signal is well outside the PLL clock capture range. If it works OK on 96KHz, I wouldn't suspect the coax cables. How are things at the PC end? Anything that you installed recently that might be hugging resources?

[HighFidelityGuy]

Thanks Stan. It's a dedicated media centre PC that rarely gets anything installed on it other than Windows updates, which I haven't done for a week or two. As far as I can see nothing is hogging resources. It's a Core i5 with 8GB of RAM, an SSD for Windows and a RAID5 array for my music and videos etc. So it's pretty capable. I've tried restarting it as well. It could still be a software/driver issue on the PC I guess. Either that or something is wrong with my EVO.

I'll try to make a video of the LED flashing. It doesn't flash constantly and sometimes it gets brighter depending on how badly distorted the sound is. I can sometimes get several seconds of perfect sound with no flashing but then it starts up again. The other odd thing is that when I stop the playback, the LED continues flashing dimly as though the DAC isn't synced to the source or something. Then when I start playing another lower res file the LED stops flashing and I get perfect sound.

If you fancy trying out the file I've been using it's the 338MB Mozart piece at the top of this list: http://www.2l.no/hires/index.html

Cheers.

[Yomanze]

That's a good feature, Stan, and relatively hidden if it only kicks in on dimmed/sleep mode. I wish you had made it standard (on my 1st production run Mk. II).

Indeed, very cool, my DAC has a error light, but it doesn't dim and light up according to severity (just flashes).

[StanleyB]

I'll try to make a video of the LED flashing. It doesn't flash constantly and sometimes it gets brighter depending on how badly distorted the sound is. I can sometimes get several seconds of perfect sound with no flashing but then it starts up again. The other odd thing is that when I stop the playback, the LED continues flashing dimly as though the DAC isn't synced to the source or something. Then when I start playing another lower res file the LED stops flashing and I get perfect sound.

That's the one reason why I was concerned about leaving the engineering code in the FW. It's good for lab tests, but distracting when used during normal music listening. The flashing LED can make you paranoid.
The fact that it only flashes at 192 and not at the lower resolutions shows at least that the clock detector is working. But be cautious in how you interpret what you see compared to what you hear. The flashing LED is taking measurements at 12MHz, which is the FW clock frequency. 192KHz signal bandwidth is larger than that. So there are times when the incoming clock will have been and gone before the FW code has even been able to detect it.
I have tried a souped up FW clock of 20MHz, but current consumption of the DAC goes up. (I am looking to try out even higher clock frequencies as possible future mods, but first I have to be able to hear a difference to say that it is worth a try.)

192KHz decoding and processing is heavily time critical. I had to wire my Touch into the RJ45 socket of a wireless N repeater before I could get reliable 192kHz audio playback on EDO between wireless NAS and Touch. The inbuilt wireless connection of the touch just couldn't keep up the pace.