Control of BBB-based audio appliances

[wealas]

What does your sheet give for register 15 bit 3?

Yep, same here 1b1

 

[Russ White]

FWIW - with my (on-board) firmware I can change filters on the fly all I want with no issues at all. I would suspect you were doing something else unexpected.

 

[Russ White]

Also if you look at my source code you can see the defaults.

 

[francolargo]

FWIW - with my (on-board) firmware I can change filters on the fly all I want with no issues at all. I would suspect you were doing something else unexpected.

Thanks for checking in, Russ.

On reflection, that's what I now think as well. Changing filters was the last I2C message that went out (intentionally) before the damage, but I now suspect the individual channel volume registers. I tweaked them in the 9018 w/o issues, explaining my overconfidence! In the new listening space - better acoustics but still not perfect - I won't need to tweak left vs. right volume. No need to take more chances. ...and the new midranges are on their way...

Cheers,

Frank

PS. When I issue a soft reset by sending a 1 to register 0, register 15 doesn't seem to contain the 1 in bit 3 that the data sheet says is default. However, stereo mode seemed to be working when I set bit 3 to 1, so I'll assume all is well with it there. ...unless you specifically keep it at 0. The very useful GitHub link you referenced doesn't mention bit 3 of register 15.

 

[francolargo]

Mini-update:
I just can't imagine a cause for the different automute behavior between the 9018 and the 9028. Using Logitech Media Server remotely with Squeezelite on the BBB, the 9028 has introduced - or fails to stop - nasty noise on some track changes. Variable intensity, yet never happened with the 9018 set to default automute. Now, the best way to minimize the noise is to set register 2 (automute enable, etc.) to 0xfc and register 4 (automute time) to 0xff (max for register 4). Register 5 (automute level) doesn't seem to affect the noise threshold.

I'm not convinced that this automute behavior would have stopped the recent DC driver damage. I wonder if the DAC chip might react unpredictably to minor line surges or other power disturbances (I saw the same behavior on 3 parallel 9028s). For now, I'm setting up with 'disposable' test drivers until the system proves 100% reliable.

 

[Russ White]

I haven't observed any strange automute behaviour in the stock firmware. If you can you might try to emulate what it does.

Cheers!
Russ

 

[Russ White]

You could try swapping back to on-board just to be certain it works in your case But I am using similar I2S/DSD sources without any issues.

 

[francolargo]

You could try swapping back to on-board just to be certain it works in your case But I am using similar I2S/DSD sources without any issues.

The onboard chip is definitely on the list of stuff to try!

Comparing notes with my best read of the GitHub code:

Re: automute... You're using a switch on register 2, register 4 is set to 4, and register 5 is default. I've tried those settings and the track switching noise is a bit worse than what's in there now.

For register 13 I can't tell if you are using 'default' or specifically writing 0x10. The data sheet seems to have an error. It says default is 0x10 (to enable dither, enable THD compensation logic, and to enable the DPLL + jitter eliminator). However, a soft reset defaults to 0x20 for register 13, ie. disabled THD compensation *and disabled jitter eliminator*.
For example, here is a soft reset followed by a register read:

root@beaglebone:/usr/script# i2cset -y 1 0x48 0x00 0x01
Error: Write failed
root@beaglebone:/usr/script# i2cdump -y 1 0x48
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 0c 3c 00 00 68 4a 40 88 88 00 00 5a 20 8a 01    .?<..hJ@??..Z ??
10: 00 00 00 00 00 00 00 00 ff ff ff 7f 00 00 00 00    ...........?....
20: 00 00 00 00 00 00 10 32 54 76 00 00 00 00 00 e0    ......?2Tv.....?

Register 0x0d is clearly 0x20 = 8'b 0010 0000. In any case, setting register 13 to 0x10 (using dither with jitter eliminator?) doesn't affect the inter-track noise.

Usually, audio is a winter hobby for me... The cheapie TangBand drivers are here now - I'll get them in plain baffle boards and hooked up and not push it. The good drivers can wait till travels are done and the nice weather is south. [...turns out one of the AMT tweeters also overheated... I'm guessing the DC surges are not caused by these I2C settings per se. However, perhaps in the past automute dropped output to non-lethal levels. I'm thinking that I should update Cronus to the one with buffered clock output - perhaps more robust/stable?]

Very much appreciate your interest and all your contributions to great sound, Russ!

Frank

PS. Here's a full register dump of whats in the chip at this point:

root@beaglebone:/usr/script# i2cdump -y 1 0x48
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 0c fc 00 ff 60 4a 60 88 88 00 00 15 10 8a 0f    .??..`J`??..????
10: 00 00 00 00 00 00 00 00 ff ff ff 0a 00 00 00 00    ...........?....
20: 00 00 00 00 00 00 10 32 54 76 00 00 00 00 00 e0    ......?2Tv.....?
30: 03 00 04 00 04 00 f0 00 00 ff ff ff ff 4f 00 06    ?.?.?.?......O.?
40: a3 0f 48 7a cd 39 00 00 00 00 00 00 00 00 00 00    ??Hz?9..........
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 00 f3    .............?.?
60: 3f 4b 06 00 01 00 00 00 00 00 00 00 00 ff 00 00    ?K?.?...........
70: 80 00 00 80 XX XX XX XX XX XX XX XX XX XX XX XX    ?..?XXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: a3 0f 48 7a cd 39 00 00 00 00 00 00 00 00 00 00    ??Hz?9..........
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 00 f3    .............?.?
e0: 3f 4b 06 00 01 eb eb eb eb eb eb eb eb ff 00 00    ?K?.?????????...
f0: 80 00 00 80 XX XX XX XX XX XX XX XX XX XX XX XX    ?..?XXXXXXXXXXXX

 

[Russ White]

Hmm - I am strongly suspecting the I2c communication is flaky - that's why I am suggesting testing on-board firmware before going a lot further. You might want to switch I2C buses? Maybe you are having a master conflict.

For my firmware I initialize registers I change with constant defaults (yes - they are based on the datasheet) - then mutate them per switch settings before sending it off to the DAC - This way I don't waste cycles reading data I don't use - and I can be sure I am setting just exactly want I want.

Cheers!
Russ

 

[Russ White]

Edited - I needed to look closer. 0x20 (32 decimal) is indeed the correct default.

 

[Russ White]

You might try using an actual I2C library and C or Python - sometimes those i2c command line tools are super flaky.

 

[francolargo]

You might try using an actual I2C library and C or Python - sometimes those i2c command line tools are super flaky.

Good to know!

I use an I2C 4 channel mux and I have never once seen it fail. But I have a backup chip, inserted it, and no difference. I will get around to inserting the firmware chips asap. Meanwhile, I think my reset observation from the command line is reproducible. Here is a quick Python loop program to soft reset each of the 3 9028s, read and print register 13, and then pop 0x10 into the register: (0d32=0x20)

#!/usr/bin/env python2.7
# -*- coding: utf-8 -*-
import socket
import time
import subprocess
import smbus
bus = smbus.SMBus(1)
for x in range(1,10):
 try:
  bus.write_byte_data(0x70, 0x40, 0x06)  # midrange address
  bus.write_byte_data(0x48, 0x00, 0x01)  # reset DAC
 except IOError as err:
  time.sleep(.2)
  Register = bus.read_byte_data(0x48, 0x0d)  # what's in register 13?
  print "mid-DAC register 13 resets to: ",(Register)
  bus.write_byte_data(0x48, 0x0d, 0x10)  # set register back to 0x10
 try:
  bus.write_byte_data(0x70, 0x40, 0x05)  # tweeter address
  bus.write_byte_data(0x48, 0x00, 0x01)  # reset DAC
 except IOError as err:
  time.sleep(.2)
  Register = bus.read_byte_data(0x48, 0x0d)  # what's in register 13?
  print "tweet-DAC register 13 resets to: ",(Register)
  bus.write_byte_data(0x48, 0x0d, 0x10)  # set register back to 0x10
 try:
  bus.write_byte_data(0x70, 0x40, 0x04)  # woofer address
  bus.write_byte_data(0x48, 0x00, 0x01)  # reset DAC
 except IOError as err:
  time.sleep(.2)
  Register = bus.read_byte_data(0x48, 0x0d)  # what's in register 13?
  print "woof-DAC register 13 resets to: ",(Register)
  bus.write_byte_data(0x48, 0x0d, 0x10)  # set register back to 0x10

and here is what prints...

root@beaglebone:/usr/script# python reset.py
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32
mid-DAC register 13 resets to:  32
tweet-DAC register 13 resets to:  32
woof-DAC register 13 resets to:  32

 

[Russ White]

Hmm that's interesting. What are you reading as the initial state of register 13? No soft reset - just the standard hardware reset.

 

[francolargo]

Hmm that's interesting. What are you reading as the initial state of register 13? No soft reset - just the standard hardware reset.

This on all 3 chips after power down and restart - 0x20 in register 13.

root@beaglebone:/usr/script# i2cdump -y 1 0x48
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 0c 3c 00 00 68 4a 40 88 88 00 00 5a 20 8a 01    .?<..hJ@??..Z ??
10: 00 00 00 00 00 00 00 00 ff ff ff 7f 00 00 00 00    ...........?....
20: 00 00 00 00 00 00 10 32 54 76 00 00 00 00 00 e0    ......?2Tv.....?

Will try to pop the firmware chips back in tonight...

F.

 

[Russ White]

Hmmm - I should have read closer - if you look both at the datasheet and my code you will see that 0b00100000 is indeed 32 or 0x20. That is correct. Not sure where 0x10 came from

Cheers!
Russ

 

[Russ White]

In fact setting register 13 to 0x10 could be very bad - because that part of the register (the least significant 5 bits) is reserved.... I have no idea what it does.

 

[francolargo]

Ohhh snap! My careless mistake forgetting the last bit is zero, not one! ...will correct that and double check other settings!

Meanwhile, I'm watching for any unintended resets or register changes. I may have just seen one that defaulted register 4.

 

[francolargo]

I wrote a python program that loops continuously in the background to monitor the status of any particular single register. If that register changes from its intended value, then the program dumps all register contents, soft resets the chip, and reloads my desired settings. This lets me test for problems with the amps off! If an unintended reset were to happen - and I may have seen it again during program debugging - it bumps us out of stereo mode, turns automute off, and cranks the volume to 127. We'll see what information develops.

 

[francolargo]

Using the monitor program or speakers for a couple of days now, I have not detected any unintended resets *as the result of I2C manipulations*. But I have seen a couple related to disturbances in the power line.

Example 1: with the DACs muted via register 7, but I2S coming from the BBB, I turned off an amp that was plugged into the same surge suppressor. Suddenly music was heard through that channel until the amp power supply was drained.
Example 2: There are 10 power supplies in the chassis with the 3 DACs & I/Vs so I actively extract the warm air with fans outside of fine-mesh metal screens on top of the chassis. That fan power is an external switching 12v wall wart and those 12v never enter the chassis. I unplugged it and got a DAC reset with enough impact to toast a pair of cheap tweeters. But 12v power for other fans (that move air past the amp heatsinks) are on a thermostat and they have never caused a disturbance.

In the past with the 9018s inside, most of the use was in a different house. The system would occasionally mute spontaneously (for a second or two), sometimes when certain compressors (not far from the listening room) would kick on/off. ...or especially during heating season with static discharge from touching the DAC/BBB chassis or from a painful zap into nearby house ground. But the correct volume was always restored so I assumed that was an automute from loss of the I2S supply from BBB/Hermes/Cronus. Maybe that assumption needs analysis.

So, my attention in this matter is expanding. In addition to catching and correcting spontaneous and potentially damaging changes to DAC registers, I'm looking into how to best isolate the DACs from any&all disturbances - both internal and external - that could cause a spontaneous change or reset. Any and all thoughts/suggestions much appreciated!

 

[francolargo]

I should have mentioned above: All of the gear is TPA. Each Buffalo is powered by one dedicated side of LCDPS supplies (which run nice and cool with the 9028s). Legatos underneath are powered by the current Placid HDs. All amps and DAC chasses have inexpensive RFI/EMI filters in the power inlet sockets.