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.

[andreaco]

I just ordered a board for RPi5 that has 4 stereo ins and 4 stereo outs. I wanted to ask you if you had any insights on why the TXRX mode doesn't work on the RPi5 and if you had some plans for that!
Otherwise I will be happy to try to dig more and find a way for having that feature, in that case, any insights about that would be precious

[rsta2]

I guess this was to reduce complexity. There was a lot of work to be done for the RPi 5. There are currently no plans to add this by myself.

[andreaco]

Alright I understand! I'll explore this on my end once I receive the board and let you know if I manage to get some results
Thanks a lot for all the work done, such a nice (and mastodontic) project

[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.

[marchingband]

I have the WM8988 working now.
The i2c address is the same, but the initialization is quite different.
How can I best handle this situation?

[rsta2]

I would copy the files wm8960soundcontroller.[h|cpp] to wm8988soundcontroller. [h|cpp] in the respective directories and rename the classes in the new files to CWM8988SoundController. Then you can modify the class for the WM8988 as you like. You have to add the class CWM8988SoundController to the ControllerFactory() in i2ssoundbasedevice-rp1.cpp and i2ssoundbasedevice- rp1.cpp at last. In the method CWM8988SoundController::Probe() read a device register (e.g. R40), which has a different reset value for WM8960 and WM8988 and check that value. If it matches the reset value of the WM8988, the device is found and can be initialized. The same test should be added to the WM8960 driver.

[marchingband]

Ok that makes sense, thanks.