On Sun, Jul 30, 2017 at 03:37:22PM +0100, Andrey Utkin wrote:
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.
So I have almost started doing something :)
For now I've dropped in the missing source files and tweaked few things as needed. Work-in-progress git branch is here: https://github.com/andrey-utkin/linux/tree/pyra-aess
Now I'm facing a pile of compilation errors (https://gist.github.com/andrey-utkin/b1747c530d82a3606dd1a374bf48e432), as quite some of things the code uses hasn't got into mainline kernel. Will work on it, but hard part is ahead and I don't expect success anytime soon.
Also by incident I found a firmware generator for ABE: https://github.com/omap-audio/abefw . And I noticed Peter Ujfalusi when looking at repos in https://github.com/omap-audio/ and recalled Nikolaus' suggestion to get him involved, so I'm CCing Peter here.
Peter, could you please confirm - is porting sound/soc/omap/aess/ code from ti-linux-3.8.y branch the right way to get the most from the audio hardware? Or is the fact that this code hasn't been ported from v3.8 means that there's another way - I don't know, ready userspace driver or whatever?
On 16 September 2017 at 13:56, Andrey Utkin andrey_utkin@fastmail.com wrote:
Also by incident I found a firmware generator for ABE: https://github.com/omap-audio/abefw
It looks closely related to the one I found and referenced on our wiki page for ABE: https://pyra-handheld.com/wiki/index.php?title=Audio_Back_End
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-09-16 16:26, Matthijs van Duin wrote:
On 16 September 2017 at 13:56, Andrey Utkin andrey_utkin@fastmail.com wrote:
Also by incident I found a firmware generator for ABE: https://github.com/omap-audio/abefw
It looks closely related to the one I found and referenced on our wiki page for ABE: https://pyra-handheld.com/wiki/index.php?title=Audio_Back_End
The answer to the last line on the page (regarding to the 3.15 branch): Yes, it should. I was using OMAP4-Blaze (SDP), PandaES and OMAP5-uevm for verification for each next-bnw/ 'release' - Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-09-16 14:56, Andrey Utkin wrote:
On Sun, Jul 30, 2017 at 03:37:22PM +0100, Andrey Utkin wrote:
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.
So I have almost started doing something :)
For now I've dropped in the missing source files and tweaked few things as needed. Work-in-progress git branch is here: https://github.com/andrey-utkin/linux/tree/pyra-aess
Now I'm facing a pile of compilation errors (https://gist.github.com/andrey-utkin/b1747c530d82a3606dd1a374bf48e432), as quite some of things the code uses hasn't got into mainline kernel. Will work on it, but hard part is ahead and I don't expect success anytime soon.
Also by incident I found a firmware generator for ABE: https://github.com/omap-audio/abefw . And I noticed Peter Ujfalusi when looking at repos in https://github.com/omap-audio/ and recalled Nikolaus' suggestion to get him involved, so I'm CCing Peter here.
Peter, could you please confirm - is porting sound/soc/omap/aess/ code from ti-linux-3.8.y branch the right way to get the most from the audio hardware? Or is the fact that this code hasn't been ported from v3.8 means that there's another way - I don't know, ready userspace driver or whatever?
I was forward porting and rewriting the ABE/AESS stuff up until 3.15: https://github.com/omap-audio/linux-audio.git next-bnw/ti-audio-next_3.15
It is a big rewrite of the original code, reshuffling files, renaming things, merging, and fixing some old bugs that we we had.
But the biggest issue imho is the firmware.
Both asoc-fw and abefw have peter/bnw branch, they must be used with the bnw kernel. BNW stands for Brave New World as I was preparing the AESS/ABE code for upstream.
Basically you need to rewrite/drop the asoc-fw to match with ASoC topology.
And the sources for the AESS/ABE firmware is _not_ available along with the compiler it was compiled. I think I still keep compiled binaries around here and there, but if they are lost, there is no way to recreate them.
in linux-audio : next-bnw/ti-audio-next_3.15 you can find the usable dynamic firmware image created with the asoc-fw peter/bnw branch.
I would not try to get 3.8 forward ported, my bnw-3.15 might be a better start. I don't know how big is the diff between the ASoC-dynamic-FW (3.8...3.15) compared to upstream ASoC topology and friends. If there is a big diff, then starting from scratch and using 3.8/3.15 as reference might be the way to go.
- Péter
Hi Peter,
Thanks a lot for replying.
On Tue, Sep 19, 2017 at 01:29:52PM +0300, Peter Ujfalusi wrote:
But the biggest issue imho is the firmware.
Both asoc-fw and abefw have peter/bnw branch, they must be used with the bnw kernel. BNW stands for Brave New World as I was preparing the AESS/ABE code for upstream.
Basically you need to rewrite/drop the asoc-fw to match with ASoC topology.
And the sources for the AESS/ABE firmware is _not_ available along with the compiler it was compiled. I think I still keep compiled binaries around here and there, but if they are lost, there is no way to recreate them.
Sounds scary. Could you please elaborate, what are consequences for us in case these firmware sources are lost?
What we won't achieve because of this, or which worse options does it leave to use the hardware to the fullest?
(I'm still confused about all the stuff related to this topic, forgive me my ignorance please.)
in linux-audio : next-bnw/ti-audio-next_3.15 you can find the usable dynamic firmware image created with the asoc-fw peter/bnw branch.
I would not try to get 3.8 forward ported, my bnw-3.15 might be a better start. I don't know how big is the diff between the ASoC-dynamic-FW (3.8...3.15) compared to upstream ASoC topology and friends. If there is a big diff, then starting from scratch and using 3.8/3.15 as reference might be the way to go.
Thanks, I will do as you suggested.
Hi Andrey,
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-09-19 13:59, Andrey Utkin wrote:
And the sources for the AESS/ABE firmware is _not_ available along with the compiler it was compiled. I think I still keep compiled binaries around here and there, but if they are lost, there is no way to recreate them.
Sounds scary. Could you please elaborate, what are consequences for us in case these firmware sources are lost?
What we won't achieve because of this, or which worse options does it leave to use the hardware to the fullest?
You will be stuck with what the current AESS firmware supports and you will be stuck with the way it is implementing it. Which is not that bad as it sounds as the FW is in good shape.
(I'm still confused about all the stuff related to this topic, forgive me my ignorance please.)
In case you have not seen it, it is a good read: http://omappedia.org/wiki/Audio_Drive_Arch
Especially the drawings under Kernel audio driver controls mapping.
In essence the AESS/ABE is a DSP which does mixing, muxing, SRC, panning, and all sorts of things. It is also interfacing with the DAIs (McPDM, McBSP, DMIC).
- Péter
On Tue, Sep 19, 2017 at 02:52:37PM +0300, Peter Ujfalusi wrote:
You will be stuck with what the current AESS firmware supports and you will be stuck with the way it is implementing it. Which is not that bad as it sounds as the FW is in good shape.
You are referring to this "omap4_abe_new" file, right?
https://git.ti.com/glsdk/abefw-omap4plus/trees/master/firmware
https://github.com/mvduin/abefw-omap4plus/tree/master/firmware
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2017-09-19 15:15, Andrey Utkin wrote:
On Tue, Sep 19, 2017 at 02:52:37PM +0300, Peter Ujfalusi wrote:
You will be stuck with what the current AESS firmware supports and you will be stuck with the way it is implementing it. Which is not that bad as it sounds as the FW is in good shape.
You are referring to this "omap4_abe_new" file, right?
https://git.ti.com/glsdk/abefw-omap4plus/trees/master/firmware
https://github.com/mvduin/abefw-omap4plus/tree/master/firmware
it is the combined AESS/ABE firmware + the ASoC dynamic fw image. The combined image for my bnw branch is named: omap_aess-adfw.bin and since I was doing bigger changes they are not remotely compatible ;)
- Péter
On Tue, Sep 19, 2017 at 11:59:25AM +0100, Andrey Utkin wrote:
On Tue, Sep 19, 2017 at 01:29:52PM +0300, Peter Ujfalusi wrote:
I would not try to get 3.8 forward ported, my bnw-3.15 might be a better start. I don't know how big is the diff between the ASoC-dynamic-FW (3.8...3.15) compared to upstream ASoC topology and friends. If there is a big diff, then starting from scratch and using 3.8/3.15 as reference might be the way to go.
Thanks, I will do as you suggested.
So I've restarted forward-porting, using Peter's next-bnw/ti-audio-next_3.15 branch, and had some progress, see https://github.com/andrey-utkin/linux/commits/pyra-aess
Luckily, a bunch of snd_soc_fw_* functions and structs used in AESS source code are already in mainline kernel as snd_soc_tplg_*. It would be tough work for me if it wasn't the case.
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
Also, power management callbacks for suspend and resume have been disabled:
I had to drop suspend and resume callbacks from snd_soc_platform_driver, as this structure doesn't have these callbacks anymore in mainline kernel, see dd63a9c2952e ("ASoC: Remove snd_soc_platform_driver suspend/resume callbacks"). These callbacks are available in snd_soc_component_driver and snd_soc_codec_driver structs. I was about to put omap_aess_pcm_{suspend,resume}() to snd_soc_platform_driver.component_driver, but the fact that these functions take "struct snd_soc_dai *" argument is confusing to me. Again, forgive me my ignorance of sound drivers subsystem :)
I consider this to be not critical as driver can just lack support of suspend/resume temporarily, we'll come back to resolve this when we get it working.
Everybody (especially Peter) is welcome to give comments, advices or add patches. When we fix this last compilation error, we can start testing it in runtime.
Hi,
On 2017-10-08 16:35, Andrey Utkin wrote:
On Tue, Sep 19, 2017 at 11:59:25AM +0100, Andrey Utkin wrote:
On Tue, Sep 19, 2017 at 01:29:52PM +0300, Peter Ujfalusi wrote:
I would not try to get 3.8 forward ported, my bnw-3.15 might be a better start. I don't know how big is the diff between the ASoC-dynamic-FW (3.8...3.15) compared to upstream ASoC topology and friends. If there is a big diff, then starting from scratch and using 3.8/3.15 as reference might be the way to go.
Thanks, I will do as you suggested.
So I've restarted forward-porting, using Peter's next-bnw/ti-audio-next_3.15 branch, and had some progress, see https://github.com/andrey-utkin/linux/commits/pyra-aess
Luckily, a bunch of snd_soc_fw_* functions and structs used in AESS source code are already in mainline kernel as snd_soc_tplg_*. It would be tough work for me if it wasn't the case.
The soc-topology is the evolution of dynamic firmware.
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
Also, power management callbacks for suspend and resume have been disabled:
I had to drop suspend and resume callbacks from snd_soc_platform_driver, as this structure doesn't have these callbacks anymore in mainline kernel, see dd63a9c2952e ("ASoC: Remove snd_soc_platform_driver suspend/resume callbacks"). These callbacks are available in snd_soc_component_driver and snd_soc_codec_driver structs. I was about to put omap_aess_pcm_{suspend,resume}() to snd_soc_platform_driver.component_driver, but the fact that these functions take "struct snd_soc_dai *" argument is confusing to me. Again, forgive me my ignorance of sound drivers subsystem :)
As commit dd63a9c2952e suggests, the device suspend/resume should be used, but it is not a show stopper.
I consider this to be not critical as driver can just lack support of suspend/resume temporarily, we'll come back to resolve this when we get it working.
Everybody (especially Peter) is welcome to give comments, advices or add patches. When we fix this last compilation error, we can start testing it in runtime.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On Wed, Oct 25, 2017 at 02:03:30PM +0300, Peter Ujfalusi wrote:
On 2017-10-08 16:35, Andrey Utkin wrote:
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
Peter,
I tried many times to think of any plan to tackle this, but the best plan so far is "make Peter to do as much as possible".
It is obvious that there's a lot to know about this hardware and existing firmware. What I've done here so far is a coding monkey job, and I really don't possess a fraction of knowledge you have.
What about, say, arbitrary amount of beer to motivate you to help with the rest of this task? Please let me know what you would accept.
What would be great is to have a clear framework to proceed. With hints being that high-level as what you've suggested above, I feel lost. I would need to spend a lot of time before I make sense of how to proceed, and this causes me to procrastinate on this every time.
Please don't take this message as a rant or dissatisfaction with your help - I realize that you are giving your helpful hints for Pyra project out of good will. I just really want to push this task forward, but I find it not practically feasible to succeed on my own.
Andrey,
On 2017-11-24 01:14, Andrey Utkin wrote:
On Wed, Oct 25, 2017 at 02:03:30PM +0300, Peter Ujfalusi wrote:
On 2017-10-08 16:35, Andrey Utkin wrote:
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
Peter,
I tried many times to think of any plan to tackle this, but the best plan so far is "make Peter to do as much as possible".
;)
It is obvious that there's a lot to know about this hardware and existing firmware. What I've done here so far is a coding monkey job, and I really don't possess a fraction of knowledge you have.
What about, say, arbitrary amount of beer to motivate you to help with the rest of this task? Please let me know what you would accept.
Beer is good :D If we bump to each other we could have few for sure...
What would be great is to have a clear framework to proceed. With hints being that high-level as what you've suggested above, I feel lost. I would need to spend a lot of time before I make sense of how to proceed, and this causes me to procrastinate on this every time.
I should not have given up after 3.16, back then I was overwhelmed with other stuff and never got the time to move things forward. There are several things I did not liked about the code, that's why I went to try to clean it up a bit and re-arrange it for the better. We would be in better shape with smaller steps than the state we are where we need to make big change.
But the good thing is that we can as well start from a blank page, don't we? Or do we want backwards compatibility for Android, ubunutu or some other distro which had AESS/ABE support?
If we try to make everything working I'm sure it will fail in unpredictable ways, so I would scrap things a bit and go step by step. First get HS playback working, then HS low power, then add HF playback followed by LP mode. After that work our way top get capture working. One feature after another.
The main issue is that we need to develop the firmware wrapper and the driver at the same time.
I also think that we might not need to roll the current complexity of the driver as the core evolved a lot and it might take some of the burden from the low level.
The first ting is for sure is to work on the firmware itself to wrap it in a soc-topology compatible manner. When that is done we can see what needs to be done on the kernel side.
Need to think about this and study the changes myself also ;)
Please don't take this message as a rant or dissatisfaction with your help - I realize that you are giving your helpful hints for Pyra project out of good will. I just really want to push this task forward, but I find it not practically feasible to succeed on my own.
None taken.
It is great that someone is pushing for this.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On Fr, 2017-11-24 at 14:22 +0200, Peter Ujfalusi wrote:
Hi,
as this is a critical issue (unless we want to burn a lot of CPU power just for the audio mixing):
Is this still being worked on?
We've got a few more devs interested in helping out now, is there something they can help here with?
Thanks!
Andrey,
On 2017-11-24 01:14, Andrey Utkin wrote:
On Wed, Oct 25, 2017 at 02:03:30PM +0300, Peter Ujfalusi wrote:
On 2017-10-08 16:35, Andrey Utkin wrote:
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
Peter,
I tried many times to think of any plan to tackle this, but the best plan so far is "make Peter to do as much as possible".
;)
It is obvious that there's a lot to know about this hardware and existing firmware. What I've done here so far is a coding monkey job, and I really don't possess a fraction of knowledge you have.
What about, say, arbitrary amount of beer to motivate you to help with the rest of this task? Please let me know what you would accept.
Beer is good :D If we bump to each other we could have few for sure...
What would be great is to have a clear framework to proceed. With hints being that high-level as what you've suggested above, I feel lost. I would need to spend a lot of time before I make sense of how to proceed, and this causes me to procrastinate on this every time.
I should not have given up after 3.16, back then I was overwhelmed with other stuff and never got the time to move things forward. There are several things I did not liked about the code, that's why I went to try to clean it up a bit and re-arrange it for the better. We would be in better shape with smaller steps than the state we are where we need to make big change.
But the good thing is that we can as well start from a blank page, don't we? Or do we want backwards compatibility for Android, ubunutu or some other distro which had AESS/ABE support?
If we try to make everything working I'm sure it will fail in unpredictable ways, so I would scrap things a bit and go step by step. First get HS playback working, then HS low power, then add HF playback followed by LP mode. After that work our way top get capture working. One feature after another.
The main issue is that we need to develop the firmware wrapper and the driver at the same time.
I also think that we might not need to roll the current complexity of the driver as the core evolved a lot and it might take some of the burden from the low level.
The first ting is for sure is to work on the firmware itself to wrap it in a soc-topology compatible manner. When that is done we can see what needs to be done on the kernel side.
Need to think about this and study the changes myself also ;)
Please don't take this message as a rant or dissatisfaction with your help - I realize that you are giving your helpful hints for Pyra project out of good will. I just really want to push this task forward, but I find it not practically feasible to succeed on my own.
None taken.
It is great that someone is pushing for this.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 14 June 2018 05:35:36 EEST, Michael Mrozek EvilDragon@openpandora.org wrote:
On Fr, 2017-11-24 at 14:22 +0200, Peter Ujfalusi wrote:
Hi,
as this is a critical issue (unless we want to burn a lot of CPU power just for the audio mixing):
Is this still being worked on?
We've got a few more devs interested in helping out now, is there something they can help here with?
Thanks!
Andrey,
On 2017-11-24 01:14, Andrey Utkin wrote:
On Wed, Oct 25, 2017 at 02:03:30PM +0300, Peter Ujfalusi wrote:
On 2017-10-08 16:35, Andrey Utkin wrote:
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
Peter,
I tried many times to think of any plan to tackle this, but the best plan so far is "make Peter to do as much as possible".
;)
It is obvious that there's a lot to know about this hardware and existing firmware. What I've done here so far is a coding monkey job, and I really don't possess a fraction of knowledge you have.
What about, say, arbitrary amount of beer to motivate you to help with the rest of this task? Please let me know what you would accept.
Beer is good :D If we bump to each other we could have few for sure...
What would be great is to have a clear framework to proceed. With hints being that high-level as what you've suggested above, I feel lost. I would need to spend a lot of time before I make sense of how to proceed, and this causes me to procrastinate on this every time.
I should not have given up after 3.16, back then I was overwhelmed with other stuff and never got the time to move things forward. There are several things I did not liked about the code, that's why I went to try to clean it up a bit and re-arrange it for the better. We would be in better shape with smaller steps than the state we are where we need to make big change.
But the good thing is that we can as well start from a blank page, don't we? Or do we want backwards compatibility for Android, ubunutu or some other distro which had AESS/ABE support?
If we try to make everything working I'm sure it will fail in unpredictable ways, so I would scrap things a bit and go step by step. First get HS playback working, then HS low power, then add HF playback followed by LP mode. After that work our way top get capture working. One feature after another.
The main issue is that we need to develop the firmware wrapper and the driver at the same time.
I also think that we might not need to roll the current complexity of the driver as the core evolved a lot and it might take some of the burden from the low level.
The first ting is for sure is to work on the firmware itself to wrap it in a soc-topology compatible manner. When that is done we can see what needs to be done on the kernel side.
Need to think about this and study the changes myself also ;)
Please don't take this message as a rant or dissatisfaction with your help - I realize that you are giving your helpful hints for Pyra project out of good will. I just really want to push this task forward, but I find it not practically feasible to succeed on my own.
None taken.
It is great that someone is pushing for this.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
-- 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
It's a shame but I haven't done anything since that last e-mail of mine. And I don't think I can get back to working on it currently. Great that you have more people to help! Please cc me on this topic.
-
Andrey Utkin -
Matthijs van Duin -
Michael Mrozek -
Peter Ujfalusi