[Tizen General] Tizen Audio Stack

Christiane Parein koekske11 at yahoo.fr
Fri Sep 6 03:49:18 GMT 2013

There are mailing list problems: we didn't receive this reply on all our email addresses.


 De : Patrick Shirkey <pshirkey at boosthardware.com>
À : Tizen List <general at lists.tizen.org> 
Envoyé le : Jeudi 5 septembre 2013 16h02
Objet : Re: [Tizen General] Tizen Audio Stack

On Thu, September 5, 2013 8:30 pm, Clark, Joel wrote:
> I know of other Tizen user that would like to see JACK in Tizen, but
> nobody has volunteered to contribute and maintain a port of JACK to the
> Tizen audio subsystem.  Any port of JACK would have to complement the
> existing Tizen audio components and not break working Tizen uses and
> applications and APIs.

The JACK Developers will work within the bounds of specified requirements
for the Tizen Audio stack.

The existing desktop logic is that when JACK is running PA hands over
control of the ALSA interface and then optionally attaches to JACK for
I/O. Both Pulse and GStreamer can connect directly to JACK so allowing
consumer apps to continue to work while JACK is running is not an issue in
that regard.

IIUC there has not been any specific testing done around the issue of
handling phone calls while JACK is running on the desktop but that issue
has been solved for the iOS port. One option is to allow system level
commands to interrupt/pause/disable JACK and take control of the audio
device and the other is to *optionally* allow the user to ignore phones
calls while JACK is running. For professionals the latter is probably more
appropriate as it's unlikely a DJ would want to have a phone call
interrupt them in the middle of a set but for people who are just playing
with their toys the former is a completely reasonable way to handle

I am assuming that Tizen routes all phone calls through PA and uses the PA
API to manage that process? I don't think it will be onerous to give PA a
method to "take over" JACK i/o as the single audio stream. IMO that would
be the most elegant way to handle the combination of PA and JACK on a
communications capable device.

Another option would be for PA to temporarily disconnect JACK from the i/o
ports and put all running JACK apps into "freewheel" mode while a phone
call is in process or disable the JACK i/o completely if resources are
constrained. In that case PA would retake control of the i/o temporarily
and then hand it back to JACK once the call is finished. I'm not sure how
fast and clean that process would be but it is technically feasible. We
would need to run some tests on the switch process but we can discuss on
the PA/JACK lists if it is the preferred method.

From the JACK perspective low latency on Tizen requires access to realtime
capabilities and that PA/GStreamer are configured with JACK support OOTB.

Can you see any other potential issues from the Tizen perspective? JACK
Developers are happy to discuss and find a way to gracefully handle them.
Most of the PA devs are also subscribed to the JACK mailing list and there
is no problem to initiate these discussions over there too.

Patrick Shirkey
Boost Hardware Ltd

> Regards
> Joel
> -----Original Message-----
> From: general-bounces at lists.tizen.org
> [mailto:general-bounces at lists.tizen.org] On Behalf Of Patrick Shirkey
> Sent: Monday, September 02, 2013 1:31 AM
> To: Tizen List
> Subject: Re: [Tizen General] Tizen Audio Stack
> On Sun, September 1, 2013 9:42 pm, MSvB wrote:
>> Hello Patrick,
>> On Fri., Aug. 30, 2013, Patrick Shirkey wrote:
>>>Reading through the porting docs and I come across this enlightening
>>>diagram of the Tizen Audio Stack:
>>>To me it has a glaring hole when compared to this diagram:
>> Nice catch.
>> I hope you get traction on this. While I'm not a typical professional
>> audio user, the use cases for low latency audio as provided by the
>> Jack project is attractive. And since Tizen has incorporated many
>> third party projects it would make sense to include Jack, maybe not in
>> IVI but mobile seems good.
> It would be great to see some effort put into running JACK on the sandy
> bridge platform before it comes to market. JACK has proven to run very
> well on previous generations of the Atom. See
> http://www.youtube.com/watch?v=_yR-fZlm_rg  a demo of the award winning
> indamixx transmission OS which was running meego at the time.
> I'm wondering if some of the hesitation towards acceptance of JACK comes
> from confusion around JACK1 and JACK2. While they are both API compatible
> JACK1 is written in pure C and JACK2 is written in C++. JACK1 was started
> first and JACK2 was built out with funding from the French GRAME institute
> and runs on several platforms including Linux, Mac, Win, iOS.  Work is now
> being done on JACK3 which will effectively replace JACK1 and JACK2 once it
> is released. That will be in C++.
> What we have seen from the Android and the ChromeOS people is instead of
> working with JACK developers to isolate and fix any specific issues they
> found for integrating JACK into a mobile stack they have cherry picked
> certain parts from JACK and left out the really useful stuff like inter
> app communication, midi, networking, etc... in the process inventing yet
> another partially useful layer for the Linux Audio stack but not actually
> addressing the needs of Professional Audio.
> There is already a Pulse Audio sink for JACK which allows Pulse to connect
> to JACK. There is also a gstreamer plugin for JACK which allows gstreamer
> to connect to JACK directly. Pulse can be configured to automatically
> detect when JACK is running and reconfigure it's outputs to connect to
> JACK and act as a proxy for apps like browsers or other consumer apps that
> are written to use pulse audio. JACK can route audio to/from pulse audio
> and gstreamer apps too. So there is already the ability to magically
> reconnect the streams when JACK is active. And vice versa when JACK is
> inactive.
> In addition JACK provides realtime midi protocol for external controllers
> and networking for clustering which is very attractive when combined with
> mobile devices. There is also support for video frame sharing which is a
> third party fork called jack-video written by salsaman(LiVes) and there is
> work being done to integrate 3d modelling data handling.
> JACK is supported by all major and nearly all minor open source multimedia
> apps. Ardour, Qtraktor, Blender, Renoise, EnegyXT just to name a few. JACK
> is the defacto standard for Professional Open Source Multimedia
> Production.
> There is an opportunity to get the open source multimedia community
> onboard with Tizen as a development platform. There is already support for
> c, c++ and html5. By far the majority of open source multimedia apps are
> built in c and c++. Opening up the platform to professional multimedia
> will bring the attention of some very clever and motivated people from
> some of the worlds most advanced musical institutions and universities to
> build out a large selection of high quality professional multimedia tools
> and assorted toys.
> --
> Patrick Shirkey
> Boost Hardware Ltd
> _______________________________________________
> General mailing list
> General at lists.tizen.org
> https://lists.tizen.org/listinfo/general

Patrick Shirkey
Boost Hardware Ltd
General mailing list
General at lists.tizen.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/general/attachments/20130906/2624347f/attachment.html>

More information about the General mailing list