[Resolved] Attaching PCM5102 to Omega2 (I2S)
-
@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.
-
@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!
-
@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 theirsnd_soc_dai_driverstructs. 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-paramsis 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/card0leads to many files that just return the stringclosed. 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.
-
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
-
@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
-
Hi guys!
I'm all trying to figure out what's wrong with TDA1543. I got a few graphs to explain my problem. I uploaded a test mp3 file and run him mpg123 -f 256 -C -v sin1000.mp3 (-f 256 is amplitude). File mp3 - sine wave, frequency 1 kHz.The amplitude is varied from 128 to 1024 (128 is displayed in mpg123 as 0 and it is on level with the noise level of the chip itself)
Initially, I sinned on the error data types (U16 or S16) but now I think that the problem is in the data reading frequencies. Maybe someone will have an idea what's the problem?Now I'm trying to compile a kernel for omega with other codecs (how shown in this theme), but it's not working yet. If anyone has a ready-made kernel with other codecs, which I could immediately flash into the omega for tests, discard the download link. Thks!
-
I fiddled with the parameters of TDA1543 and got a normal sound. But it is so only when I set the playback volume in mpg123 to 2 percent. More and I get distortions, I will give another 2 oscillograms first - "mpg123 -f 128" second "mpg123 -f 256". Initially this is a saw with a single amplitude generated with the aid of audacity.
However, that sounds!
I also noticed an error, the line CLK does not turn off when the sound stops.
-
Hi all
Does anyone know if the current driver in use stock in omega2 use LeftJustified or the RightJ or the philips format i2s (one bitclock delayed) i2s format ?
also it is 16 bit data per channel and 32 bit total word bitclock I think : meaning we need to use either simple 16 bit only dacs or else very wide accepting comptability multi-formats allowing (extensive format input accepting) dacs.
still it is a nice evolution from some weeks ago when i2s/sound was not featured at all.In fact Andrew I suspect from your overdrive distortion and volume symptoms (without all checking the mt7688 doc and register) omega2 driver is probably left justified format when your dac tda1543 only strictly accept philips justified i2s (meaning 1 bck delayed msb left justified) . that would mean an error on your dac ms bit understanding. meaning it starts seemingly to correctly work only when volume is grossly reduced.
-
In this theme
Judging by this picture, the data format is 16 bits i2s
-
@Andrew-Naumenko
true I had seen it. from that picture it is sure it is 16 bits per channel i2s (into 32 bit bclk total sample) wordclock.
but the fact you need to turn down volume so much is all the more strange knowing that both your omega2 and tda dac are EXACTLY same philips i2s mode format (and both 16 bits only).
-
Hi all,
I´m also trying to get the MAX98357A running on a Linkit Smart 7688 with LEDE master branch (kernel 4.9). The previous manuals about configuring and patching helped me a lot - thanks for it.
Now I´m able to play a mp3-file with madplay and can hear the sound, but there is one issue.
After stopping the sound the loudspeaker gets hot, because of ~5V DC output.In the MAX datasheet is written "do not remove LRCLK while BCLK is present -> may cause a high DC output". This seems to be the case. In I2S mode the datasheet tells BLCK = "rising edge".
Am I wrong or is it needed to invert the BCLK signal for the MAX98357A in the simple-sound-card settings to get a I2S mode running properly?I tried to set bitclock-inversion in the simple card setup, but it returned with a ralink-i2s / ASoC issue "Failed to set DAI format -22".
Unfortunately, currently no oscilloscope available to measure it...
Thanks in advance for any hints from you...
-
Anyway, someone successed with plaing something with aplay on i2s(Lede 17.01 branch)?
