On Tue, October 22, 2013 3:06 am, Uimonen, Jaska wrote: > Hello, > > First I have to say, that it is really awesome that you have had > The effort to go through this exercise! I'm meeting the pulse > Developers in ALS this week so we can also talk about these > Issues. >
That will be great. I am happy that you see the value of JACK on Mobile and are in a position to make something positive happen. > As said before, I'm really interested to use jack in > Pulseaudio configuration as architecturally "external" dsp > engine. This Is something that would be very very useful > in my daily laptop development from policy management > point of view. > > I can't really say or promise how or when jackd would become part > of Tizen. First we could possibly provide it by optional component > So you could download it from tizen repo on top of the image. > If the co-operation Between pulse and jackd is working nicely, > we could start to think a permanent solution. But I still emphasize > that these things need time and involve also some politics. > The last thing we want is to provide a sub standard UX by rushing things out the door. FYI, I was accepted for the Tizen Device Program so in about a week I should have a device to run some tests on. I am happy to put some time into this to ease the load on your side. > What I can promise is, that if there are good patches in pulseaudio > Upstream available for these pain spots, we can quite easily > Integrate and release those to tizen. We could maybe also do part > of the actual work depending little bit on the effort. > > Could you still briefly summarize the findings or key items that > Need attention in more detail? > The findings so far: There is a relatively minor "bug" in the message queue for jack-sink/source if there is an app that is not keeping up with the stream which allows the buffer to grow continuously until it overflows and then it is reset to zero again. It seems to be the culprit of the variation in the latency results that I was seeing while testing.There are a couple of possibilities for dealing with it and we are still thinking on the best solution. There also appears to be an issue with running jack-sink/source in realtime mode which needs to be debugged. It might be local to my setup though. The deeper issues in PA are around the Stream Buffer and splitting out the audio and control logic into separate threads from the main thread, - It's possible that we can allow apps to optionally bypass the Stream Buffer to get the lowest possible latency inside of PA and providing "as close to the metal as possible" latency between JACK+PA. - Finer grained thread handling will also provide further optimisations across PA and it has been on the list of things to do for a while. Tanu has a much better overview of the work involved with this item but it will be a pretty major effort and require extensive testing/QA keeping in mind the many possible locations for new bugs to arrive. -- Patrick Shirkey Boost Hardware Ltd > Br, > Jaska > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Patrick Shirkey > Sent: Monday, October 21, 2013 4:59 PM > To: Tizen List > Subject: Re: [Tizen General] Tizen Audio Stack > > Another update for people interested in this thread. > > With the help of Tanu Kaskinen (intel/PA lead) we have identified a few > optimisations that could be made in Pulse Audio to allow it to work more > efficiently in combination with JACK. In addition David Henningson > (Canonical) has contributed some recent patches that seek to make some > parts of PA a little more efficient and has expressed his interest in > seeing the complete set of optimisations done from the Ubuntu Mobile > perspective too. > > I have discussed the issue in depth with the core JACK developers and they > feel that as the issues are (almost all) in regards to optimising Pulse > Audio they can't offer much assistance at this point. > > So the bulk of the effort looks like it will be spent on optimising PA to > get better realtime audio performance and a more efficient graph model > while JACK is running. The benefits from this process will also be > applicable to the general desktop experience so that turns out to be > pretty beneficial all round. > > FYI, the other option of adding Bluez, Murphy and PA API support to JACK > directly went down like a lead balloon with the JACK developers so there > is approx zero likelihood of taking that route. > > What is currently missing is the motivation to undertake the work that is > required as a priority over any other development so I cannot say for sure > how long it will take to get things done. I estimate it will be around > three months of dev time including discussions and Dev/QA so it's not a > major effort in the larger scheme of things. However when it kicks off and > how much resource can be put to the task is still an unknown. > > From the Tizen perspective is there anything that Linux Audio Developers > could be doing to support the implementation process on the OS side? > > > -- > Patrick Shirkey > Boost Hardware Ltd > _______________________________________________ > General mailing list > [email protected] > https://lists.tizen.org/listinfo/general > --------------------------------------------------------------------- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
