[Resolved] Attaching PCM5102 to Omega2 (I2S)

sza2 sza2

Actually, I did not apply all the patches. I modified some files manually as the patching was failed (probably the delta was to big to successfully apply - I did not spend so much time to figure out why).

I cloned the repo first last week commit 78057457912170ceba29792ef02ba441abe8f246 and I did a lot of tinkering, I don't remember the several config changes I made.

So yesterday I cloned again (cb2a3911e15df3be15126fc17fabe6f3671eee7b) to have a fresh copy and I did the following:

added MAX98357A related stuff to target/linux/ramips/modules.mk (based on your patch)
added target/linux/ramips/patches-4.4/0722-asoc-enable-max98357a-kconfig.patch
(well, I'm not a kernel guru, so I don't understand why it is necessary to replace tristate with tristate "Maxim MAX98357A CODEC" in Kconfig but the compilation stopped with errors if I did not apply this)
added lines to OMEGA2.dtsi based on your patches (my current OMEGA2.dtsi) - modifications in mt7628an.dtsi was not necessary

The result of the above was a kernel which supports MAX98357A (thus PCM5102 too).

Hope this helps.

/sza2

PS: I like Saleae - however I ran into trouble due to its limitation that no continuous sampling to disk, but the maximum is the free RAM size. Although the support was good, they offer a full refund of price of the two Logic Pro 16 - well, we chose not to send back but use for other tasks

luz

@sza2-sza2 it works now!!

Thanks a lot for the detailed steps!

I was using lede-17.01 before, which is still on kernel 4.4 and had the problem with DMA that made it either crash or (with my attempt to fix it with 942-omega2-dma-bughunt-WIP) not transfer data to the output.

Apparently, some work and bugfixes for the mt76xx SoCs got upstreamed into Linux mainline between 4.4 and 4.9. At least, the DMA related LEDE patch target/linux/generic/patches-4.4/132-mips_inline_dma_ops.patch that contains the code which was causing the crash, has disappeared in LEDE master.

Anyway - i2s sound output with max98357a works now, with less patching than before! Great!

But no advance without new problems - with kernel 4.9 the PWM support (/sys/class/pwm/)… does not work any more, because it tries and fails to claim gpio18 for some unknown reason, which is already claimed by something else, for another unknown reason

sza2 sza2

@luz Hi,

Glad to hear that I2S works - bad, that something else broken Currently, I don't plan to use any PWM stuff - but as a newbie I still struggling even with simple GPIOs (it works with official v0.1.9-b159 - so I'm almost sure it is a kernel configuration difference or some user space mistake I made).

/sza2

Xplatforms

Hi @luz & @sza2-sza2 have you already tested the quality of sound through i2s on Omega? How is it? Is it worth the fort of compiling custom fw, or it is better to use simple USB-SoundCards?
Can someone of you please share fw image with working i2s for omega2 or omega2p?

luz

@Xplatforms I haven't really tested it, because in my application it's for game sounds (more beeping than music) and connected to a very tiny loudspeaker of limited quality.

But I see no reason why the sound should be inferior to USB soundcards. i2s as such is lossless, it only depends on the output chip and its specs. I am using the MAX98357A, a really tiny (3x3mm housing) class D mono amplifier chip designed for phone and tablet speakers, and I'd say my setup sounds like a phone.

On the contrary, USB sound is much more complicated and probably also needs more CPU time from the Omega2.

Xplatforms

@luz I'm asking because of that comment from onion admins:
in this topic: https://community.onion.io/topic/287/solved-i2s-pins-on-omega/5

Can you share your image for test purpose please?

luz

@Xplatforms said in [Resolved] Attaching PCM5102 to Omega2 (I2S):

@luz I'm asking because of that comment from onion admins:
in this topic: https://community.onion.io/topic/287/solved-i2s-pins-on-omega/5

I see. No idea why Boken came to that conclusion - but then, that was two years ago with the Omega1/AR9331. Could well be that ASoC (ALSA for SoCs) wasn't ready back then. After all, ASoC for the MT7688 started working apparently only with a kernel newer than 4.4.

Can you share your image for test purpose please?

The image is highly customized for the application (the "pixelboard" - tetris/game-of-life lounge table)), so it might be a bit difficult to use, but here's the image where aplay works via MAX98357A. You might need to enter "failsafe" mode and edit out the "*" in /etc/shadow for the root user to be able to login.

sza2 sza2

@Xplatforms Hi,

First of all, I not an audiophile guy. Although my experience with the DAC mentioned in the topic title is pretty good - at least to my ears. You can also take a look at the sine wave I captured, there's no distortion, no noticeable noise on it, that's a quite good waveform.

I've tested the channels by a 20W class-D amplifier (TPA3100 based), and it was good too. Obviously, the analog part is sensitive to the digital noise generated by the Omega2.

Regarding the USB sound cards, there are huge differences between specific models. Years ago, I bought one for ~2USD but its sound is terrible (I've tested it with the same Omega2 HW a few month ago - that's why I decided to find some way to use the I2S DAC).

On the other hand, I heard the sound of a so called Hi-Fi USB sound card and that was rather like my I2S HW (I cannot decide whether it was better or worse, but about the same quality).

I cannot say anything about the resource side, I assume @luz is right.

/sza2

Xplatforms

@luz , @sza2-sza2 thank you very much for your answers and sharing image! I'll try it today

Gavin Guo

@luz I think the gpio18 is used for the max98357a at the dts file,

sdmode-gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;

you can remove that pin config, and try.

luz

JFYI: I2S support has landed in official Omega2 FW: https://community.onion.io/post/16473

Andrew Naumenko

I rechecked all the parameters of the i2s signal from omega2 and found the problem. i2s signal from omega 2 leaves really 16 bits per channel, but by default the data type is unsigned (u16). In the standard, I2S signal must be signed, and because of this, I have distortions with overload for TDA1543. At tests with MAX98357 these problems did not arise (probably) because it understands 16 24 and 32 bits, because of what the bit of the sign is shifted. When I try to reproduce the sign type of the signal (for example "mpg123 -e s16 test.mp3"), omega 2 is restarting.

sonus

@Andrew-Naumenko and others
I also get 99% distorded audio with my quality i2s dac that should get proper I2S (i2s = philips format with data 1 bitclock delayed left justified ) to play correctly . You probably found the culprit with the unsigned (u16) subject (corrected by the maxim ic) ? Hope people can help us get normal i2s (philips I2S) (for the most of users) stock driver config in the coming days/weeks. personnaly I do not want to get that maxim MX integratedampchip (when there are many more interesting i2s dacs and amps available everywhere) to fix when I already have better here. thanks for the future helpers

luz

@sonus: In ASoC (which is a subproject of ALSA, the Advanced Linux Sound Architecture), there are a lot of codecs (driver kernel modules) for various sound chips. The MAX98090 module obviously is made for that chip, and not others with different features.

For the Linux 4.4 kernel currently in use for LEDE 17.01 on which Onion's firmware is based, the available ASoC codecs are in the sound/soc/codecs subdirectory of the 4.4 kernel tree.

Of all these codecs, the current Onion build includes only those for WM8960 and MAX98090 (you can see that in the definition of sound-mt7620 which is in target/linux/ramips/modules.mk in Onion's LEDE source tree.)

You can see the changes @Lazar-Demin made to add the MAX98090 in his commit here (only the WM8960 was included in original LEDE 17.01)

Further up in this thread you can read about how I added the MAX98357A for my own use, and got it to work thanks to help from @sza2-sza2.

Probably, many of the other Linux 4.4 ASoC codecs would work with the MT7688's i2s hardware too, but one has to try to find out.

However, for the TDA1543, I see no SoC codec yet, neither in the 4.4 tree nor in the latest 4.17 tree...

Probably it would be doable to make a codec - have a look at max98357a.c, it consists mostly of config parameter tables, and almost no code. The hard part is probably learning to understand what these parameters mean

sonus

@luz the tda1543 and most DAC chips on the market (simply are operating following i2s signal lines) and as such do not need any driver except the most simple one implementing correct standart i2s (pcm5102 driver should match). I mean it does not need any other options like i2c spi (like volume control etc) etc thus only need the proper i2s pins and simple driver. it is same as pcm5102 etc regarding that : plain i2s only (pcm5102 is i2s left justified or i2s philips which are nearly the same at least one or another will not give any distortion) . thanks : I know and value the fact the new firmware audio inherits from this thread. except the core alsa i2s driver or asoc plain i2s driver, any i2s dac does not need any additionnal driver code to work when the problem will be corrected the new driver would fit nearly ALL the i2s and leftjustified audio dacs.

sonus

@luz
hi I understand most what is inside the MAX audio driver it is just I do not know how to mod my current firmware omega to put in the feature that would make it suiting all standart i2s dacs scenario.

Andrew Naumenko

@luz tda1543 does not require management (i2c or spi). It only needs a standard I2S interface with 16 bits with a 1 bit offset. The max98357 chip is too versatile and can understand many formats, but as I said earlier, the problem lies in the unsigned format of the output data. TDA1543 understands the range -32,768 to 32,767, and the omega2 yields 0 to 65,535.
Can you explain in more detail, how I can rebuild the system for making any changes?
Thks!

luz

@Andrew-Naumenko @sonus yes, the "driver" for these simple chips does not need any code, or at least almost none. However, it must describe the chip to the ALSA/ASoC subsystem, exactly because it needs to know if sound samples sent out via i2s should be signed or unsigned (furthermore, there is big endian and little endian byte orders, and possibly other details). Then ASoC can produce the correct type of samples.

That's the theory. Looking at what we have, I'm getting confused. For one both the MAX98090 codec as well as my MAX98357A codec claim support for signed samples (SNDRV_PCM_FMTBIT_S16) in their snd_soc_dai_driver structs. So IMHO with both codecs, I'd expect the samples coming out signed, and should fit the TDA1543.

I have no idea why this is not the case. But I suspect that there might be things missing or wrong in the whole setup, because for example, aplay --dump-hw-params is supposed to list the available formats, but at least on my omega, it just hangs forever. And further up in the thread @Andrew-Naumenko said forcing U16 samples with mpg123 just crashes the Omega. Also, poking around in /proc/asound/card0 leads to many files that just return the string closed. Again, no idea if this is ok or not, but it looks a bit strange.

ALSA is complex, and ASoC is relatively new (and we're using kernel 4.4, while 4.18 is current), and we're probably the first few trying this with the MT7688 at all - many chances for bugs here and there. I'm no way an ASoC expert, and also don't have the time to get one anytime soon. I just tried until my MAX98357A produced sound (from hxcmodplayer), and shared the procedure (see above).

In general, my hope is that when the next OpenWrt release uses a newer kernel, we'll maybe see things working that don't work now.

As for building your own kernel modules - @Maximilian-Gerhardt has created an excellent and detailed tutorial for that, here.

sonus

Hi all,
I am inquiring about a maximum digital out volume level creating the distortion (overdrive) as the possible problem cause. amixer and alsamixer being provided I used them to see and reduce all playback devices I could find just to try easy fixes and inquiring tools. amixer itself verbose playing : aplay -v -D hw:0 -f cd /dev/zero seems to send data rawinterleaved S16LE as we need but as of now I had not the opportunity to test a small .wav so as to hear result so if anyone is interested please do test this command playing a wav file : aplay xxfile.wav -v -D hw:0 -f cd
is there any volume control register in MT7688 I don't think ? MUCH unfortunately -g parameter is not featured anymore in mpg123 which would have been heaven... note though that the key press of - and prolonged pressing reduces volume gradually (on other than omega2 devices) so if any has a trick to : there is still some volume command in mpg123.
actually I do not know if is only a overvolume distortion problem or if it also is a problem of unsigned format which should be signed...
to help answer that question installing a mpg321 package could provide to the ones's interested the software volume control (gain) as it seems to offer (and better fixedpoint processing efficiency).
thanks

sonus

@luz
Hi do you know any quite simple way so as to use a 24bit data out i2s driver (seems that the a max... .c offer that mode : s24) : using any recent omega2 firmware (mainly your works) but getting that option mode to activate s24 instead of 16bit data format ?
stream_name = "HiFi Playback",
SNDRV_PCM_FMTBIT_S24
SNDRV_PCM_FMTBIT_S32,

thanks a lot for all