i2s DeviceModeTXRX on pi zero 1

[marchingband]

I would like to use WM8960 with a pi zero 1, I have them all hooked up on a breadboard on my desk, but,
i see here it says not supported, for input and output at the same time.
Do I need to create separate input and output devices?
Or is it just fully impossible currently?
thank you!

[marchingband]

I am testing it with DeviceModeTXOnly
It is not clear to me how to format the written data.
I am generating an s32, checking that it is in range, and writing it to the u32 *pBuffer buffer in GetChunk, left and right alternating.

The result is that GetChunk only gets called twice, which I am interpreting to mean that I am not writing to the buffer correctly.

m_pSound->IsActive() is returning true ... and no errors coming up, everything initialized right, and i2c seems to be working.

This same approach worked well when I was using the PWM output, but using s16 instead of s32.
Any insights?

[marchingband]

Here is where I'm at: https://github.com/marchingband/wm8960-circle-tests

[rsta2]

DeviceModeTXRX should work on the RPi Zero (1). This "Not supported" comment is for the RPi 5 with RP1 chip, where it is not working. The driver is using 24-bits signed I2S data. Each sample occupies a 32-bit word. The highest byte should be 0. Be sure to return the same value from GetChunk() as it receives via the nChunkSize parameter. Otherwise the process stops.

[marchingband]

"Not supported" comment is for the RPi 5 with RP1 chip.

Ah man thank you.

The driver is using 24-bits signed I2S data

Reading this, of course C doesn't have s24, does this look correct? Is there a circle utility to create these ints?

uint32_t tos24(int32_t in){
    bool neg = in < 0;
    in &= 0x7FFFFF;
    if(neg){
        in |= 0x800000;
    }
    return in;
}

[rsta2]

You are welcome. When you have 32 bits integer (int32_t, int, s32), you only need to shift it right by 8 bits to get a value, which can be written into the GetChunk() buffer for I2S: uint32_t tos24(int32_t in){ return (uint32_t) in >> 8; }

[marchingband]

Great thank you.
I found that CI2SSoundBaseDevice::ControllerFactory has a bug where it thinks it has found PCM512x.
I modified the source file to look like this

boolean CI2SSoundBaseDevice::ControllerFactory (void)
{
	if (!m_pI2CMaster)
	{
		return TRUE;
	}

	// PCM512x
	// m_pController = new CPCM512xSoundController (m_pI2CMaster, m_ucI2CAddress);
	// assert (m_pController);

	// if (m_pController->Probe ())
	// {
	// 	return TRUE;
	// }

	// delete m_pController;
	// m_pController = nullptr;

	// WM8960
	m_pController = new CWM8960SoundController (m_pI2CMaster, m_ucI2CAddress,
						    m_nSampleRate,
						    m_DeviceMode != DeviceModeRXOnly,
						    m_DeviceMode != DeviceModeTXOnly);
	assert (m_pController);

	if (m_pController->Probe ())
	{
		return TRUE;
	}

	delete m_pController;
	m_pController = nullptr;

	return !m_ucI2CAddress;		// PCM5102A does not need a controller
}

and reran ./makall
And now my program works.
Would you like me to open a proper issue?
I really appreciate the support, thanks so much.

[marchingband]

Or am I missing a flag somewhere, or something like that?

[rsta2]

Do you have another I2C device connected with I2C address 0x4C or 0x4D by any chance? Otherwise this shouldn't happen. You can also explicitly provide the I2C address of the WM8960 (0x1A) to the constructor of CI2CSoundBaseDevice, if automatic probing fails. Can you please try this?

[marchingband]

Nothing else is connected, and I am passing the address to the constructor already.

I also retested by uncommenting the code and running makeall, and again it breaks for me.

[rsta2]

Nothing else is connected, and I am passing the address to the constructor already.

Ah, that's the difference. There seems to be a problem when the I2C address is specified. The driver cannot distinguish between PCM512x and WM8960, when the I2C address of the WM8960 is passed. I will try to fix this. Can you please pass zero as I2C address for now. This enables auto-probing, which should work, when the WM8960 is at I2C address 0x1A.

[marchingband]

I have updated the repo incase you want to inspect https://github.com/marchingband/wm8960-circle-tests

[marchingband]

I am new to C++ (I am a C developer) so it is totally possible that I am doing something dumb.

[rsta2]

No, it wasn't your mistake.

[rsta2]

The problem has been fixed on the develop branch.

[marchingband]

awesome, thank you so much!
My next step is going to be to switch to WM8988.
I don't see an obvious way to add a new driver.
Do you have any guidance on this, and would you like me to PR my driver back into circle when it is done?
WM8988 is a lot cheaper, as it doesn't have the amplifiers, just line level.

[marchingband]

I'm not 100% sure that i2c address is the right level of abstraction for the factory. Many popular DACs like pcm510x do not have any i2c at all, for example. Would an enum work better? The developer will typically know what DAC they have connected ... or maybe I am missing something.

[rsta2]

According to the datasheet (pg. 43) the WM8988 can use the I2C address 0x34 or 0x36. This is different from all other I2C addresses for the supported I2S codecs. The PCM510x is used, when there is no other chip found.

It' important to have an auto-probing method for I2S codecs, because existing applications do not care about the connected codec. Normally you don't have to specify the I2S address. The driver has to figure out by, which codec it uses. No, the developer does not always know, which codec is used. For example my MiniSynth Pi has no way to configure the I2S codec without re-compiling.

[marchingband]

I see. Unfortunately I think 0x34 is 0x1A shifted, 0x1A being the 7bit address ... I could be wrong.

[marchingband]

There is a possibility that the same init commands will work, maybe this codec will just ignore the extras? why don't I wait and see, before worrying you with this.

[rsta2]

No problem.