Thoughts regarding audio in Fremantle-port/Neo900
On the N900, audio is handled through PulseAudio and some binary plugins (pulseaudio-module-nokia-*) containing Nokia proprietary algorithms. Also related is a daemon (OHM) and a lot of logic, plugins and other bits) (including some compiled prolog code) that handles policy (i.e. allocating system resources, audio routing, audio priority and more)
The goal of the Fremantle-port/Neo900 project is to be able to run existing binary components that talk to PulseAudio and interact with the policy system (e.g. by talking to libplayback)
There are 2 problems faced by the Fremantle-port/Neo900 project related to this project. The first is due to any changes in the hardware (audio, TV out, power management, bluetooth audio, whatever else) or to the software stack that impact on the policy logic and other closed-source bits. The second is due to the fact that the Neo900 is using a new cellular modem that has a different audio interface to the N900 cellular modem.
 Solutions for problem 1
One or more of the following steps should be taken to solve problem #1:
- Use the same hardware (or compatible hardware) on the Neo900 as on the N900 where possible (e.g. TWL4030, TLV320AIC34, speakers, microphone etc) to minimize the amount of work that needs to be done.
- Verify that, when compiled, the decompiled prolog code is 100% identical to the original prolog file (other than changes we make intentionally), decompile the policy.dresc file somehow and then change the policy files as necessary
- Make changes to kernel drivers or open code to expose the same interface as the N900 exposes, thus allowing the Neo900 to use the closed blobs as-is
- Try and obtain source to the closed bits (unlikely to happen but it wouldn't be the first time leaks happened :) and change as necessary
- Identify if alsa-policy-enforcement, pulseaudio-module-nokia-* or pasr need to change as a result of changes to the hardware/software and if so, reverse engineer, clone or replace them and make the needed changes
- If pulseaudio-modules-nokia-* or pasr need changes one option is to take the bits being used for meego/harmattan (at https://gitorious.org/maemo-multimedia/ ) and hack them to be 100% compatible with the Fremantle software stack and the Neo900 hardware. (we can use the current versions of that code, we can use the older versions that went with the closed pulseaudio-modules-nokia blob and use the pulseaudio-modules-nokia blob as-is or we can use the older versions that went with the closed pulseaudio-modules-nokia blob and reverse engineer the blob)
 Solutions for problem 2
We have the following options for dealing with the cellular modem issue:
- Try and obtain source to pulseaudio-nokia (unlikely to happen but it wouldn't be the first time leaks happened :) and change as necessary
- Use the bits being used for meego/harmattan (at https://gitorious.org/maemo-multimedia/ ) and hack them to be 100% compatible with the Fremantle software stack and the Neo900 hardware. (we can use the current versions of that code, we can use the older versions that went with the closed pulseaudio-modules-nokia blob and use the pulseaudio-modules-nokia blob as-is or we can use the older versions that went with the closed pulseaudio-modules-nokia blob and reverse engineer the blob)
- Hack the kernel driver for cmtspeech to take in the same commands it does now but to translate them into whatever the Neo900 cell modem needs
- Reverse engineer/clone all of pulseaudio-module-nokia-voice (including libcmtspeech) and modify it for the Neo900 cell modem
- Reverse engineer the static copy of libcmtspeech inside pulseaudio-module-nokia-voice, modify it for the Neo900 cell modem and find some way to modify pulseaudio-module-nokia-voice so it uses our new libcmtspeech code somehow
 How to proceed
The following steps should be taken to proceed with this:
- Identify what hardware components from the N900 we can use in the Neo900 and which bits will need to be different
- Try to exercise any avenues we may have to get hold of code to play with (code for policy-settings-RX51, pulseaudio-nokia, pasr or alsa-policy-enforcement)
- Verify the decompiled prolog code is a 100% correct copy
- Find a way to decompile the policy.dresc file and produce a re-compilable output file
- Reverse engineer pulseaudio-nokia, pasr and alsa-policy-enforcement and figure out how those are tied to the hardware and software stack about whether anything will need to be changed. (need to find someone who knows PulseAudio to help with that)
- This page was last modified on 8 November 2014, at 11:32.
- This page has been accessed 1,419 times.