MilkV Duo external I2S input

Duo
1

I’m working to add external I2S input to the MilkV Duo. This is a continuation of work that was started over on this topic:

It appears that I’ve got input working and the source is in my own fork of the SDK V2 here:

This builds on the MAX98357A output driver that we got working last year by adding a new ALSA hardware card for the WM8782. Note that it’s not necessary to actually have a WM8782 connected - any device that can generate I2S data in signed 16 or 24-bit LE format should work. It’s also still necessary to use the ‘ethpoke’ application in my duo-examples repository to configure the I/O muxes:

At this time I’m still testing and cleaning up code so there may be additional changes as I progress, but things are hopeful.

1 Like
2

More info as I continue testing:

I’ve been finding ways to simplify the amount of code required for external I2S - using the ‘simple-card’ driver eliminates the need for the ‘cv1835_max98357a’ driver and ‘cv1835_wm8782’ and the subsequent changes to the sound/soc/cvitek Makefile and Kconfig. However, despite the fact that the new I2S input driver appears in the ‘arecord -l’ device list and recording from it appears to proceed correctly, generating expected messages in syslog and an output file, the actual external I2S pins are not active. There must be further things required. I’m continuing to debug…

2 Likes
3

I’ve discovered why the input I2S device doesn’t appear to be connected to the external I2S pins - there are a set of muxes that are configured to route the various devices to the pins and the settings chosen for the muxes assume that I2S1 pins would be used, but we’re using the I2S2 pins. The driver code can be changed to prioritize I2S2 and this will help during concurrent operation, however it will mean that only concurrent operation of I2S1 and I2S2 will work since one of them will have to operate in ‘secondary’ mode, taking its clocks from the other which means it cannot operate alone without on-the-fly reconfiguration which the normal driver operation doesn’t allow. I’ll be giving that a try shortly…

2 Likes
4

Have you successfully installed tinyalsa based on sdk2?

1 Like
5

SDK V2 appears to have ALSA installed - I’ve not had to make any changes to the buildroot configuration and aplay, arecord & alsamixer are all available.

1 Like
6

Further progress. I studied the AIAO mux settings in cv1835_i2s_subsys.c and discovered that they were configured to use the I2S1 I/O pins which aren’t fully available on the Duo board. I revised the settings to use the I2S2 pins on the ethernet connector and now I2S input is working. The main problem with the older settings was that they didn’t hook up the connections between the master and slave ports of the internal channels correctly.

As noted earlier, there is a caveat - the input channel is operating as a slave to the output channel, so it only works concurrently. You cannot do I2S input only - the output channel must be running otherwise the input channel will get I/O errors. That’s fine for my application, but may cause issues for if you’re not aware of the limitation. Output only does work though, and that’s a more common use-case.

I’ve stripped out all the extraneous modifications leading up to this point and checked in the minimal changes to my github fork of SDK V2. I’m now using the ‘simple-audio-card’ linkage driver and the spdif tx/rx codec targets for generic I2S which greatly reduced the amount of code needed. Now the most critical changes are in the DTS file defining how the existing kernel drivers are hooked up.

1 Like
7

Dug back into the past and applied the u-boot board.c modifications suggested by @dnech to my SDK V2 external I2S branch and it works. I added in the GPIO muxing changes as well since I found those necessary in my ethpoke userspace application. With this change ethpoke is no longer needed and audio operations will work immediately after bootup.

2 Likes
8

Hi emeb

Have you tried transplanting max98357a on sdk2? Can it be played successfully?

1 Like
9

Yes - that was the first thing I did in this thread. It worked just fine. Since then I’ve made significant changes to the way the external I2S is enabled and gone to a more generic codec driver that should still work with the max98357a while also allowing I2S input if desired.

Note that while the drivers I’m using now don’t specifically mention the max98357a, they still output I2S audio in a form that the max98357a can use and require no new C code - just device tree changes. The only C code required in my current branch were modest additions to existing files to get the I2S2 output pins working properly.

1 Like