Audio Driver (with bounty!)


Did some first tests. The amixer settings work, but I still just get:
Code: 
root@letux:~# aplay -Dplughw:0,5 /usr/share/sounds/alsa/Front_Center.wav 
[17875.842864]  OMAP ABE Media LP: ASoC: no backend DAIs enabled for OMAP ABE Media LP
on channel 5. The others can not be opened. This means there is something wrong in the driver code...
 
hns said:
Did some first tests. The amixer settings work, but I still just get:
Code: 
root@letux:~# aplay -Dplughw:0,5 /usr/share/sounds/alsa/Front_Center.wav
[17875.842864]  OMAP ABE Media LP: ASoC: no backend DAIs enabled for OMAP ABE Media LP
on channel 5. The others can not be opened. This means there is something wrong in the driver code...
Click to expand...
Hm. The driver could still be ok: https://bugzilla.kernel.org/show_bug.cgi?id=195811#c3
Which means that audio routing is not set up properly for 'OMAP ABE Media LP'.
Here is a more OMAP5 specific discussion about a similar error message: https://e2e.ti.com/support/processo...c-no-backend-dais-enabled-for-omap-abe-media1 but no real solution.
I think I still have to learn a lot about the inner workings of ALSA and how to use it.
 
hns said:
Hm. The driver could still be ok: https://bugzilla.kernel.org/show_bug.cgi?id=195811#c3
Which means that audio routing is not set up properly for 'OMAP ABE Media LP'.
Here is a more OMAP5 specific discussion about a similar error message: https://e2e.ti.com/support/processo...c-no-backend-dais-enabled-for-omap-abe-media1 but no real solution.
I think I still have to learn a lot about the inner workings of ALSA and how to use it.
Click to expand...
I find that ST wiki have fairly good documentation of various aspects of the Linux kernel. For example, they have an article on audio configuration and troubleshooting: https://wiki.st.com/stm32mpu/wiki/ALSA_overview#How_to_trace_and_debug_the_framework

I'm sure I've seen a visualization tool somewhere for the audio routing, but I can't find it now!
 
@hns, I don't know if this will help you but I ran vizdapm on my devboard when playing audio running Linux-3.8.13.

This is for /sys/kernel/debug/asoc/PandaBoard5/dapm:
root.png


And this is for /sys/kernel/debug/asoc/PandaBoard5/twl6040-codec/dapm:
twl6040-codec.png


Unfortunately, I got kernel oops whenever I tried to read anything from /sys/kernel/debug/asoc/PandaBoard5/401f1000.aess/dapm. Figures... :mad:

I hope this can assist in figuring out the audio routing

EDIT:
With some careful manoeuvres of the delete key in the kernel sources I was able to run vizdapm in /sys/kernel/debug/asoc/PandaBoard5/401f1000.aess/dapm: :oops:
401f1000.aess.png
 
Last edited:
Cool!

I started the PandaES with the letux 6.2-rc6 kernel and found the required files /sys/kernel/debug/asoc/PandaBoardES/twl6040-codec/dapm and /sys/kernel/debug/asoc/PandaBoardES/401f1000.aess/dapm.

A wget for the script and an apt-get for the dot command helped me to get three PNG files :)

/sys/kernel/debug/asoc/PandaBoardES/dapm
out0.png


/sys/kernel/debug/asoc/PandaBoardES/twl6040-codec/dapm (seems to show the issue that the frontend DAIs are not properly initialized)
out2.png


/sys/kernel/debug/asoc/PandaBoardES/401f1000.aess/dapm
out1.png
Now we can compare the pictures :)
And then dig into the code since they are not equivalent (they do not have to match exactly since some nodes are named differently).

BTW: I have started to try to disassemble the "firmware" binary with capstone/cstool. It may (or may not) be a tms320c64x...
 
Last edited:
Risca said:
Code: 
amixer cset -c 1 name='Headset Left Playback' 1
  amixer cset -c 1 name='Headset Right Playback' 1
  amixer cset -c 1 name='Headset Playback Volume' 12
  amixer cset -c 1 name='DL1 PDM Switch' 1
  amixer cset -c 1 name='Sidetone Mixer Playback' 1
  amixer cset -c 1 name='SDT DL Volume' 120
  amixer cset -c 1 name='DL1 Mixer Multimedia' 1
  amixer cset -c 1 name='DL1 Media Playback Volume' 110
  amixer sset -c 1 'Analog Left',0 'Aux/FM Left'
  amixer sset -c 1 'Analog Right',0 'Aux/FM Right'
  amixer sset -c 1 'Aux FM',0 7
  amixer sset -c 1 'AUDUL Media',0 149
  amixer sset -c 1 'Capture',0 4
  amixer sset -c 1 MUX_UL00,0 AMic0
  amixer sset -c 1 MUX_UL01,0 AMic1
  amixer sset -c 1 'AMIC UL',0 120
Click to expand...
I believe these commands are what makes the connections between the "bubbles"
 
Have run the script and something has changed, but they are partially still far away from being equivalent.
Differences:
  • I do not see any green bubble
  • the aess picture is still very small
  • in root, there are double links
Most likely this has something to do with the dynamic setup of DAI links which I have found in the code.
BTW: the
Code: 
amixer cset -c 1 name='Headset Right Playback' 1
reports
Code: 
Wrong control identifier: 1
and so do all other cset commands. The sset commands work.
So enough aspects to dig into...
 
hns said:
BTW: the
Code: 
amixer cset -c 1 name='Headset Right Playback' 1
reports
Code: 
Wrong control identifier: 1
and so do all other cset commands. The sset commands work.
So enough aspects to dig into...
Click to expand...
Maybe there's an issue with the location of the -c flag? All the examples in the man page places it before the command
 
I should dump all the possible controls available to amixer in the Linux-3.8 kernel once I get home again. Hopefully tomorrow, but it might be next week
 
I had already checked the available amixer settings and they are almost identical (just different where minor features were added).

But I have looked into the upstream code and there seems to be an explanation why I see some double-arrows in my root.png:

https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap4-panda-common.dtsi#L91
https://elixir.bootlin.com/linux/v6.2-rc8/source/sound/soc/ti/omap-abe-twl6040.c#L137

both define DAPM routes. Default omap5 routing is slightly different from the Panda:

https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap5-board-common.dtsi#L130

In both cases the device tree routes are a subset of the defaults from the driver.
So I think there is code missing to remove duplicates or ignore the driver-internal list if there are device tree entries? Or should device tree add only what is missing which would mean to have an empty DTS list? Let's ask the authors of these files...
 
Last edited:
Other news: I found code fragments that I had originally marked (or forgotten) as "FIXME" while converting them from a very old Linux to the latest. They seem to be necessary for operation, and their absence might have side effects, like the missing bubbles in the image. So I'm digging into their function and finding a new place they should have in a "modern" driver.
 
Risca said:
Maybe there's an issue with the location of the -c flag? All the examples in the man page places it before the command
Click to expand...
Yes indeed... Well spotted!
Code: 
root@letux:~# amixer --help
Usage: amixer <options> [command]

Available options:
  -h,--help       this help
  -c,--card N     select the card
  -D,--device N   select the device, default 'default'
...
unfortunately, fixing this doesn't improve anything audible...
 
Generally: https://github.com/goldelico/letux-kernel
You should also subscribe to the Letux kernel mailing list (https://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel) to receive notifications about updates.
There are also pre-built binaries: http://download.goldelico.com/letux-kernel/
But the above scripts or how vizdapm is called are not included anywhere.

EDIT: you can also look at my branch https://github.com/goldelico/letux-kernel/tree/omap-audio-3.15 (which is working on the PandaES). I just checked and vizdapm produces bubble images almost the same as yours.
So I have just to understand the important lines of "git diff omap-audio-3.15 letux-current"... Finding a needle in a haystack may be easier :)
 
Last edited:
Risca said:
Already subscribed ;) haven't seen anything related to AESS lately though. I'm also subscribed to pyra-kernel and pyra-firmware
Click to expand...
Fine! I just wondered because you asked about the code checkout location because it is mentioned there every now and then, but not in a special thread.
Indeed, the last "public" update was here: https://lists.goldelico.com/pipermail/letux-kernel/2023-January/008404.html in the CHANGES.
Well, I can't push all experimental steps until something starts to work, so my latest experiments are not included (they usually add tons of printk and one or two real fixes).
BTW: if you just want to inspect the AESS patches (without firmware stuff): https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/aess-v11 (note: this branch is updated ca. once a week and there may come a -v12 in the future).
Status is that I have found some needles in the haystack and am trying to pick them up... One major issue is that there is no 40124000.mcbsp in the widget list to match the backend paths. And I still don't know if it should be there and how it should be added there or if something else is wrong. Unfortunately I could not boot the same SD card with the older omap-3.15 kernel and add some printk there to look into these lists...
So progress is there, but slow.
 
hns said:
Fine! I just wondered because you asked about the code checkout location because it is mentioned there every now and then, but not in a special thread.
Indeed, the last "public" update was here: https://lists.goldelico.com/pipermail/letux-kernel/2023-January/008404.html in the CHANGES.
Click to expand...
Yes, I've seen the release mails, but I can never find the actual commits I find interesting.
For example, the release you linked mentions "some fixes for soc_component_driver for aess", so I wanted to check that code. I followed the git download link (https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=letux-6.2-rc4), but there was only a ton of merge commits. I didn't really feel like trudging through 50 other merged branches to find this 1 commit, so I entered the commit message in the search bar but it came up empty. I could of course clone the repo, but the Linux repo is big!
 
hns said:
BTW: if you just want to inspect the AESS patches (without firmware stuff): https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/aess-v11 (note: this branch is updated ca. once a week and there may come a -v12 in the future).
Status is that I have found some needles in the haystack and am trying to pick them up... One major issue is that there is no 40124000.mcbsp in the widget list to match the backend paths. And I still don't know if it should be there and how it should be added there or if something else is wrong. Unfortunately I could not boot the same SD card with the older omap-3.15 kernel and add some printk there to look into these lists...
So progress is there, but slow.
Click to expand...
I can take a look :) unfortunately, time is running out this weekend so don't expect much :( I've already spent most of it on "fixing" a stupid bug with the network card on the devboard so it doesn't get a random MAC address every boot. Kinda annoying, but I have a workaround now. I also have nfsroot working, which will hopefully save me time in the long run :)
 
You must log in or register to reply here.

Similar threads

EvilDragon
Information about OS / Kernel / Prototypes
2 3 4
Replies
79
Views
45K
docbroke
docbroke
TrashyMG
Other odd bugs that could use a bounty.
Replies
17
Views
3K
TrashyMG
TrashyMG
Farox
Beta FastTracker 2 Clone
Replies
4
Views
2K
levi
levi
Bosbeetle
Help needed by pyra team
Replies
1
Views
3K
levi
levi
Wally
Pyra Audio Driver - PulseAudio
2
Replies
23
Views
9K
Letalis Sonus
L
Back
Top