Ordered two OPA1656 that I just received, put them in the RIAAs and got lower DC offset out compared to the NE5532s as planned. Keeping the NE5532s in the mixer circuits though, everything sounds great so far.
Planning to raise the input and feedback resistor values to load the MUSES slightly less. Swapping 47k input to 100k. Raising gain slightly at the same time, I'll see if I go for 330k or 470k for feedback resistors.
Been searching for some metal housing but the dimensions of my board are a bit unusual compared to more common pre/power amp/DAC builds?
Board is 215mm x 70mm and height is just under 40mm.
Planning to raise the input and feedback resistor values to load the MUSES slightly less. Swapping 47k input to 100k. Raising gain slightly at the same time, I'll see if I go for 330k or 470k for feedback resistors.
Been searching for some metal housing but the dimensions of my board are a bit unusual compared to more common pre/power amp/DAC builds?
Board is 215mm x 70mm and height is just under 40mm.
I tested the code from this thread for my 72323 and liked the one by @Nikon1975 most. I attach a modified version that uses soft SPI so that any GPIO can be used instead of the hardware SPI pins:
Timely post for me! Thanks. Am trying - again - to sit down and finalise my 72323 interface, essentially two MUSES chips and the Waveshare 2.4 display. I'm using an ESP32 (with your debounce library!). Only outstanding part is the MUSES software.
Am I correct in assuming you can change to 0.5db increments by simply changing the 0.25 in void attenuation() to 0.5db? (Guess that removes the LSB?).
Also, are any alterations to the library .cpp and .h files needed for multiple MUSES chips on the same SPI bus? Especially if using different latch pins for the two MUSES chips.
Guess I need to sit down and play with the various options. Lately I seem to have very limited time for this wonderful pastime, so in an effort to save time I'm looking for feedback with my particular configuration. I'm aware Magnus has four MUSES chips, separately addressed, on a single latch pin. I'm also aware Skylar88 is using a single ESP32 SPI bus' Data and Clock lines (but with pin 15 instead of the 'standard' ESP32 VSPI pin 5 for SS ) to control the Waveshare display as well as a single MUSES chip.
Plan A was to first try that pin 23/18/15 configuration with the Waveshare as well as the two MUSES chips. All three devices on latch pin 15. If anyone has tried something like this please let me know your results
.
Plan B was to use the two default ESP32 SPI buses exactly as 'standard' - the Waveshare on VSPI (so pin 23 as Data, pin 18 as Clock and pin 5 as latch) and the two MUSES on the ESP32's HSPI bus (so pin 13 as MOSI, 14 as Clock and use 15 and 16 as latch pins). I think Skylar88 mentioned he could only get the Waveshare to work with 23/18 and 15 as latch.
Am I correct in assuming you can change to 0.5db increments by simply changing the 0.25 in void attenuation() to 0.5db? (Guess that removes the LSB?).
Also, are any alterations to the library .cpp and .h files needed for multiple MUSES chips on the same SPI bus? Especially if using different latch pins for the two MUSES chips.
Guess I need to sit down and play with the various options. Lately I seem to have very limited time for this wonderful pastime, so in an effort to save time I'm looking for feedback with my particular configuration. I'm aware Magnus has four MUSES chips, separately addressed, on a single latch pin. I'm also aware Skylar88 is using a single ESP32 SPI bus' Data and Clock lines (but with pin 15 instead of the 'standard' ESP32 VSPI pin 5 for SS ) to control the Waveshare display as well as a single MUSES chip.
Plan A was to first try that pin 23/18/15 configuration with the Waveshare as well as the two MUSES chips. All three devices on latch pin 15. If anyone has tried something like this please let me know your results
.Plan B was to use the two default ESP32 SPI buses exactly as 'standard' - the Waveshare on VSPI (so pin 23 as Data, pin 18 as Clock and pin 5 as latch) and the two MUSES on the ESP32's HSPI bus (so pin 13 as MOSI, 14 as Clock and use 15 and 16 as latch pins). I think Skylar88 mentioned he could only get the Waveshare to work with 23/18 and 15 as latch.
@derekr There is no any issue using multiple Muses on the same SPI bus with only one latch pin. I'm doing this with my boards
But I'm not using a SPI display but an low res I2C ones.
I'm a little bit late on developing my project and I'm planning to move to an Hires SPI display in a (hope short) future. Do you have any evidence of any conflict between Muses and SPI display ?
But I'm not using a SPI display but an low res I2C ones.
I'm a little bit late on developing my project and I'm planning to move to an Hires SPI display in a (hope short) future. Do you have any evidence of any conflict between Muses and SPI display ?
@mvaldes Know what you mean about time taken to get this project done! So far I have the Waveshare display and the ESP32 living happily together. Am about to implement the Muses - hence queries above. Hope to get some time today/tomorrow and I'll for sure report what I find.
Yes, I accept that a single SPI latch pin can handle two Muses chips. Magnus confirmed with FOUR chips - even though I've read somewhere that you shouldn't go above three devices on a single ESP32 SPI bus.
Here's where I'm at - Waveshare set up as per online tutorials, MOSI on 23, Clock on 18 and SS on 15. I have the DS, RST and BL pins on 16, 18 and 19 FWIW. I have not tried the ESP32's default VSPI SS pin 5 with the Waveshare as it worked perfectly on SS pin 15 as per the tutorial. Skylar88 (speaking from memory) may have tried SS on pin 5 with no luck - I am going to try that first (without Muses) and see how it goes as that is the default ESP32 VSPI SS pin.
I am building this primarily for use in a balanced Iron Pre so need two Muses chips. I haven't actually tried any of the Muses code above but it seems quite straightforward except (to me, not a trained programmer) in the area of the library handling two Muses chips - I can't see any provision in the library for defining the second chip. Wouldn't the compiler throw a "Redefining the same address" error if I add "static Muses72323 Muses(1); // address of muses chip, usually 0" to the already existing "static Muses72323 Muses(0); // address of muses chip, usually 0"?
Go for that hires display, it's truly a step up.
Yes, I accept that a single SPI latch pin can handle two Muses chips. Magnus confirmed with FOUR chips - even though I've read somewhere that you shouldn't go above three devices on a single ESP32 SPI bus.
Here's where I'm at - Waveshare set up as per online tutorials, MOSI on 23, Clock on 18 and SS on 15. I have the DS, RST and BL pins on 16, 18 and 19 FWIW. I have not tried the ESP32's default VSPI SS pin 5 with the Waveshare as it worked perfectly on SS pin 15 as per the tutorial. Skylar88 (speaking from memory) may have tried SS on pin 5 with no luck - I am going to try that first (without Muses) and see how it goes as that is the default ESP32 VSPI SS pin.
I am building this primarily for use in a balanced Iron Pre so need two Muses chips. I haven't actually tried any of the Muses code above but it seems quite straightforward except (to me, not a trained programmer) in the area of the library handling two Muses chips - I can't see any provision in the library for defining the second chip. Wouldn't the compiler throw a "Redefining the same address" error if I add "static Muses72323 Muses(1); // address of muses chip, usually 0" to the already existing "static Muses72323 Muses(0); // address of muses chip, usually 0"?
Go for that hires display, it's truly a step up.
OK, I updated the code and made it possible to freely specify all pins in the soft-SPI version (@Skylar88, you might want to add a link to the first post: included are working code examples for each library). In the hardware-SPI version you now can specify any pin as the chip select. Both libraries will allow you to use more than one chip on the same bus. The code is based on the library by @Nikon1975, the soft-SPI library is included in my package and comes from here. The soft step feature of the muses chip is always enabled, the zero cross detector can be disabled as well.
@jpk73 Your code works perfectly. Thanks for your efforts, appreciated. I was able to set up the two Muses chips as MusesL and MusesR with addresses 0 and 1. Code compiled fine.
I did not have a lot of time to test but initial results look like the Waveshare is - as @Skylar88 said - quite adamant about wanting to be on 23/18 and 15 as latch. It would come up with all three devices (the display and two Muses chips) but there appear to be conflicts. I will go back at it later in the week but it doesnt look like all three devices can co-exist on the same latch pin - as @Skylar88 said. Thanks again for your code.
I did not have a lot of time to test but initial results look like the Waveshare is - as @Skylar88 said - quite adamant about wanting to be on 23/18 and 15 as latch. It would come up with all three devices (the display and two Muses chips) but there appear to be conflicts. I will go back at it later in the week but it doesnt look like all three devices can co-exist on the same latch pin - as @Skylar88 said. Thanks again for your code.
Yes, agreed. The ESP32 has two usable hardware SPI buses as you know, so now that the ‘all on one bus’ approach has been sort-of investigated I thought I’d next try putting the display on the VSPI bus and the two Muses chips on the HSPI bus. The software SPI is also an option as you suggest and certainly worth trying as well - are you saying the software implementation is quieter?
Your point about the possible sound quality advantage of separating the display did occur to me. Although it also occurred to me that sound quality isn’t really an issue when you’re changing the volume - which is the only time the SPI bus for the Muses will be active. Bit like wondering whether you really need an isolator on that same Muses bus for the brief time the volume is changed - you’re not listening critically when you change volume. But this is diy so why not….
Your point about the possible sound quality advantage of separating the display did occur to me. Although it also occurred to me that sound quality isn’t really an issue when you’re changing the volume - which is the only time the SPI bus for the Muses will be active. Bit like wondering whether you really need an isolator on that same Muses bus for the brief time the volume is changed - you’re not listening critically when you change volume. But this is diy so why not….