I2S Half Duplex Question

[A622266]

My audio application is half-duplex; I want to record and playback using one I2S port, but not at the same time. My preferred codec is ADAU1361. This device has one SCK (BCLK), one WS (LRCLK) and two SD (ADC_SDATA and DAC_SDATA). The device also requires an MCLK, which I will supply with a crystal.

I want to interface ADAU1361 to an ESP32. I think I can configure one ESP32 I2S port as an audio input, and configure the other as an output during playback. The same pins on ESP32 will be used for SCK and WS for record and playback, and will be connected to ADAU1361 BCLK and LRCLK, respectively. I will use different pins on the ESP32 for SD to connect to the ADAU1361 ADC_SDATA and DAC_SDATA pins.

Is this scheme feasible with the current Micropython I2S implementation for ESP32? I noted the limitations in the discussion here, but in that case, the user's application is full duplex.

[miketeachman]

I expect you'll have the same issue as described in the discussion #9243. I don't know of a way to synchronize the two I2S peripherals on the ESP32 (so that the WS clocks are synchronous). Perhaps there is an ESP-IDF setting that enables this, but I haven't seen it. Your easiest solution is to use two different I2S hardware devices, one for Tx, the other for Rx.

[robert-hh]

The structure of the ADAU1361 may look similar to the WM8960, but the a first glance into the data sheet reveals that the programming is completely different. So no, you can not use the WM8960 driver.

[A622266]

Thanks Robert. I was planning to write my own driver for ADAU1361, using WM8960 driver as an example. But @miketeachman is saying that my application may not work with ESP32. What I was asking is whether I could use WM8960 codec and driver instead of ADAU1361. If yes, I'd be interested to know what about WM8960 makes it possible that ADAU1361 lacks. Although there is only one sck on WM8960 like ADAU1361, I see that it does have a separate ws line for ADC and DAC. Does that make it possible to use with ESP32 for an application that requires record and playback, but not at the same time?

[robert-hh]

It's quite a while, and I have to get back to reread all the details. I have used the WM8960 for recording and playback with MIMXRT devices. But I never connected it to a ESP32 with I2S. I could try. I have an external breakout with the WM8960, but that one has the WS lines internally connected.

[A622266]

Thanks Robert. If you can try it, I would be very interested to know if it works. If the WS lines are connected, does it really have any advantage over ADAU1361? I prefer ADAU1361 since I already have it, and also it appears that WM8960 is discontinued.. Cirrus do recommend WM8962 as a replacement, however.

[robert-hh]

I'll test that. Playback of "Penny Lane" at 44100/Stereo worked. Recording is tomorrow.

[miketeachman]

Did you get the opportunity to read the answer section of the discussion https://github.com/orgs/micropython/discussions/9243?
I think that answer provides a detailed explanation on why you cannot use the same I2S hardware device for both Rx and Tx. https://github.com/orgs/micropython/discussions/9243#discussioncomment-3597153

[A622266]

Hi Mike -- Yes I did read it. But I thought the key aspect was that the user wanted to have record and playback at the same time on two different ports, and there would be no way to have sck and ws to be synchronous. Since in my case, I don't need both directions at the same time, I though I might get away defining the ports such that the same sck and ws pins would be used for audio in and audio out. A different pin would be used for data as required by the codec. I would just reconfigure the port according to the use case in my program, or declare I2S0 and I2S1 to have the same pins for sck and ws. You don't think that will work with the current Micropython port?

I did also start reading the Espressif manual for I2S. The hardware does appear to support full duplex operation (see about halfway down the page), similar to how the codec expects (with shared sck and ws). So perhaps that is a possibility for the future. Also interesting might be the TDM mode, to allow more than 2 channels on the same pins, which some codecs support (e.g. ADAU1361). I also noted the PDM modes would be an alternative to an I2S microphone, essentially saving a pin per stereo pair.

[miketeachman]

Sorry, I missed reading "but not at the same time" in the initial discussion. doh!. Yes, that should work with one I2S peripheral by calling the init() method to reconfigure the peripheral and the pins it uses.

Full duplex operation might be a possibility. I wonder how much demand there is for this enhancement?

I've thought about implementing a machine.PDM class for the various ports that offer the PDM mode. Both the M5stack and the TTGO T-Watch-2020 V3 have PDM microphones, so there might be enough demand for this new class.

[A622266]

I'm glad to hear that you think it should work to use a codec with a single I2S port for record and playback (half-duplex). I think Robert will confirm this tomorrow with his setup using WM8960.

Full duplex operation might be a possibility. I wonder how much demand there is for this enhancement?
Full duplex usually means a real-time communications application. Algorithms like double-talk detectors and acoustic echo-canceling are needed, which would limit the audience. Maybe there are some other less complex apps that I'm not thinking of?

I think PDM is useful -- there quite a few PDM microphones. Some have the sound port on the top, which can make them easier to work with in pcb assembly. Is there a top-port I2S microphone? I've only seen bottom-port with I2S. PDM also saves a pin, since you get two mics on the one data line with a double-data rate clock line. On the PDM output side, this can be used to create an analog output with an external filter-- and since the newer ESP32s don't include DACs, this is the only way that I see to get an analog output without using a lot of GPIOs.

I also think TDM is interesting. There are some mulit-channel codecs out there (more than two ADCs or DACs), and usually the only way to interface to them is TDM. This of course only makes sense if the uC is powerful enough to do something useful with all these channels, but probably if you let people push the envelope, they will come up with some very interesting ideas ..

[miketeachman]

Hi @miketeachman Revising my comment above on full duplex operation. I'm finding it quite limiting to not have this feature, as you can't effectively use audio codecs that have only one I2S port. In addition to real-time communication that I was thinking of above, the limitation also eliminates any analog-to-analog applications such as a smart microphone or speaker equalization. By analog-to-analog, I mean a signal that starts and ends in the analog domain, but in the middle we do some DSP processing (e.g. using ulab and micropython). These type of applications aren't possible with a typical audio codec (i.e. one bi-directional I2S port), without full duplex operation. Since it looks like the team are still taking inputs on a final I2S spec for micropython, this should be considered an important requirement.

Thanks for the update. It looks like Espressif started supporting full duplex I2S operation in ESP-IDF v5. I don't see it mentioned in any of the v4.x releases. Micropython doesn't yet support ESP-IDF v5, but when that comes it should be possible to extend the I2S interface to support full duplex operation, while keeping backwards compatibility with the existing interface.

[A622266]

Thanks. Do any processors have micropython support for full-duplex, such as pyboard d? Those are hard to get, but I would probably get one if it had the feature earlier.

[miketeachman]

None of the Micropython ports support full-duplex I2S at this time.

[A622266]

@miketeachman For uC that have two I2S ports, I wonder if it would work to tie sck and ws for both ports to the sck and ws pins of the codec. One of the uC I2S ports can transmit on an sd pin to the DACs of the codec, and the other uC I2S port can receive on a different sd pin from the ADCs of the codec. if it works, it would mimic full duplex operation, at the cost of two I2S port on the uC. Another limitation is that sample rate must be the same for both directions. I'll try to get this to work. Let me know if you think it just won't work!

[miketeachman]

Unfortunately it's not possible for the reason described here

[robert-hh]

As expected, recording works as well, tested with the built-in microphone of the breakout. Test-Setup of the WM8960:
Playback:

    from machine import I2C
    i2c=I2C(1, scl=Pin(19), sda=Pin(18))
    import wm8960
    wm=wm8960.WM8960(i2c, sample_rate=SAMPLE_RATE_IN_HZ,
        adc_sync=wm8960.SYNC_ADC,
        sysclk_source=wm8960.SYSCLK_PLL,
        mclk_freq=24_000_000)
    wm.volume(3, 90)

Recording:

    from machine import I2C
    i2c=I2C(1, scl=Pin(19), sda=Pin(18))
    import wm8960
    wm=wm8960.WM8960(i2c, sample_rate=SAMPLE_RATE_IN_HZ,
        adc_sync=wm8960.SYNC_ADC,
        mclk_freq=24_000_000,
        sysclk_source=wm8960.SYSCLK_PLL,
        left_input=wm8960.INPUT_MIC1,
        right_input=wm8960.INPUT_CLOSED)

With SAMPLE_RATE_IN_HZ set to the intended rate, like 44_100 or 32_000. The MCLK of the used Waveshare WM8960 breakout is fixed at 24MHz and cannot be supplied by the ESP32. It could only be fed from the breakout to the MCU.

[A622266]

Thanks very much for your test, Robert. And I can see on the breakout board that the bit clock and frame clock are tied together. In your code, do you use two I2S ports (id=0 and id=1), and they share the same pins for bit clock and frame clock? Or do you use one I2S port (id=0), and then just reinitialize it to use a different data pin during a change in use case (playback or record)?

[robert-hh]

For both test the IS2 id 0 was used with the different pins for the data line at the ESP32 side. Bit clock and frame clock are shared. During recording, I had a strange noise in the codec output, because besides maybe crosstalk no data was supplied.

[robert-hh]

We had as well tested the SGTL5000 codec as part of the MIMXRT port. The driver is here: https://github.com/rdagger/micropython-sgtl5000

[A622266]

Okay, thank you. I was thinking that I could configure the codec as I2S controller, and the ESP32S3 as I2S peripheral. I thought this may work, since the codec would provide the bit clock and the frame clock to both I2S ports of the ESP32S3, and since this configuration (codec I2S controller, ESP32 I2S peripheral) is supported according to the documentation of the codec and the ESP32S3. But I see now in the Micropython documentation, that the ESP32 can only be configured as an I2S controller. And I see your point on why the other way won't work (ESP32 I2S controller, codec I2S peripheral)

…

On Sun, Apr 2, 2023 at 10:03 PM Mike Teachman ***@***.***> wrote: Unfortunately it's not possible for the reason described here <#9243 (comment)> — Reply to this email directly, view it on GitHub <#9639 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGH5SSXEWEL2YBPEHWP2JILW7IVYBANCNFSM6AAAAAARGLJQ2E> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>