Audio Driver (with bounty!)

[jedi23]

Same progress as on the slackware side I guess...

 

[Linux-SWAT]

Sucks... Audio pumping battery is the only reason I let the Pyra apart...

 

[hns]

Finally, there are news!

As you may remember, some 3.15 kernel (https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/omap-audio-3.15) is working on the PandaES (omap4) and there is headset audio if it is sent to the "Media LP" channel or to the "twl6040-legacy" channel. The legacy channel circumvents the AESS DSP completely (works also without firmware) while the first makes use of it.

With modern kernels where I have adapted firmware loading and fixed several bugs, I never could make the headset audio work with "Media LP"on the PandaES. Why PandaES and not the Pyra? Because I can leave it permanently connected to LAN and power and it has a headset jack like the Pyra and a single handsfree speaker can be connected. So I gave up for quite a while (everyone has more promising projects than this one).

In the meantime I tried to analyse the AE DSP (which is not a TMS320 or any other well known architecture) and could at least verify that it is doing something.

Recently, I started over to have a look and there was a first observation. Playing to "Media LP" reports that the MP3 is sent to the hardware - but at half speed, compared to the wall-clock. So I started to work on this, found that the AE Event Generator (which defines the rate samples are processed in the DSP) is running at half speed and with some help by one of the omap kernel maintainers, we could fix this by a modification to the device tree. But still there is no sound for the "Media LP" channel. Only with the 3.15 kernel (which does not need this modification).

Comparing code and even flashing new µSD cards, rebuilding firmware etc. from scratch didn't help.

At some point I digged out the omap5 evaluation board, booted and connect a headset. And to my very very big surprise, there was sound on the headset with the "Media LP" channel. With the dusty µSD that was still installed.

It turned out that it had an letux-6.13-rc5 kernel from January 2025. Likely, I simply did not recognize that it can work or did not even test audio with it.

So I flashed two new µSDs card with a rebuilt kernel, Debian 11.11 user-space. And installed the two U-Boot versions for PandaES and for the omap5 evaluation board. And I rebuilt the firmware on both boards. After connecting a headset to the headset jack, both boards play audio on the legacy channel. But the PandaES still plays silence on the "Media LP" channel while the omap5 eval board plays something!

After doing more and more checks, it is now obvious that the AESS basically works on omap5, including the Pyra. It is just the omap4 kernel variant broken which I had been using for testing...

But work even for the omap5 is still not finished to merge the code anywhere:
1) firmware build can not be done for kernels letux-6.16 or later on Debian 11.11 (some gcc version issue)
2) if the "Media LP" channel is used at least once, the "twl6040-legacy" channel gets broken (using "Legacy" once or several times before "Media LP" is no problem)
3) none of the other channels works
4) uninstalling the aess driver as kernel module may hickup the kernel
5) proper power management for the DSP is not working and disabled
6) I have not yet managed to set up the alsamixer to get sound on the handsfree speakers of the Pyra
7) there are no power-consumption tests
8) no tests if re-encoding mp3 e.g. with different sample rate works

I'll try to tidy up this a little bit over the next weeks and do more tests and then it may become possible for others to help with work to fix the final bugs.

 

[Linux-SWAT]

Centimeter by centimeter !
Great news. Thanks for the hard work !

 

[Git1]

Finally, there are news!

As you may remember, some 3.15 kernel (https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/omap-audio-3.15) is working on the PandaES (omap4) and there is headset audio if it is sent to the "Media LP" channel or to the "twl6040-legacy" channel. The legacy channel circumvents the AESS DSP completely (works also without firmware) while the first makes use of it.

With modern kernels where I have adapted firmware loading and fixed several bugs, I never could make the headset audio work with "Media LP"on the PandaES. Why PandaES and not the Pyra? Because I can leave it permanently connected to LAN and power and it has a headset jack like the Pyra and a single handsfree speaker can be connected. So I gave up for quite a while (everyone has more promising projects than this one).

In the meantime I tried to analyse the AE DSP (which is not a TMS320 or any other well known architecture) and could at least verify that it is doing something.

Recently, I started over to have a look and there was a first observation. Playing to "Media LP" reports that the MP3 is sent to the hardware - but at half speed, compared to the wall-clock. So I started to work on this, found that the AE Event Generator (which defines the rate samples are processed in the DSP) is running at half speed and with some help by one of the omap kernel maintainers, we could fix this by a modification to the device tree. But still there is no sound for the "Media LP" channel. Only with the 3.15 kernel (which does not need this modification).

Comparing code and even flashing new µSD cards, rebuilding firmware etc. from scratch didn't help.

At some point I digged out the omap5 evaluation board, booted and connect a headset. And to my very very big surprise, there was sound on the headset with the "Media LP" channel. With the dusty µSD that was still installed.

It turned out that it had an letux-6.13-rc5 kernel from January 2025. Likely, I simply did not recognize that it can work or did not even test audio with it.

So I flashed two new µSDs card with a rebuilt kernel, Debian 11.11 user-space. And installed the two U-Boot versions for PandaES and for the omap5 evaluation board. And I rebuilt the firmware on both boards. After connecting a headset to the headset jack, both boards play audio on the legacy channel. But the PandaES still plays silence on the "Media LP" channel while the omap5 eval board plays something!

After doing more and more checks, it is now obvious that the AESS basically works on omap5, including the Pyra. It is just the omap4 kernel variant broken which I had been using for testing...

But work even for the omap5 is still not finished to merge the code anywhere:
1) firmware build can not be done for kernels letux-6.16 or later on Debian 11.11 (some gcc version issue)
2) if the "Media LP" channel is used at least once, the "twl6040-legacy" channel gets broken (using "Legacy" once or several times before "Media LP" is no problem)
3) none of the other channels works
4) uninstalling the aess driver as kernel module may hickup the kernel
5) proper power management for the DSP is not working and disabled
6) I have not yet managed to set up the alsamixer to get sound on the handsfree speakers of the Pyra
7) there are no power-consumption tests
8) no tests if re-encoding mp3 e.g. with different sample rate works

I'll try to tidy up this a little bit over the next weeks and do more tests and then it may become possible for others to help with work to fix the final bugs.

Fantastic to hear there is more progress being made here. Thanks a lot for your effort.

 

[hns]

Centimeter by centimeter !

Indeed.

Here is the next centimeter:
- latest code changes have been integrated into letux-6.18: https://github.com/goldelico/letux-kernel/tree/letux-6.18
- firmware source code and build process has been fixed and improved (not really necessary to do yourself since there is https://download.goldelico.com/letux-kernel/letux-6.18-lpae/ which provides a copy for download)
- tested for headset audio on Pyra

Still unsolved issues:
1) alternating between playing "McPDM twl6040-legacy" and "ABE Media LP" channels breaks them (Device or resource busy: Operation not permitted)
2) not clear how to enable handsfree on Pyra with AESS (may need additional settings for AESS alsa mixers?)
3) Media LP channel stays silent on headset of PandaES (omap4 only - not Pyra related)
4) "ABE Media1" is broken, but works with 3.15 kernel
5) power-management and measurements
6) not all combinations of kernel-module/kernel-builtin with and without firmware work and fall back properly (there should always be a working "twl6040-legacy" channel)
7) tests for all mixers, microphone, sample rate conversion etc.
8) setup for voice phone call with echo cancellation etc...

 

[Linux-SWAT]

I'm not sure to understand the difference between handsfree and headset...

 

[TeDaDeS]

I'm not sure to understand the difference between handsfree and headset...

I would guess headphones vs. bluetooth?

 

[hns]

I'm not sure to understand the difference between handsfree and headset...

Headset/headphone connector = speakers connected to the round plug socket at the backside of the Pyra
Handsfree speakers = built in stereo speakers above the nubs
And, there is bluetooth as an independent option for connecting stereo speakers (but that is outside the AESS system)
To make it even more confusing, the audio codec chip could drive an earpiece speaker but the Pyra has none.

Or to describe it in other words: at the moment only the round plug provides audio signals in AESS mode.
Handsfree only works in twl6040-legacy mode.

 

[Linux-SWAT]

Is there any audio things still going on ?

 

[jedi23]

One of these sparse life signs only posted on that commercial platform as I mentioned in the final order eMail thread:

 

[spud42]

again, not good enough! why wasnt that news posted here!!

 

[TeDaDeS]

Maybe @hns has an update for us?
If he does create newer kernels, maybe also enable HIDRAW so we can try to add support for the new Steam Controller (now we only have the 'lizard' mode).
So, that would require:
CONFIG_HIDRAW=y
CONFIG_INPUT_UINPUT=y (if we want to use sc-controller, else we need SDL3)

 

[hns]

well, the issue is that EvilDragon no longer writes here (I am also not happy with this). And I must admit that I look here only once a month or so.
Regarding TILER and AESS it is mainly moved (slowly) forward within the LetuxOS kernel (currently letux-7.3 is coming).
For AESS the status is that it works on the headset output on the omap5 evm and the Pyra. But there are still severe bugs like that it works no longer if you use the legacy audio interface.
Things are even too complex for modern LLM chat tools. They have good ideas but circle back and forget what already has been tested or the goal of a discussion.
But I have no idea if and when these latest kernels will become part of a Pyra distribution. The whole Pyra Software project is too fragmented and I even don't have any insights who is working on what. It lacks some central focus like some LKML or this forum.
CONFIG_INPUT_UINPUT=y is already in the LetuxOS kernel and I have noted to CONFIG_HIDRAW.

 

[jedi23]

Things are even too complex for modern LLM chat tools. They have good ideas but circle back and forget what already has been tested or the goal of a discussion.

This I already figured out myself. My trick is to tell the LLM to create an essay covering all the recent problems and insights about certain topics. Every time I let the LLM work on a similar topic, I upload the corresponding essay and tell it to consider it to avoid circling back and forgetting already solved stuff. Works quite good so far!

The whole Pyra Software project is too fragmented and I even don't have any insights who is working on what. It lacks some central focus like some LKML or this forum.

Is anyone actually working on anything right now? With so much silence, one could also say, the whole Pyra Software project is practically dead...
But I'm greatful for anyone who still works on issues every now and then. Considering the amount of fun I'm having with the Pyra, every step forward is only a bonus to an already great device!

 

[TeDaDeS]

This I already figured out myself. My trick is to tell the LLM to create an essay covering all the recent problems and insights about certain topics. Every time I let the LLM work on a similar topic, I upload the corresponding essay and tell it to consider it to avoid circling back and forgetting already solved stuff. Works quite good so far!

Is anyone actually working on anything right now? With so much silence, one could also say, the whole Pyra Software project is practically dead...
But I'm greatful for anyone who still works on issues every now and then. Considering the amount of fun I'm having with the Pyra, every step forward is only a bonus to an already great device!

I use the same approach, have the LLM write me a summary of a project and common issues to avoid. That way I don't constantly circle back to the same problem.
Probably better LLM's have less issues with this. Things like ChatGPT and Copilot can do programming but are more suitable for regular chats. Copilot for Github or Claud Code are already an improvement for coding purposes, still the summary helps even if it's just for yourself picking up stale projects after a long period of time.

I think there needs to be some momentum for people to keep motivated to progress the Pyra. It feels like the hardware assembly pretty much slowed down when Askarus stopped working on it, which reduces the influx of new motivated users by a lot.
The Linux kernel and support for OMAP5 doesn't help either, as you really need hardware acceleration to make things like games/videos/music run well while maintaining a good battery-life. The Pyra has capable hardware we cannot always take advantage of.
For me personally, I was working on a new kernel to but while testing it out on my Pyra I somehow broke my existing installation. As I also do development (including the build) on the Pyra itself, I didn't just want to reinstall the Pyra losing my data and configuration.
I did build a VM so I can do some builds on my PC, especially building the Linux kernel, but testing the kernel does require real hardware. As I have multiple hobby projects, and limited time to work on all of these, I usually pick up the one that is most feasible and interesting for me. I imagine running some AI agents with access to the real hardware could potentially speed up progress, but I haven't tried. Part of the fun for me of having a Pyra is the tinkering you do yourself. But just having a good working Pyra from the start is probably better at this time for most users.

 

[PowerGod]

With the Pandora @EvilDragon was keeping everyone updated and interested with videos and challenges, without someone who does the same for the Pyra it feels abandoned.

Luckily there are at least people who release apps from time to time (THANK YOU !!) making the situation less stale.

 

[jedi23]

More importantly, how can anyone else start working on the kernel when the kernel sources aren't available!!!
This is not a temporary issue, it's down since at least Two Months™

 

[TeDaDeS]

More importantly, how can anyone else start working on the kernel when the kernel sources aren't available!!!
This is not a temporary issue, it's down since at least Two Months™

That's not good indeed. Maybe @hns knows why this offline?

His server also gives an error as response "service temporarily disabled": https://projects.goldelico.com/p/gta04-kernel/
I had a local copy so I didn't check (or did any pull requests lately).
Maybe were using outdated URL's.

 

[jedi23]

There's still access to https://github.com/goldelico/letux-kernel/tree/letux-5.6.y but I guess it has not the Pyra-specific stuff like TILER or Pyrainput that is included within pyra-daveiii-pyradef-aufs.
At least we can still grab the images, but no sources in the extra folders as well: https://packages.pyra-handheld.com/images/extra/