Am 23.05.2019 um 21:34 schrieb aTc atc@k-n-p.org:
On 5/23/19 7:26 PM, H. Nikolaus Schaller wrote:
I just took some minutes (well more) and installed letux-4.19.44 on the 2GB Pyra. And for me, sound works!
Same here, although it's a letux image with the 4.19.0 kernel.
Ah, fine. I got the impression that nothing is working which made me wonder what is going on.
Well, not optimal , but it works. When playing an MP3 I get noise after ca. 10 seconds. But before that, music is crisp and loud and volumed damon works as expected. This was better with some older kernel, so it is a pure software issue.
I've been playing 4 channel wav files through aplay, sounds is great through both the speakers and headphone output.
Fine!
I did have to disable the volumed, with it enabled the volume levels of the channels move about all over the place.
The values the volumed reads from the wheel seem to fluctuate wildly : adding an echo $WHEEL to the volumed script gives : 852 412 372 667 389 312 922 757 581 410 636 469 957 559 650 895 935 315 854 395 1183 356 639 738 326 467 (the average value does change when moving the wheel, so it's not reading some other device)
Yes, I have observed that as well - on all recent prototypes and not on the older ones. This indicates a hardware issue which did creep into the last production run.
That is Issue #1
Also, setting the handsfree volume above 40 causes lots of distortion in the speakers. Setting it to levels around 70 causes white noise to appear sometimes, which doesn't go away when lowering the volume. It does sometimes dissapear again when setting the volume higher, At which point it stays away when lowering the volume.
Yes, that are the same symptoms as I observe. It did work well with older kernels so there is something changed either in the PCM drivers or elsewhere. Tony or Peter (don't remember who) mentioned that there is something with idle states. AFAIR there was a patch for McBSP but not for McPCM (but I may be wrong in this point).
Technically this would mean that the PCM data from OMAP to TWL6040 is not reliable and is loosing bits or frame synchronization (PCM is a serial data protocol). This would bit-shift data in the .wav so that the D/A converters create white noise.
This is Issue #2
The right speakers doesn't seem to be making proper contact with the pads, and requires some pressure on the case before it'll make any sound.
Getting the same to work on PyraOS shouldn't be too difficult, although the main problem there is that Mate wants to use pulseaudio, which tries probing the nonexisting subdevices, and locks up the entire mate settings daemon. (or it's the setting daemon itself that probes them)
That is a separate issue that the AESS/ABE integration patches do not properly work and creates these broken sound card channels.
This is Issue #3
Maybe what you could do is to git revert the AESS/ABE patches from the letux tree?
Something like:
git checkout letux-4.19.44
git log --oneline v5.2-rc1..letux/aess-v2 | tail -u | while read COMMIT TITLE do HASH=$(git log --oneline -grep "$TITLE") git revert $HASH done
The key issue to solve is that the patch set has been rebased to v5.2 in the mean time.
An alternative could be
git checkout letux/aess-v2 git revert v5.2.rc1..letux/aess-v2 git checkout letux-4.19.44 git cherry-pick $reverts from above
Or a simple brute force approach
git checkout letux-4.19.44 git checkout v4.19.44 -- sound/soc/ti/ arch/arm/mach-omap2/omap_hwmod_54xx_data.c
This should wipe out all sound specific Letux patches and leave mainline
I think a simple alsa config can split 4 channel devices into 2 stereo ones, or copy the first two channels to the second pair. pulseaudio can probably handle that as well.
I had searched (certainly not exhaustive) for such an ALSA feature but did not succeed. Hence the approach to use sox/play and remix the channels.
So in total we have a mix of 3 separate issues. I was aware of two of them. The Issue #1 is new to me.