> -----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, ... > 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 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)? Warm Regards Tom. -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare 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. _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
