This deals with most of what #18 was trying to do (but better) except for supporting I2SOut objects on different pins. Would it make sense to allow, optionally, the I2SOut object to be passed in?

This deals with most of what #18 was trying to do (but better) except for supporting I2SOut objects on different pins.

Sorry for stepping on your toes a little bit. 😆

Would it make sense to allow, optionally, the I2SOut object to be passed in?

What if we did a check like:

if "I2S_BCLK" in dir(board):
    self._audio = ...

If the pin(s) isn't available, it'll just set self._audio = None. And then we can add @audio.setter to change it after initialization? It'll have to do some de-initialization if necessary, but that shouldn't be a problem.

The user code would look something like:

peripherals = adafruit_fruitjam.peripherals.Peripherals()
peripherals.audio = I2SOut(...)
peripherals.play_file(...)

As for the DAC, I could see us adding in an argument for the busio.I2S object, but I don't think it makes sense to pass the whole TLV320DAC3100 object. Alternatively, we could do a similar thing for a setter.

As for the DAC, I could see us adding in an argument for the busio.I2S object, but I don't think it makes sense to pass the whole TLV320DAC3100 object. Alternatively, we could do a similar thing for a setter.

I had noticed an application that used a different I2C bus to communicate with the TLV320 breakout board which is why I considered passing the DAC object. I'm not really even sure it wasn't just an alternate name for the board.I2C but it got me thinking that it was possible someone might wire up a different bus.

If we passed in the I2C object to be used though, then a different bus could be used. In addition, if there was an alternate DAC being used (the ES8311 also uses I2C 0x18 so it would be incorrectly identified as the TLV320) an invalid I2C bus or one that wasn't connected could be passed in to disable the TLV320 allowing it to be handled outside the library.

EDIT: 😁 I guess that's essentially your setter approach though....

This version of the library seems to be causing the boot animation (or perhaps more broadly initializing adafruit_fruitjam.peripherals.Peripherals?) to get stuck when it runs on a Fruit Jam device (tested on 10.0.beta-3).

I've started tracing to figure out where it is getting stalled but not managed to find the bottom of the rabbit hole yet. It seems like the DAC init never completes when using this version of the library edited to add a few print statements to check where it's at:

>>> import boot_animation
before
after
tlv320_present True
before fj periphs
dac_present True
before tlv init()
...  # never prints anything else even though there is a print after tlv init()

If we passed in the I2C object to be used though, then a different bus could be used. In addition, if there was an alternate DAC being used (the ES8311 also uses I2C 0x18 so it would be incorrectly identified as the TLV320) an invalid I2C bus or one that wasn't connected could be passed in to disable the TLV320 allowing it to be handled outside the library.

@RetiredWizard I've got the setters going and have the i2c bus parameter to disable initialization. I think that takes care of it, but for anything deeper, I may need a direct use-case with desired code examples, because it's starting to get over my head.

Thanks for the review, @RetiredWizard & @FoamyGuy! I think I've got this ready to go now, but please let me know if there are any additional changes that need to be made.