On Thu, September 12, 2013 6:13 pm, Counihan, Tom wrote: > > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] >> On Behalf Of Patrick Shirkey >> Sent: Friday, September 06, 2013 5:18 PM >> To: Tizen List >> Subject: Re: [Tizen General] Tizen Audio Stack >> >> >> On Fri, September 6, 2013 7:07 pm, Counihan, Tom wrote: >> > Hi Patrick, >> > >> >> 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 things. >> > >> > Do you know if any work has been done by the JACK community to >> > integrate Bluez? Specifically for HFP and A2DP/ARVCP use cases? >> > >> >> AFAIK no one has publicly integrated JACK directly with the bluez API. I >> think >> that is mostly because PA has pretty good support already. I haven't >> come >> across anyone using a bluetooth device with JACK yet but there is no >> reason it >> cannot or should not be supported. Artists are always looking for new >> ways to >> express themselves via technology. >> >> Currently there is support for ALSA, OSS and FFADO at the device layer. >> Multichannel duplex USB devices can be accessed via ALSA or OSS and IIUC >> they have very similar performance limitations to bluetooth. >> >> Some people have had success working with wireless networked devices >> with >> some limitations on the i/o channel count and cabled networked audio is >> definitely not a problem even distributed across the globe with the >> right >> infrastructure and bandwidth. >> >> Would you like JACK to send audio data directly to the bluetooth headset >> and >> for the audio system to bypass PA while JACK it is running? If so would >> it be a >> requirement for JACK to send audio to both ALSA and bluez devices at the >> same >> time? > > Actually, I come from the perspective of automotive, where the roles you > are probably envisioning are reversed. > And that said, I suspect also the audio quality demands, including latency > demands, may be higher that you probably perceive above. Particularly in > high-end vehicles, where the audio experience is presented as a key > feature .. High-Def HFP, Blueray, ... >
There is at least one luxury car company that is investing time into JACK support for their multimedia solutions. http://magnetimarelli.com/ I'm not sure what Tesla have settled on but they most definitely use Linux as their multimedia OS. >> Otherwise we might be able to split the load between PA and JACK. I'm >> not sure how well JACK would respond to sitting on top of PA but that is >> also >> another potential option. It just hasn't been addressed on the desktop >> as things >> went the other way with PA letting JACK take over the device layer. > > This is one of a number of permutations you mention. One additional > alternative not mentioned to date of course is a pure Jack solution. > The reason I mention this is, as above highlights to me, it looks > complicated interleaving the two solutions. > With complication comes additional risk in terms of maintaining quality, > stability and integrity. Also I'm guessing from a product perspective, the > more code the higher the maintenance cost. > I've no idea what the effort would be to offer an alternative JACK > solution that could seamlessly slip into the Tizen architecture. But I > suspect for those that control the architecture that would be a > pre-requisite (I'm not one of those folks). > I didn't want to push that option as I fear it could open a can of worms especially as there are a couple of Intel guys in the PA team who are paid to work on PA and Tizen integration and I don't want them to think they are under attack. After many years of discussions between PA and JACK devs it is unlikely that the two projects will be consolidated into a single solution because they have broadly different goals and the management of the development process explicitly requires different and conflicting priorities. The crucial difference between JACK and PA is that JACK is designed for low latency professional audio where hardware/power/bandwidth/etc... is not a physical limitation or even really a concern whereas PA is designed for desktop audio management for the consumer experience with a lot of effort spent on low power mobile where resources can be severely restricted. PA uses almost the same ringbuffer technique as JACK for managing the low latency part of the problem. IIRC Lennart Poettering (PA) came up with a slightly different implementation but he discussed it in detail with Paul Davis and Stephane Letz (JACK) at the time. Based on those points of difference JACK enables many to many audio routing, midi, networking and session management. PA enables the i/o device to be shared between many applications and across a network or bluetooth device. PA is not explicitly designed for audio to be shared between apps. The main design goal is to enable normal users to be able to hear audio i/o from their browser, skype and VLC at the same time seamlessly. To really cut to the chase: - JACK is aimed at enabling realtime multimedia production in a modular environment - PA is aimed at audio management in a consumer environment where realtime is not the core concern > >> >> I can see AVRCP being a useful addition to the control protocols. It >> would >> complement midi and osc and be very handy for transport control. >> Enabling >> Handsfree transport control would be a very powerful feature for >> drummers or >> other musicians/performers/artists who cannot easily physically touch >> the >> device. In the past that issue was dealt with by using a gate filter as >> the trigger >> to start/stop the transport but voice control would be very useful too. >> >> Can you see any other issues that I can address with the JACK/PA devs? > > Can you share your desired goals for Tizen (IVI)? > My goal is to enable JACK to run on Tizen (IVI) without having to jump through hoops. The ideal situation would be official support for JACK as the professional audio solution alongside PA as the default audio solution. It would cause me pain if for example OpenSL or "yet another partial solution based on JACK" was given priority (and funding). I personally would like to be able to use JACK on Tizen for realtime networked 3d multimedia production. It would enable cameras, actors, models/set design, sound, all rendering in realtime with contributors from across the globe. In combination with other open source multimedia tools that is a very powerful and cost effective distributed production and live performance solution. I am happy to put effort into making JACK a viable solution for the Tizen platform. IMO Adding support for BlueZ would be a very useful addition to JACK especially if it makes JACK a viable option for inclusion in Tizen. -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
