Digital Control of Attenuation – Repository for DIY

[MagnusT]

Thanks to @mvaldes boards I have a running test 72323 and I'm trying out the different alternatives for code and libraries.

All these posted below work to control the volume but I have a problem that is identical regardless which one I use. If I make a loop and fade the levels in steps every half second or so it works great changing the volume on only one channel but when I try to change both channels, either one channels works perfectly but the other doesn't change or both channels change a bit haphazardly to different levels? Anyone seen this behavior?

• I've tried lowering the SPI bus frequency
• I've changed how often I change the levels of the two channels
• I've added a delay between changing the level of the first and the second channel

but no solution works.


These three all give me the same behavior:

• https://github.com/jerrylong-km/Muses72323_ESP32
• https://github.com/chipfunk/muses-72323
• https://www.diyaudio.com/community/threads/f5x-pre-my-way.381778/#post-7109578

 

[MagnusT]

@d00dz1

If I understand it correctly I get a "attenuation greater than max" error when attenuation is going down (volume rising) from 0b00010000 to 0b00001111

I haven't checked in your error checking code yet though

 

[d00dz1]

Hey @MagnusT ,

thank you for your report and testing out the library .

An attenuation value of 0b00001111 (as seen by the chip) is not listed in the datasheet as valid attenuation-range. The highest value (as seen by the chip) should be 0b111011111 (decimal: 479). Offsetting this for the 0dB-value (0b000100000, decimal: 32) results in 447 different attenuation-levels. So valid input-values to muses_72323_set_volume() are in a range of [0..447]. The value 447 (0x1bf) is defined as MUSES_72323_MAX_ATTENUATION. Any value greater than that should give the error you describe.

I extended the software-tests to check all valid attenuation-values to not return an error. You can see the commit here https://github.com/chipfunk/muses-72323/commit/49c978c8b6c1a927853f216a8dc55b020ae45c0b.

Hope this clarifies something, please feel free to ask further.

 

[MagnusT]

Thank you for the response!! My bad, I had a wrap around on zero on the attenuation value in my code, oooops



Still have the problem when setting both channel volumes, but that problem is the same regardless of library, your's or other's.

If I wait a second between setting the channel volumes like: set L, wait, set R, wait, set L, wait, set R and so on, each time a volume is set it works on the channel it is set on, but the other channel gets muted. So the sound flip flops between channels. If the delay between setting the channels is short the behavior seems more random.

 

[d00dz1]

@MagnusT looking at your code ... i think you're missing a corresponding call to SPI.end() for each SPI.begin() to stop the SPI-data- and -clock-signal ... maybe thats confusing the chip?

void musesSend(muses_72323_command_t command) {
  Serial.print(highByte(command),BIN);
  Serial.print("\t");
  Serial.println(lowByte(command),BIN);

  digitalWrite(MUSES_CS, LOW);

  // dunno why? delayMicroseconds(1);
 
  SPI.beginTransaction();

  SPI.transfer(highByte(command));
  SPI.transfer(lowByte(command));

  SPI.end();

  digitalWrite(MUSES_CS, HIGH);

  delayMicroseconds(1);   // let chip settle

}

As for your void setup() routine ... i think you can skip SPI initialization here and move it to function void musesSend(muses_72323_command_t command). That way all SPI communication with chip can be found and fixed in one place.

And maybe give the chip more than 1 microsecond to settle, did you mean milliseconds?


Good luck.

 

[MagnusT]

Thanks!! Giving it a try!


The microsecond delay was just copied from this code
https://github.com/jerrylong-km/Muses72323_ESP32

 

[d00dz1]

It's difficult to describe code-changes, so here they are:

Only enable SPI bus, do not start transaction, skip configuration

void setup() {
  Serial.begin(115200);
  pinMode(MUSES_CS, OUTPUT);
  digitalWrite(MUSES_CS, HIGH);

  SPI.begin();  // enable SPI for this project

  // lets try without musesConfigure();
  // lets try without musesMute(MUSES_72323_CHANNEL_RIGHT);
  // lets try without musesMute(MUSES_72323_CHANNEL_LEFT);

}

Start and stop SPI transaction for each command sent:

void musesSend(muses_72323_command_t command) {
  Serial.print(highByte(command),BIN);
  Serial.print("\t");
  Serial.println(lowByte(command),BIN);

  digitalWrite(MUSES_CS, LOW);

  SPI.beginTransaction(SPISettings(250000, MSBFIRST, SPI_MODE0));  // MUSES72323 SPI interface is rated at 250kHz maximum
 
  SPI.transfer(highByte(command));
  SPI.transfer(lowByte(command));
 
  SPI.endTransaction();

  digitalWrite(MUSES_CS, HIGH);

  delayMicroseconds(1000);
}

If 250 kHz is the maximum frequency for SPI, maybe lower that value to give you some safety margin.

 

[MagnusT]

Yup, sort of copied from the Muses72323 library.

No change with my problem yet though

 

[MagnusT]

Trying with and without link channels, but AFAIK that only affects gain, not volume

 

[MagnusT]

I've run at different SPI bus frequencies, not sure what is the lowest I can go. I set it as low as 5000 hehe

 

[d00dz1]

Page 8 on datasheet shows the SPI-CS/latch to go low after SPI-clock starts, maybe try

void musesSend(muses_72323_command_t command) {
  SPI.beginTransaction(SPISettings(115200, MSBFIRST, SPI_MODE0));
  digitalWrite(MUSES_CS, LOW);

  SPI.transfer(highByte(command));
  SPI.transfer(lowByte(command));

  digitalWrite(MUSES_CS, HIGH);
  SPI.endTransaction();

  delayMicroseconds(5000);
}

Edit: Just checked my code for another project ... that's how i've done it there.

 

[MagnusT]

I'll give the board an bonus extra careful clean. Who knows....

 

[MagnusT]

Tried the latch before/ after in some different combos. no luck

--------------------------

This is the traffic:

14:29:47.204 -> 10100 10000100
14:29:47.715 -> 10100 10000000
14:29:48.181 -> 10101 100
14:29:48.694 -> 10101 0
14:29:49.203 -> 10101 100
14:29:49.713 -> 10101 0
14:29:50.178 -> 10100 10000100
14:29:50.690 -> 10100 10000000
14:29:51.202 -> 10100 100
14:29:51.712 -> 10100 0
14:29:52.223 -> 10011 10000100
14:29:52.689 -> 10011 10000000
14:29:53.204 -> 10011 100
14:29:53.716 -> 10011 0
14:29:54.185 -> 10010 10000100
14:29:54.697 -> 10010 10000000
14:29:55.211 -> 10010 100

 

[d00dz1]

Can you try sending a single command from datasheet like

  command = 0b0001000000000100; // zero dB, right channel, no soft-step
  SPI.transfer(highByte(command));
  SPI.transfer(lowByte(command));

just once to check correctness of data-transmission please?

And maybe add a delay of at least 10 ms on void setup(), see datasheet "Recommended power-up sequence".

 

[MagnusT]

Good idea, I usually have a 200ms delay for Serial print to settle anyway

 

[MagnusT]

Interesting!!! Doing one more clean of the board solved everything.

Thanks for all input!!

 

[MagnusT]

 

[MagnusT]

Since the board has 200+ components, mainly smd, I ordered assembled from JLCPCB, no way I'll do 200 by hand . Shipped today from China.

It's a fully "MUSED" DJ mixer, all control will be done with four MUSES72323 chips. Since you never know if you get things 100% right the first round (one rarely does) I tried to add many "good to haves", like room for power decoupling components in multiple configurations so i can try different OPAs, pin headers if I want to add tone controls, patch in effect boards, use other RIAAs, power supply stuff done so I can run it from either DC or AC sources trying different configurations out and so on and so on.... Even before getting the boards (minimum at JLCPCB are five boards where two are assembled) I've noticed two mistakes, one is just a mislabeled text saying 24V where it should say 18V and... I missed connecting AGND and DGND at the spot where I was planning to do it. That's an easy fix though, let's see what I find out more when I get the boards

Yesterday I wrote the bulk of the software to control everything from an external (isolated) ESP32 that uses a mix of pots, rotary encoders and a veeeery special crossfader.

Here's the schematic and a first version of the code. Comments are welcome, have I forgot something totally essential or done something stupid? 40 years since I last had fun designing analog audio stuff

 

[Skylar88]

Wow, that's a courageous undertaking, @MagnusT. Four Muses chips + OPAs! I'm guessing it's more for pro audio use than for audiophile HiFi.

What kind of visual feedback are you using (screen)?

Edit: I've just noticed that al 4 Muses chips are addressed together with the same latch pin. Interesting. I would have thought that you might want to set volume separately, but I don't really understand what the project does.

Edit2: Why are you using 18V? So far I've seen other projects use 15V. I know that the Muses chips can accept 18V, but was under the impression that it is the maximum, and that it's safer to use a bit lower voltage.

 

[MagnusT]

The idea is sort of an Audiophile DJ mixer I recently bought a cheap Behringer DJ mixer to do some rebuild/experiments on. It's built around 4580, 074s and a 2164 VCA. But I was shocked of the surprisingly awful sound quality so I decided to experiment on something more proper.

- the chips are addressed with their chip address pins ADR0 and ADR1, four combinations in total available, perfect for this project

- as with everything in this experiment/project, 18V is a starting point that I can change depending on what OPAs I use and so on. But with 12" singles generating very high output levels from MM cartridges in combination with man handling the vinyl while the needle is on it I thought the best head room possible wouldn't be a bad idea. But I am not 100% sure if 18V is "absolute max" or "a normal max to use" for some OPAs and the MUSES. So you have a point.

Not sure I got the question about visual feedback. For starters I'm just using knobs and stuff but I'll need some leds displaying what cue mode (auto, xfade, split mode and so on) that is chosen and so on. The fun part with this mixer is that the physical user interface is not connected to the audio at all, giving room to try different physical UIs. And even to be able to swap out the whole control, it's just a thin cable going to the audio box.