Is the .program i2s_out_master correct?

[bschwind]

For reference, I'm trying out this PIO program in a Rust project (not using any of the associated C code in this repo). I'm outputting to a PCM5102A

The code in question

.side_set 2

public entry_point:
                    ;        /--- LRCLK
                    ;        |/-- BCLK
frameL:             ;        ||
    set x, 30         side 0b00 ; start of Left frame
    pull noblock      side 0b01 ; One clock after edge change with no data
dataL:
    out pins, 1       side 0b00
    jmp x-- dataL     side 0b01

frameR:
    set x, 30         side 0b10
    pull noblock      side 0b11 ; One clock after edge change with no data
dataR:
    out pins, 1       side 0b10
    jmp x-- dataR     side 0b11

I'm wondering if this program is only outputting 31 bits of data per frame instead of 32.

At the very start of the program, x is assigned to 30, and then we essentially enter a loop, decrementing x until it's 0.

The jmp x-- dataL instruction jumps to dataL if x is non-zero before the decrement.

So if x were 1 at the start, it would output a bit, then the jmp instruction would bring you back to the output instruction one more time for a total of 2 bits being output.

If x is then 30, I would guess this loop then outputs only 31 bits here.

I'm relatively new to PIO programming though, so there might be a detail somewhere that I'm missing.

[malacalypse]

Have you put it on an oscilloscope and watched what it does?

32 clocks are sent per frame channel (the pull noblock leaves the 31st bit on the output line and toggles the clock, which doesn't matter since the codec isn't using the LSBs for anything meaningful anyway).

Here's a schematic from TI showing the I2S protocol in detail:

(From https://e2e.ti.com/support/audio-group/audio/f/audio-forum/452359/codec-tlv320aic3100-loopback)

Note that the bit sent after the frame clock changes is marked as having no meaning. This is because the frame is always intended to be bigger than the bit depth of the sample being sent. Also note that the data format indicated by the project is signed 32-bit integers. The MSB of this integer will be used by the codec. The LSBs will be truncated to the codec's resolution (this is inherent in I2S protocol).

So you're right that max 31 most-significant bits of the input DATA are sent, but 32 clocks are sent.

Changing 30 to 31 will send 32 bits of data in a 33 bit frame. That tends to make a lot of codecs grumpy (and they'll ignore the LSBs anyway), but nobody's stopping you from trying it.

[bschwind]

I looked at it on a logic analyzer. It correctly plays the output, though just out of curiosity I tried outputting just 0x1 values and received 0x0 on the logic analyzer, but fair enough because the LSB in a 32-bit audio sample isn't going to change anything even remotely perceptible.

This is the diagram I was referencing, when interfacing with the PCM5102A, which claims it accepts "32 bit audio data":

Entirely unrelated to this discussion, but I was curious what motivated the pull noblock vs. configuring autopull and having a nop where the pull noblock statements currently are. Maybe they're both equally valid solutions and one was simply chosen arbitrarily, but I'm interested to hear.

[malacalypse]

Right, as I mention the pull noblock doesn't update the output so it leaves the LSB-1 on the line for the clock cycle, that's the LSB 32-th bit in the 32-bit format you reference. So if you output 0x1 you'll get 0x0 on that bit, because the bit in position 1 is a 0, and it gets repeated. If you output 0x2, you should get 0x3, for instance. At least, that's what I think it does. It's been a while since I've messed with this code.

pull nobock vs autopull - autopull under some conditions got out of sync on me, and I didn't bother digging further into why as pull noblock worked fine, so I just left it. If you want to mess with it and use autopull, I wouldn't put a NOP there, I'd actually see if I could rearrange things to output that 32nd LSB. However, you'll have to rearrange things a little bit in that case or it won't get into the starting alignment properly. I'd do this not because that LSB matters but because it seems neater, and why use autopull if you can't maximize the neatness? ;)

[bschwind]

Thanks for your answers! I think I understand everything now, especially the point that although the very last LSB isn't output, there are 32 bit clock cycles in total per left/right side.

If you want to mess with it and use autopull, I wouldn't put a NOP there, I'd actually see if I could rearrange things to output that 32nd LSB. However, you'll have to rearrange things a little bit in that case or it won't get into the starting alignment properly

Makes sense! I attempted something to that effect here:

https://github.com/bschwind/super-sanic/blob/395a64b2522431e518b3ec3caa6365fc47898246/src/main.rs#L64-L76

Seems to work well so far, though I'm curious if I'll run into similar issues with autopull that you had.

[malacalypse]

Nice work! Let me know how stable it runs, that's a crisp little loop there. If it works reliably and gets the 32nd bit output correctly, I'd be willing to consider an MR against the repo here, if you're willing to help trim up the associated C code a bit too. I don't have much time / energy for this project at the moment, but I'm trying to keep it fresh and relevant as much as possible.

[bschwind]

Thanks! I'm currently away from home without access to any of my electronics so I'll have to get back to this in a few weeks. I'll test it more thoroughly when I'm home and report back on the stability here. Happy to submit a PR with associated C changes as well if we verify the stability and everything.

Thanks again for the discussion on this super cool little peripheral.