Hi, On Fri, Nov 14, 2014 at 09:54:42PM +0200, Ivaylo Dimitrov wrote: > On 14.11.2014 19:20, Sebastian Reichel wrote: > >The patch looks ok. It does not cleanup the cmt-speech driver for > >mainline usage, but it should work. Before adding this driver to the > >mainline kernel there should be open source userspace support anyway. > > I am aware of that(patch not ready), it's one of the reasons this > patch still sits on gitorious IMO. > > libcmtspeechdata was opened by Nokia long ago, so I don't understand what > userspace support (for inclusion of the driver in the mainline kernel that > is) is needed. see https://gitorious.org/meego-cellular/libcmtspeechdata/source/7f8f3ce357513e4849e1bf6d657980a514529c1a: ah cool. I assumed, that userland stuff is mostly closed. > REed pulseaudio modules that use cmtspeech will be ready sooner than later > (I believe in 2-3 monts from now), see on gitorious how fast we progressed > with -record and -music modules. Sure, -voice module is way more > complicated, but lots of it is already opensourced, we just need to figure > out a couple of DSP algorithms(drc, agc, aec, etc) related to call quality. > But I don't think the driver should wait for those modules to be REed, they > can be used as is even now, in their closed form for testing. https://gitorious.org/pulseaudio-modules-nemo/jusas-tanuk2-mer-packaging/source/6ed34611b49c99b007f614d9dff4d58369876345: https://github.com/nemomobile/pulseaudio-module-cmtspeech-n9xx/commits/master It seems there is already cmtspeech code for pulseaudio? > Unfortunately all my spare time is dedicated to that PA stuff, so > I simply can't cleanup cmtspeech driver and send a patch for > upstreaming. (Pavel, what about you?) If somebody gets audio working with your driver and documents the steps needed in userland I will take care of upstreaming the driver. > >Btw. I am aware that this would break existing pulse audio stuff, > >but wouldn't it make sense to export a V4L2 device instead of the > >custom /dev/cmt_speech ABI? > > Not to say that I agree with Pali's reply that working userspace should not > be broken just for the sake of it. Actually the mainline kernel never implemented that interface, so there is no regression/break and I don't think introducing userspace ABI's should be done carelessly - especially when there is also a standardized interface. > Nokia PA guys did a great job integrating lots of things related to audio > and honestly, I don't see a reason why should we reinvent the wheel. There > is lot more behind the scenes than simple PCM streaming (like audio policies > and routing, sideband audio, speakers protection, etc) and reiplementing all > this using different API wouldn't worth it IMO. What has speaker protection to do with the modem interface? Shouldn't this be two different PA modules? -- Sebastian
Attachment:
signature.asc
Description: Digital signature
