[Letux-kernel] [PATCH 0/8] Get sound playback working on the Pandora again

Grond grond66 at riseup.net
Mon Jan 10 17:19:29 CET 2022


On Sat, Jan 08, 2022 at 05:30:31PM +0100, Stefan Leichter wrote:
> Hello Grond,
> 
> On 07.01.22 23:01, Grond wrote:
> > On Fri, Jan 07, 2022 at 09:17:50PM +0100, Stefan Leichter wrote:
> > > Hi Grond,
> > > 
> > > On 07.01.22 18:28, Grond wrote:
> > > > Hey Stephan.
> > > > 
> > > > I'm pretty sure I know what's causing at least one of the problems.
> > > > 
> > > > On Fri, Jan 07, 2022 at 05:50:34PM +0100, Stefan Leichter wrote:
> > > > > Hello Grond,
> > > > > 
> > > > > a late happy new year and thank you for your work.
> > > > > 
> > > > > On 31.12.21 01:41, Grond wrote:
> > > > > > Note that these changes only fix playback. Recording sound does not
> > > > > > currently work for as yet unknown reasons. However, given the (mind
> > > > > > boggling) number of ALSA kcontrols exposed by the TWL4030's sound
> > > > > > capture codec, it is likely that there is just a switch that is turned
> > > > > > off somewhere.
> > > > > 
> > > > > Today I tried on my 1GHz pandora the new kernel from hns (5.16.0-rc8-letux+) with includes you patches. Did you notice in /var/log/syslog or dmesg output the line:
> > > > > 
> > > > > [   17.557952] omap3pandora-sound omap3pandora-sound: Failed to register sound card: -517
> > > > > 
> > > > 
> > > > -517 is -EPROBE_DEFER. As Nicolaus pointed out, it just means that the
> > > > first attempt to probe the driver failed because one of the components
> > > > it depends on wasn't probed yet. However, this should not be considered
> > > > a good reason to use dev_err (since it's expected behaviour). Perhaps I
> > > > should modify the patch series?
> > > > 
> > > > > This can be the reason for the not working audio input. If you change in soc-core.c line 858 from dev_dbg to dev_err you will see the problem in dmesg:
> > > > > 
> > > > > [   17.246490] omap3pandora-sound omap3pandora-sound: ASoC: codec component pcm1773-codec not found for link PCM1773
> > > > > 
> > > > > One thing was driving me mad. When I login only via ssh aplay -l doesn't show any audio devices. After login on the pandora keyboard the playback device (pcm1773-hifi-0) appears and is usable.
> > > > 
> > > > I have no good explanation for this. Generally speaking, what is the
> > > > timing for you logging in via SSH versus the keyboard? If SSH is always
> > > > earlier, it may simply be the driver taking a while to load (but I
> > > > cannot imagine why that would be).
> > > 
> > > Not exactly sure what you mean with timing, but let me try to explain what I did now:
> > > 
> > > The pandora was started at 20:50. Booting to the console prompt takes about 35 seconds. At 20:55 login via ssh, check for the loaded modules, run aplay, login on the console, second aplay:
> > > 
> > > letux at letux:~$ lsmod | grep -e pandora -e pcm ; aplay -l ; date
> > > snd_soc_pcm1773        16384  1
> > > pandora_bl             16384  0
> > > snd_soc_omap3pandora    16384  0
> > > pandora_nub            20480  0
> > > aplay: device_list:270: no soundcards found...
> > > Fri Jan  7 20:55:32 UTC 2022
> > > letux at letux:~$ aplay -l ; date
> > > **** List of PLAYBACK Hardware Devices ****
> > > card 0: omap3pandora [omap3pandora], device 0: HiFi Out pcm1773-hifi-0 [HiFi Out pcm1773-hifi-0]
> > >    Subdevices: 1/1
> > >    Subdevice #0: subdevice #0
> > > Fri Jan  7 20:55:50 UTC 2022
> > > letux at letux:~$
> > > 
> > > I can wait longer between the startup an the ssh login, just suggest a duration.
> > > 
> > > If I first login at the console the playback device will appear directly at the first aplay call after the login, even if I did not wait for five minutes after starting the pandora.
> > The reason I mention that it might be a timing issue is that the console
> > login is not very well-coupled to the audio driver stack. It seems
> > really unlikely that logging in on the console actually *causes* sound
> > card probe to succeed. But I would be really interested to see what
> > dmesg looks like after the sound card probe has succeeded. Also, if you
> > could try compiling a kernel with DYNAMIC_DEBUG enabled, you can see all
> > of the ASoC core debug messages, which I've found is really helpful in
> > running down the root cause of why the sound card driver isn't loading.
> > (I would suggest adding dyndbg="file sound/* +fp" to the kernel command
> > line as well.)
> > 
> I don't see anything new in the dmesg output after the console login.
> 
> Please find the log of the ssh session (including dmesg output) attached
> 
> Regards
> Stefan

I really don't understand how this is possible. The dmesg that you sent
makes it quite clear that the sound card has been probed (and therefore
registered with the ALSA core) before the WL1251 wifi driver has been
initialized. Therefore, it should be impossible for you to log in via
SSH to observe *any* state where the playback stream has not been set
up. I'm completely mystified. And without access to a 1GHz unit on which
to perform tests, I don't really know how to debug this.


More information about the Letux-kernel mailing list