On 16/10/12 09:21, Tanu Kaskinen wrote:
<snip>
I would like to just drop the closed modules, but is it an acceptable
solution? It would cause major regressions on Nemo's N900 hardware
adaptation at least: audio quality during calls would be bad (very bad,
I believe) and the speaker protection algorithm would not be available.
(I'm not sure if the N9/N950 adaptations would regress too - are the
closed bits currently used on those hw adaptations?)
If those regressions are not acceptable, should we branch
PulseAudio in Nemo, so that everyone else could move on while Nemo stays
stuck on an old PulseAudio version?
Or should I try to replace the closed algorithms with open source
algorithms? PulseAudio has some important algorithms already available,
but they are designed for desktop VoIP use, so I don't know how well
they would perform on a mobile phone. It would be an interesting
exercise to do in any case, but will it have to be done before
PulseAudio can be updated on Mer?
No comments received... The plan is to go ahead with the integration, so
if someone has hardware adaptations (other than N900/N9(50)) that use
non-upstream pulseaudio modules, be prepared to port them to the new
version.
Thanks for the earlier notification, it was appreciated. I didn't reply
because I'm not doing platform development and was expecting someone
else to reply.
I'm just doing some simple app development for Nemo and have an N900 for
testing. I wouldn't want Nemo/Mer development being held back by an old
bit of hardware with binary blobs, but at the same time the N900 is my
only development device so it would be good to have some reassurance
that future builds of Nemo won't be crippled by regressions too much.
Is the option to "somehow branch PulseAudio in Nemo" still a possibility?
That said, I'm not very dependent on audio at the moment.
Thanks,
Ross.
