And finally, the last post I'll do today.
Some devs have already received Pyra prototypes and hopefully, will also find some time to fix issues we have in the OS and kernel.
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I still have prototypes left, but I can't simply send them out to anyone, as they are few and they're expensive.
But maybe some of you who don't have prototypes yet are willing to help out (and find some time for that as well) or you know someone who could.
If that's the case, please let me know.
We don't expect someone to work on it 24/7 (especially not devs with a real life and jobs!), but if you think you got the time and motivation to work a few hours per week or fix a few bugs, then let me know.
On Tue, Jul 04, 2017 at 02:23:41AM +0200, Michael Mrozek wrote:
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I'd love to work on this, but after searching at Goldelico issue tracker, pyra-kernel ML, #dragonbox-{dev,pyra} IRC logs and Letux branches names I am still quite out of context.
Please file a ticket on issue tracker (GitLab you have deployed is good). In it, please specify:
* What "ABE support" means in case of Pyra, specifically * Trusted URL of older kernel to port the code from * Paths of files with code to port * Test procedures which must work with the new way, with enough details for fresh participant to orient * Just a terse technical introduction into what is known about the problem, as possible.
This way the problem description could be done collectively (this is important part of having it solved!), and then any stranger could look at it and try their abilities on solving it. I hope this solving stranger will be me, but can't promise that.
Also please consider publishing other outstanding tasks the same way as suggested above.
P. S. Great progress on Pyra overall, keep pushing!
Hi,
On Tue, Jul 04, 2017 at 02:23:41AM +0200, Michael Mrozek wrote:
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I'd love to work on this, but after searching at Goldelico issue tracker, pyra-kernel ML, #dragonbox-{dev,pyra} IRC logs and Letux branches names I am still quite out of context.
Thanks a lot :) Does that mean you have a bit more time now? If you do, I can send you a unit to work on as well.
Please file a ticket on issue tracker (GitLab you have deployed is good). In it, please specify:
- What "ABE support" means in case of Pyra, specifically
- Trusted URL of older kernel to port the code from
- Paths of files with code to port
- Test procedures which must work with the new way, with enough details for fresh participant to orient
- Just a terse technical introduction into what is known about the problem, as possible.
Yes, I want to work on the tickets as soon as I find the time.
ABE is the Audio Back-End of the OMAP5. In the case of the Pyra, it would be used to do audio sample rate conversions. AFAIK, the TWL runs with 96kHz, so basically everything needs to be upsampled.
Usually, the ABE does that, but as it doesn't work right now, the processor has to do that - which means that playing audio on the Pyra needs a lot of CPU power right now.
Where to find it... good question. zmatt should be able to help here (ping him on IRC, in case he doesn't reply to the mailing list here).
I found the following (TI kernel 3.8): https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/master/sound/s oc/omap/omap-abe-twl6040.c
It still SEEMS to be in our kernel tree: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=sound/soc/omap/om ap-abe- twl6040.c;h=614b18d2f631b80c61e32eaca0b139c816fcb5d5;hb=refs/heads/letu x-4.12.1
Though I don't know if it works or not. Hopefully zmatt can shed some light here :)
On Mon, Jul 17, 2017, at 03:26, Michael Mrozek wrote:
Hi,
On Tue, Jul 04, 2017 at 02:23:41AM +0200, Michael Mrozek wrote:
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I'd love to work on this, but after searching at Goldelico issue tracker, pyra-kernel ML, #dragonbox-{dev,pyra} IRC logs and Letux branches names I am still quite out of context.
Thanks a lot :) Does that mean you have a bit more time now?
No, I have less time :) As I notified you privately before, I'm a father now :)
If you do, I can send you a unit to work on as well.
Let's start the work and see then. Having hands on a unit is very rewarding, but I'm not sure it's worth it for the team. Maybe you should give it to somebody to be a "proxy" for many remote devs, ideally a person with relaxed timetable, to be able to run somebody's code with minimal delay after developer request.
Please file a ticket on issue tracker (GitLab you have deployed is good). In it, please specify:
- What "ABE support" means in case of Pyra, specifically
- Trusted URL of older kernel to port the code from
- Paths of files with code to port
- Test procedures which must work with the new way, with enough details for fresh participant to orient
- Just a terse technical introduction into what is known about the problem, as possible.
Yes, I want to work on the tickets as soon as I find the time.
ABE is the Audio Back-End of the OMAP5. In the case of the Pyra, it would be used to do audio sample rate conversions. AFAIK, the TWL runs with 96kHz, so basically everything needs to be upsampled.
Downsampled, supposedly? Twl6080 is full chip name, right?
Usually, the ABE does that, but as it doesn't work right now, the processor has to do that - which means that playing audio on the Pyra needs a lot of CPU power right now.
Where to find it... good question. zmatt should be able to help here (ping him on IRC, in case he doesn't reply to the mailing list here).
I found the following (TI kernel 3.8): https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/master/sound/s oc/omap/omap-abe-twl6040.c
It still SEEMS to be in our kernel tree: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=sound/soc/omap/om ap-abe- twl6040.c;h=614b18d2f631b80c61e32eaca0b139c816fcb5d5;hb=refs/heads/letu x-4.12.1
Though I don't know if it works or not. Hopefully zmatt can shed some light here :)
Good start. Will reach zmatt.
Am Montag, den 17.07.2017, 10:10 +0100 schrieb Andrey Utkin:
Hi,
just received a quick note from zmatt on IRC: The file I linked to is the general sound driver for the chip. That's why we also have it on the latest kernel.
What's missing is the hardware implementation, and that has a whole subdirectory: sound/soc/omap/aess
So it's probably this one: https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/41b605f2887879 d5e428928b197e24ffb44d9b82/sound/soc/omap/aess
On Mon, Jul 17, 2017, at 03:26, Michael Mrozek wrote:
Hi,
On Tue, Jul 04, 2017 at 02:23:41AM +0200, Michael Mrozek wrote:
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I'd love to work on this, but after searching at Goldelico issue tracker, pyra-kernel ML, #dragonbox-{dev,pyra} IRC logs and Letux branches names I am still quite out of context.
Thanks a lot :) Does that mean you have a bit more time now?
No, I have less time :) As I notified you privately before, I'm a father now :)
If you do, I can send you a unit to work on as well.
Let's start the work and see then. Having hands on a unit is very rewarding, but I'm not sure it's worth it for the team. Maybe you should give it to somebody to be a "proxy" for many remote devs, ideally a person with relaxed timetable, to be able to run somebody's code with minimal delay after developer request.
Please file a ticket on issue tracker (GitLab you have deployed is good). In it, please specify:
- What "ABE support" means in case of Pyra, specifically
- Trusted URL of older kernel to port the code from
- Paths of files with code to port
- Test procedures which must work with the new way, with enough details for fresh participant to orient
- Just a terse technical introduction into what is known about
the problem, as possible.
Yes, I want to work on the tickets as soon as I find the time.
ABE is the Audio Back-End of the OMAP5. In the case of the Pyra, it would be used to do audio sample rate conversions. AFAIK, the TWL runs with 96kHz, so basically everything needs to be upsampled.
Downsampled, supposedly? Twl6080 is full chip name, right?
Usually, the ABE does that, but as it doesn't work right now, the processor has to do that - which means that playing audio on the Pyra needs a lot of CPU power right now.
Where to find it... good question. zmatt should be able to help here (ping him on IRC, in case he doesn't reply to the mailing list here).
I found the following (TI kernel 3.8): https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/master/sou nd/s oc/omap/omap-abe-twl6040.c
It still SEEMS to be in our kernel tree: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=sound/soc/oma p/om ap-abe- twl6040.c;h=614b18d2f631b80c61e32eaca0b139c816fcb5d5;hb=refs/heads/ letu x-4.12.1
Though I don't know if it works or not. Hopefully zmatt can shed some light here :)
Good start. Will reach zmatt.
Hi all,
as far as I remember the ABE (Audio Back End) basically plays the same role as the DSP on the OMAP3 chips. It can autonomously process McBSP data streams in parallel to the ARM core. Audio Engine Sub-system (AESS) is a component of ABE.
On OMAP4/5 it can drive the McASP channel of the Audio Front End twl6040 (also called "Phoenix" chip) instead of the McBSP front end by the twl4030.
See: http://omappedia.org/wiki/Audio_Drive_Arch#Audio_Back_End_.28ABE.29
For operation it needs: * a kernel driver to install firmware and choose options * a firmware to be installed
This is also not very different from managing the GPU.
AFAIR the kernel driver is already upstream in the kernel code (contrary to the GPU) since it is the same as for OMAP4.
But we still need to install the DSP firmware, which does audio filtering, resampling, mixing, forwarding McBSP streams to speaker etc.
I had researched that ca. 3 years ago but forgot most of these things...
Maybe Peter Ujfalusi is a good source for this. He seems to be very familiar with audio stuff and is active kernel developer.
BR, Nikolaus
Am 17.07.2017 um 12:44 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Montag, den 17.07.2017, 10:10 +0100 schrieb Andrey Utkin:
Hi,
just received a quick note from zmatt on IRC: The file I linked to is the general sound driver for the chip. That's why we also have it on the latest kernel.
What's missing is the hardware implementation, and that has a whole subdirectory: sound/soc/omap/aess
So it's probably this one: https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/41b605f2887879 d5e428928b197e24ffb44d9b82/sound/soc/omap/aess
On Mon, Jul 17, 2017, at 03:26, Michael Mrozek wrote:
Hi,
On Tue, Jul 04, 2017 at 02:23:41AM +0200, Michael Mrozek wrote:
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I'd love to work on this, but after searching at Goldelico issue tracker, pyra-kernel ML, #dragonbox-{dev,pyra} IRC logs and Letux branches names I am still quite out of context.
Thanks a lot :) Does that mean you have a bit more time now?
No, I have less time :) As I notified you privately before, I'm a father now :)
If you do, I can send you a unit to work on as well.
Let's start the work and see then. Having hands on a unit is very rewarding, but I'm not sure it's worth it for the team. Maybe you should give it to somebody to be a "proxy" for many remote devs, ideally a person with relaxed timetable, to be able to run somebody's code with minimal delay after developer request.
Please file a ticket on issue tracker (GitLab you have deployed is good). In it, please specify:
- What "ABE support" means in case of Pyra, specifically
- Trusted URL of older kernel to port the code from
- Paths of files with code to port
- Test procedures which must work with the new way, with enough
details for fresh participant to orient
- Just a terse technical introduction into what is known about
the problem, as possible.
Yes, I want to work on the tickets as soon as I find the time.
ABE is the Audio Back-End of the OMAP5. In the case of the Pyra, it would be used to do audio sample rate conversions. AFAIK, the TWL runs with 96kHz, so basically everything needs to be upsampled.
Downsampled, supposedly? Twl6080 is full chip name, right?
Usually, the ABE does that, but as it doesn't work right now, the processor has to do that - which means that playing audio on the Pyra needs a lot of CPU power right now.
Where to find it... good question. zmatt should be able to help here (ping him on IRC, in case he doesn't reply to the mailing list here).
I found the following (TI kernel 3.8): https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/master/sou nd/s oc/omap/omap-abe-twl6040.c
It still SEEMS to be in our kernel tree: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=sound/soc/oma p/om ap-abe- twl6040.c;h=614b18d2f631b80c61e32eaca0b139c816fcb5d5;hb=refs/heads/ letu x-4.12.1
Though I don't know if it works or not. Hopefully zmatt can shed some light here :)
Good start. Will reach zmatt.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Montag, den 17.07.2017, 14:20 +0200 schrieb H. Nikolaus Schaller:
Thanks for the info. That would be great. Right now, simply playing audio uses 26% CPU :D
Hi all,
as far as I remember the ABE (Audio Back End) basically plays the same role as the DSP on the OMAP3 chips. It can autonomously process McBSP data streams in parallel to the ARM core. Audio Engine Sub-system (AESS) is a component of ABE.
On OMAP4/5 it can drive the McASP channel of the Audio Front End twl6040 (also called "Phoenix" chip) instead of the McBSP front end by the twl4030.
See: http://omappedia.org/wiki/Audio_Drive_Arch#Audio_Back_End_.28ABE .29
For operation it needs:
- a kernel driver to install firmware and choose options
- a firmware to be installed
This is also not very different from managing the GPU.
AFAIR the kernel driver is already upstream in the kernel code (contrary to the GPU) since it is the same as for OMAP4.
But we still need to install the DSP firmware, which does audio filtering, resampling, mixing, forwarding McBSP streams to speaker etc.
I had researched that ca. 3 years ago but forgot most of these things...
Maybe Peter Ujfalusi is a good source for this. He seems to be very familiar with audio stuff and is active kernel developer.
BR, Nikolaus
Am 17.07.2017 um 12:44 schrieb Michael Mrozek <EvilDragon@openpando ra.org>:
Am Montag, den 17.07.2017, 10:10 +0100 schrieb Andrey Utkin:
Hi,
just received a quick note from zmatt on IRC: The file I linked to is the general sound driver for the chip. That's why we also have it on the latest kernel.
What's missing is the hardware implementation, and that has a whole subdirectory: sound/soc/omap/aess
So it's probably this one: https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/41b605f288 7879 d5e428928b197e24ffb44d9b82/sound/soc/omap/aess
On Mon, Jul 17, 2017, at 03:26, Michael Mrozek wrote:
Hi,
On Tue, Jul 04, 2017 at 02:23:41AM +0200, Michael Mrozek wrote:
However, we could need more help - especially with the kernel setup, drivers and patches (for example, ABE support needs to be ported from an older kernel version to the current one, otherwise simple audio playing needs tons of processor time).
I'd love to work on this, but after searching at Goldelico issue tracker, pyra-kernel ML, #dragonbox-{dev,pyra} IRC logs and Letux branches names I am still quite out of context.
Thanks a lot :) Does that mean you have a bit more time now?
No, I have less time :) As I notified you privately before, I'm a father now :)
If you do, I can send you a unit to work on as well.
Let's start the work and see then. Having hands on a unit is very rewarding, but I'm not sure it's worth it for the team. Maybe you should give it to somebody to be a "proxy" for many remote devs, ideally a person with relaxed timetable, to be able to run somebody's code with minimal delay after developer request.
Please file a ticket on issue tracker (GitLab you have deployed is good). In it, please specify:
- What "ABE support" means in case of Pyra, specifically
- Trusted URL of older kernel to port the code from
- Paths of files with code to port
- Test procedures which must work with the new way, with
enough details for fresh participant to orient
- Just a terse technical introduction into what is known
about the problem, as possible.
Yes, I want to work on the tickets as soon as I find the time.
ABE is the Audio Back-End of the OMAP5. In the case of the Pyra, it would be used to do audio sample rate conversions. AFAIK, the TWL runs with 96kHz, so basically everything needs to be upsampled.
Downsampled, supposedly? Twl6080 is full chip name, right?
Usually, the ABE does that, but as it doesn't work right now, the processor has to do that - which means that playing audio on the Pyra needs a lot of CPU power right now.
Where to find it... good question. zmatt should be able to help here (ping him on IRC, in case he doesn't reply to the mailing list here).
I found the following (TI kernel 3.8): https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/master /sou nd/s oc/omap/omap-abe-twl6040.c
It still SEEMS to be in our kernel tree: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=sound/soc /oma p/om ap-abe- twl6040.c;h=614b18d2f631b80c61e32eaca0b139c816fcb5d5;hb=refs/he ads/ letu x-4.12.1
Though I don't know if it works or not. Hopefully zmatt can shed some light here :)
Good start. Will reach zmatt.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Mon, Jul 17, 2017 at 12:44:13PM +0200, EvilDragon@openpandora.org wrote:
Am Montag, den 17.07.2017, 10:10 +0100 schrieb Andrey Utkin:
Hi,
just received a quick note from zmatt on IRC: The file I linked to is the general sound driver for the chip. That's why we also have it on the latest kernel.
What's missing is the hardware implementation, and that has a whole subdirectory: sound/soc/omap/aess
So it's probably this one: https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/41b605f2887879 d5e428928b197e24ffb44d9b82/sound/soc/omap/aess
Thanks to everybody for plenty of info.
What a shame, TI public git repo is not fetchable. Am I missing some trick, or do I need to be TI employee to "have access"?
$ git remote add ti git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git [OK] $ git fetch ti fatal: The remote end hung up unexpectedly [ERR=128]
$ git remote set-url ti https://git.ti.com/ti-linux-kernel/ti-linux-kernel [OK] $ git fetch ti fatal: repository 'https://git.ti.com/ti-linux-kernel/ti-linux-kernel/' not found [ERR=128]
On Wed, Jul 19, 2017 at 01:13:09PM +0100, Andrey Utkin wrote:
What a shame, TI public git repo is not fetchable. Am I missing some trick, or do I need to be TI employee to "have access"?
$ git remote add ti git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git [OK] $ git fetch ti fatal: The remote end hung up unexpectedly [ERR=128]
So I managed to fetch that repo, the above issue is specific to my pre-existing git workcopy.
Started to read sound/soc/omap/ with regard to ABE stuff. Not much of a progress for now, but now my vague idea is that aess/ subdir is full of goodness we need, and for some reason it wasn't forward-ported by TI devs from 3.8 branch it was originally introduced in. I guess it is due to lack of TI manpower on OMAP support, but I accept a chance that the right way is now different and thus porting aess/ code is not the right thing to do.
Will read on the code.
-
Andrey Utkin -
H. Nikolaus Schaller -
Michael Mrozek