[Jack-Devel] JACK on mobile

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] JACK on mobile

Patrick Shirkey
Hi,

Recently there have been discussions about the viability of getting
official JACK support into the mobile audio stack. Currently JACK is left
out of the mix and Pulse Audio is the default audio system layer.

For most consumer mobile use cases this is not a problem but when it comes
to professional audio and some specific cases with very hard time limits
for the audio graph JACK can actually be preferable over the PA API and
logic.

A few things have been identified that make it hard to just drop JACK into
the mobile audio stack at this point.

1: Bluetooth support especially for hands free audio
2: "Murphy" system daemon support
3: Dealing gracefully with apps that use the PA api

On the PA mailing list we have identified several optimisations that can
be done to PA that would allow PA and JACK to coexist peacefully and cause
minimal system disruption from the developer/user perspective.

However, they are mostly required to allow JACK to run and that is not a
core priority for the PA developers. On the other hand it seems that JACK
developers are not going to be interested in spending time on optimising
PA.

So this leads to a slight issue. Is it likely that JACK will be able to
support both the Bluez and Murphy API's in order to be a drop in
replacement for PA while it is running on a mobile OS? Or is it better to
put the time into optimising PA so that we don't have to double up on
development efforts considering that the PA developers already provide
Bluez and Murphy support and are funded to work on that part of the audio
layer?

The optimisations that would enable PA to work better with JACK are not
trivial and will require some pretty heavy thought and a fair sized chunk
of time commitment to make them happen.

Its possible that we could get some assistance from the Linux Foundation
for the development process if we have a good plan and they agree that it
is an important project. In addition several of the PA developers work at
Intel and Ubuntu so there might be some support from those areas to
provide a fully professional and highly optimised audio stack for Linux
based mobile OS's.



--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Paul Davis
Patrick, with the greatest respect, I think that you are totally barking up the wrong tree here. And I mean, really the wrong tree. Everything you are talking about doing seems to add up to a set of band-aids that all fail to address the core problems with audio on Android. Audio on Android is just fine unless you care about latency. None of these proposed integrations with PA are going to make it a platform that can begin to compare with iOS for music/pro-audio apps.

Ironically, I was talking to a guy at Google who was trying to hire me yesterday and I (mostly joking) said "the only thing I'd want to do at Google is fix audio on Android". He then tried to convince me that he could make that happen.

--p



On Tue, Oct 15, 2013 at 3:27 PM, Patrick Shirkey <[hidden email]> wrote:
Hi,

Recently there have been discussions about the viability of getting
official JACK support into the mobile audio stack. Currently JACK is left
out of the mix and Pulse Audio is the default audio system layer.

For most consumer mobile use cases this is not a problem but when it comes
to professional audio and some specific cases with very hard time limits
for the audio graph JACK can actually be preferable over the PA API and
logic.

A few things have been identified that make it hard to just drop JACK into
the mobile audio stack at this point.

1: Bluetooth support especially for hands free audio
2: "Murphy" system daemon support
3: Dealing gracefully with apps that use the PA api

On the PA mailing list we have identified several optimisations that can
be done to PA that would allow PA and JACK to coexist peacefully and cause
minimal system disruption from the developer/user perspective.

However, they are mostly required to allow JACK to run and that is not a
core priority for the PA developers. On the other hand it seems that JACK
developers are not going to be interested in spending time on optimising
PA.

So this leads to a slight issue. Is it likely that JACK will be able to
support both the Bluez and Murphy API's in order to be a drop in
replacement for PA while it is running on a mobile OS? Or is it better to
put the time into optimising PA so that we don't have to double up on
development efforts considering that the PA developers already provide
Bluez and Murphy support and are funded to work on that part of the audio
layer?

The optimisations that would enable PA to work better with JACK are not
trivial and will require some pretty heavy thought and a fair sized chunk
of time commitment to make them happen.

Its possible that we could get some assistance from the Linux Foundation
for the development process if we have a good plan and they agree that it
is an important project. In addition several of the PA developers work at
Intel and Ubuntu so there might be some support from those areas to
provide a fully professional and highly optimised audio stack for Linux
based mobile OS's.



--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Patrick Shirkey

On Wed, October 16, 2013 7:02 am, Paul Davis wrote:

> Patrick, with the greatest respect, I think that you are totally barking
> up
> the wrong tree here. And I mean, really the wrong tree. Everything you are
> talking about doing seems to add up to a set of band-aids that all fail to
> address the core problems with audio on Android. Audio on Android is just
> fine unless you care about latency. None of these proposed integrations
> with PA are going to make it a platform that can begin to compare with iOS
> for music/pro-audio apps.
>
> Ironically, I was talking to a guy at Google who was trying to hire me
> yesterday and I (mostly joking) said "the only thing I'd want to do at
> Google is fix audio on Android". He then tried to convince me that he
> could
> make that happen.
>

Actually this has nothing at all to do with Android. Google do not support
Pulse Audio and they have made it clear that they do not support JACK
either. I think it is a dead end trying to get Google to change their
position on that. They have proven with both Android and Chrome that they
care very little for the work that has been done on JACK for professional
audio.

This is about getting JACK onto the *other* Linux mobile platforms that
already support PA by default.

Tizen, Ubuntu Mobile, HP WebOS, Jolla, etc...

The only way to make that happen is to address the various issues outlined
in this thread.

I know for a fact that I am not the only person in the whole world who
wants to see JACK running on mobile platforms other than iOS.

JACK is a very powerful and flexible solution for professional audio. If
you think that it is actually inferior to coreaudio I will have to
politely disagree with you.

We have two choices.

1: Add support to JACK so that it can be a drop in replacement for PA
2: Optimise PA so that it can provide the most efficient combination while
JAK is running

Which is the preferred option and who is going to do the work?






> --p
>
>
>
> On Tue, Oct 15, 2013 at 3:27 PM, Patrick Shirkey
> <[hidden email]
>> wrote:
>
>> Hi,
>>
>> Recently there have been discussions about the viability of getting
>> official JACK support into the mobile audio stack. Currently JACK is
>> left
>> out of the mix and Pulse Audio is the default audio system layer.
>>
>> For most consumer mobile use cases this is not a problem but when it
>> comes
>> to professional audio and some specific cases with very hard time limits
>> for the audio graph JACK can actually be preferable over the PA API and
>> logic.
>>
>> A few things have been identified that make it hard to just drop JACK
>> into
>> the mobile audio stack at this point.
>>
>> 1: Bluetooth support especially for hands free audio
>> 2: "Murphy" system daemon support
>> 3: Dealing gracefully with apps that use the PA api
>>
>> On the PA mailing list we have identified several optimisations that can
>> be done to PA that would allow PA and JACK to coexist peacefully and
>> cause
>> minimal system disruption from the developer/user perspective.
>>
>> However, they are mostly required to allow JACK to run and that is not a
>> core priority for the PA developers. On the other hand it seems that
>> JACK
>> developers are not going to be interested in spending time on optimising
>> PA.
>>
>> So this leads to a slight issue. Is it likely that JACK will be able to
>> support both the Bluez and Murphy API's in order to be a drop in
>> replacement for PA while it is running on a mobile OS? Or is it better
>> to
>> put the time into optimising PA so that we don't have to double up on
>> development efforts considering that the PA developers already provide
>> Bluez and Murphy support and are funded to work on that part of the
>> audio
>> layer?
>>
>> The optimisations that would enable PA to work better with JACK are not
>> trivial and will require some pretty heavy thought and a fair sized
>> chunk
>> of time commitment to make them happen.
>>
>> Its possible that we could get some assistance from the Linux Foundation
>> for the development process if we have a good plan and they agree that
>> it
>> is an important project. In addition several of the PA developers work
>> at
>> Intel and Ubuntu so there might be some support from those areas to
>> provide a fully professional and highly optimised audio stack for Linux
>> based mobile OS's.
>>
>>
>>
>> --
>> Patrick Shirkey
>> Boost Hardware Ltd
>> _______________________________________________
>> Jack-Devel mailing list
>> [hidden email]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>


--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Stéphane Letz
Patchfield?

http://google-opensource.blogspot.fr/2013/09/patchfield-for-android.html

https://github.com/google/patchfield

Stéphane


Le 16 oct. 2013 à 08:21, Patrick Shirkey <[hidden email]> a écrit :

>
> On Wed, October 16, 2013 7:02 am, Paul Davis wrote:
>> Patrick, with the greatest respect, I think that you are totally barking
>> up
>> the wrong tree here. And I mean, really the wrong tree. Everything you are
>> talking about doing seems to add up to a set of band-aids that all fail to
>> address the core problems with audio on Android. Audio on Android is just
>> fine unless you care about latency. None of these proposed integrations
>> with PA are going to make it a platform that can begin to compare with iOS
>> for music/pro-audio apps.
>>
>> Ironically, I was talking to a guy at Google who was trying to hire me
>> yesterday and I (mostly joking) said "the only thing I'd want to do at
>> Google is fix audio on Android". He then tried to convince me that he
>> could
>> make that happen.
>>
>
> Actually this has nothing at all to do with Android. Google do not support
> Pulse Audio and they have made it clear that they do not support JACK
> either. I think it is a dead end trying to get Google to change their
> position on that. They have proven with both Android and Chrome that they
> care very little for the work that has been done on JACK for professional
> audio.
>
> This is about getting JACK onto the *other* Linux mobile platforms that
> already support PA by default.
>
> Tizen, Ubuntu Mobile, HP WebOS, Jolla, etc...
>
> The only way to make that happen is to address the various issues outlined
> in this thread.
>
> I know for a fact that I am not the only person in the whole world who
> wants to see JACK running on mobile platforms other than iOS.
>
> JACK is a very powerful and flexible solution for professional audio. If
> you think that it is actually inferior to coreaudio I will have to
> politely disagree with you.
>
> We have two choices.
>
> 1: Add support to JACK so that it can be a drop in replacement for PA
> 2: Optimise PA so that it can provide the most efficient combination while
> JAK is running
>
> Which is the preferred option and who is going to do the work?
>
>
>
>
>
>
>> --p
>>
>>
>>
>> On Tue, Oct 15, 2013 at 3:27 PM, Patrick Shirkey
>> <[hidden email]
>>> wrote:
>>
>>> Hi,
>>>
>>> Recently there have been discussions about the viability of getting
>>> official JACK support into the mobile audio stack. Currently JACK is
>>> left
>>> out of the mix and Pulse Audio is the default audio system layer.
>>>
>>> For most consumer mobile use cases this is not a problem but when it
>>> comes
>>> to professional audio and some specific cases with very hard time limits
>>> for the audio graph JACK can actually be preferable over the PA API and
>>> logic.
>>>
>>> A few things have been identified that make it hard to just drop JACK
>>> into
>>> the mobile audio stack at this point.
>>>
>>> 1: Bluetooth support especially for hands free audio
>>> 2: "Murphy" system daemon support
>>> 3: Dealing gracefully with apps that use the PA api
>>>
>>> On the PA mailing list we have identified several optimisations that can
>>> be done to PA that would allow PA and JACK to coexist peacefully and
>>> cause
>>> minimal system disruption from the developer/user perspective.
>>>
>>> However, they are mostly required to allow JACK to run and that is not a
>>> core priority for the PA developers. On the other hand it seems that
>>> JACK
>>> developers are not going to be interested in spending time on optimising
>>> PA.
>>>
>>> So this leads to a slight issue. Is it likely that JACK will be able to
>>> support both the Bluez and Murphy API's in order to be a drop in
>>> replacement for PA while it is running on a mobile OS? Or is it better
>>> to
>>> put the time into optimising PA so that we don't have to double up on
>>> development efforts considering that the PA developers already provide
>>> Bluez and Murphy support and are funded to work on that part of the
>>> audio
>>> layer?
>>>
>>> The optimisations that would enable PA to work better with JACK are not
>>> trivial and will require some pretty heavy thought and a fair sized
>>> chunk
>>> of time commitment to make them happen.
>>>
>>> Its possible that we could get some assistance from the Linux Foundation
>>> for the development process if we have a good plan and they agree that
>>> it
>>> is an important project. In addition several of the PA developers work
>>> at
>>> Intel and Ubuntu so there might be some support from those areas to
>>> provide a fully professional and highly optimised audio stack for Linux
>>> based mobile OS's.
>>>
>>>
>>>
>>> --
>>> Patrick Shirkey
>>> Boost Hardware Ltd
>>> _______________________________________________
>>> Jack-Devel mailing list
>>> [hidden email]
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>>
>>
>
>
> --
> Patrick Shirkey
> Boost Hardware Ltd
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Patrick Shirkey

On Wed, October 16, 2013 5:47 pm, Stéphane Letz wrote:
> Patchfield?
>
> http://google-opensource.blogspot.fr/2013/09/patchfield-for-android.html
>
> https://github.com/google/patchfield
>

This thread is not intended to be a discussion about Android and the
support or lack thereof for *existing* open source professional audio
solutions like JACK or Pulse Audio from developers who are paid by Google.
It's about the OTHER Linux Mobile Platforms that already run Pulse Audio
and the task of getting JACK onto them as a alternative solution without
forcing users to jump through hoops and/or fight with the various PA vs
JACK issues.

There is another option that hasn't been discussed in detail, which is
running JACK on top of PA on mobile devices that use PA as the default
audio management layer. If people round here feel that is a viable
solution then I guess that answers my questions about the priorities of
JACK developers in regards to the OTHER mobile platforms that already run
PA by default.

Just in case I didn't communicate myself clearly enough and anyone is
still having trouble understanding the topic of this thread, the issues I
am seeking to address are around running JACK,  the namesake of this
mailing list, on mobile operating systems that run *Linux* and have
already chosen *Pulse Audio* as the default audio management layer.

There are currently two options on the table:

1: Optimising PA to allow JACK and PA to coexist peacefully and
efficiently on the same system
2: Extending JACK to support Bluez, Murphy, PA API and a commitment to
ongoing maintenance of those extensions to ensure JACK is a drop in
replacement for PA when it is in use on Moblie OS's that already support
PA by default



--
Patrick Shirkey
Boost Hardware Ltd




> Stéphane
>
>
> Le 16 oct. 2013 à 08:21, Patrick Shirkey <[hidden email]> a
> écrit :
>
>>
>> On Wed, October 16, 2013 7:02 am, Paul Davis wrote:
>>> Patrick, with the greatest respect, I think that you are totally
>>> barking
>>> up
>>> the wrong tree here. And I mean, really the wrong tree. Everything you
>>> are
>>> talking about doing seems to add up to a set of band-aids that all fail
>>> to
>>> address the core problems with audio on Android. Audio on Android is
>>> just
>>> fine unless you care about latency. None of these proposed integrations
>>> with PA are going to make it a platform that can begin to compare with
>>> iOS
>>> for music/pro-audio apps.
>>>
>>> Ironically, I was talking to a guy at Google who was trying to hire me
>>> yesterday and I (mostly joking) said "the only thing I'd want to do at
>>> Google is fix audio on Android". He then tried to convince me that he
>>> could
>>> make that happen.
>>>
>>
>> Actually this has nothing at all to do with Android. Google do not
>> support
>> Pulse Audio and they have made it clear that they do not support JACK
>> either. I think it is a dead end trying to get Google to change their
>> position on that. They have proven with both Android and Chrome that
>> they
>> care very little for the work that has been done on JACK for
>> professional
>> audio.
>>
>> This is about getting JACK onto the *other* Linux mobile platforms that
>> already support PA by default.
>>
>> Tizen, Ubuntu Mobile, HP WebOS, Jolla, etc...
>>
>> The only way to make that happen is to address the various issues
>> outlined
>> in this thread.
>>
>> I know for a fact that I am not the only person in the whole world who
>> wants to see JACK running on mobile platforms other than iOS.
>>
>> JACK is a very powerful and flexible solution for professional audio. If
>> you think that it is actually inferior to coreaudio I will have to
>> politely disagree with you.
>>
>> We have two choices.
>>
>> 1: Add support to JACK so that it can be a drop in replacement for PA
>> 2: Optimise PA so that it can provide the most efficient combination
>> while
>> JAK is running
>>
>> Which is the preferred option and who is going to do the work?
>>
>>
>>
>>
>>
>>
>>> --p
>>>
>>>
>>>
>>> On Tue, Oct 15, 2013 at 3:27 PM, Patrick Shirkey
>>> <[hidden email]
>>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Recently there have been discussions about the viability of getting
>>>> official JACK support into the mobile audio stack. Currently JACK is
>>>> left
>>>> out of the mix and Pulse Audio is the default audio system layer.
>>>>
>>>> For most consumer mobile use cases this is not a problem but when it
>>>> comes
>>>> to professional audio and some specific cases with very hard time
>>>> limits
>>>> for the audio graph JACK can actually be preferable over the PA API
>>>> and
>>>> logic.
>>>>
>>>> A few things have been identified that make it hard to just drop JACK
>>>> into
>>>> the mobile audio stack at this point.
>>>>
>>>> 1: Bluetooth support especially for hands free audio
>>>> 2: "Murphy" system daemon support
>>>> 3: Dealing gracefully with apps that use the PA api
>>>>
>>>> On the PA mailing list we have identified several optimisations that
>>>> can
>>>> be done to PA that would allow PA and JACK to coexist peacefully and
>>>> cause
>>>> minimal system disruption from the developer/user perspective.
>>>>
>>>> However, they are mostly required to allow JACK to run and that is not
>>>> a
>>>> core priority for the PA developers. On the other hand it seems that
>>>> JACK
>>>> developers are not going to be interested in spending time on
>>>> optimising
>>>> PA.
>>>>
>>>> So this leads to a slight issue. Is it likely that JACK will be able
>>>> to
>>>> support both the Bluez and Murphy API's in order to be a drop in
>>>> replacement for PA while it is running on a mobile OS? Or is it better
>>>> to
>>>> put the time into optimising PA so that we don't have to double up on
>>>> development efforts considering that the PA developers already provide
>>>> Bluez and Murphy support and are funded to work on that part of the
>>>> audio
>>>> layer?
>>>>
>>>> The optimisations that would enable PA to work better with JACK are
>>>> not
>>>> trivial and will require some pretty heavy thought and a fair sized
>>>> chunk
>>>> of time commitment to make them happen.
>>>>
>>>> Its possible that we could get some assistance from the Linux
>>>> Foundation
>>>> for the development process if we have a good plan and they agree that
>>>> it
>>>> is an important project. In addition several of the PA developers work
>>>> at
>>>> Intel and Ubuntu so there might be some support from those areas to
>>>> provide a fully professional and highly optimised audio stack for
>>>> Linux
>>>> based mobile OS's.
>>>>
>>>>
>>>>
>>>> --
>>>> Patrick Shirkey
>>>> Boost Hardware Ltd
>>>> _______________________________________________
>>>> Jack-Devel mailing list
>>>> [hidden email]
>>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>>>
>>>
>>
>>
>> --
>> Patrick Shirkey
>> Boost Hardware Ltd
>> _______________________________________________
>> Jack-Devel mailing list
>> [hidden email]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
>


--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Paul Davis
In reply to this post by Patrick Shirkey



On Wed, Oct 16, 2013 at 2:21 AM, Patrick Shirkey <[hidden email]> wrote:


I know for a fact that I am not the only person in the whole world who
wants to see JACK running on mobile platforms other than iOS.

You're not. I'd be very happy to see Android be a suitable platform for music creation and pro-audio applications. That isn't going to happen given the current underlying technology in Android.

Regarding other mobile technologies, I would direct you to one of Brian Lunduke's talks

    https://www.youtube.com/watch?v=QKwWPQ1Orzs

(remember there is a companion video to this one).
 

JACK is a very powerful and flexible solution for professional audio. If
you think that it is actually inferior to coreaudio I will have to
politely disagree with you.

It isn't inferior to any native audio API because it relies on them all and does something different. However, what CoreAudio does do (which neither ALSA nor ASIO do) is provide a native API that works very well for both consumer, mobile and pro-audio/music creation apps that all have widely differing needs. ALSA can be used to get close, but to do things right, ALSA needs to be involved and to be modified/extended.
 

We have two choices.

1: Add support to JACK so that it can be a drop in replacement for PA
2: Optimise PA so that it can provide the most efficient combination while
JAK is running

3. Provide a proper native API on the platform.

Coming up with a solution to the PulseAudio/JACK situation ought to be the goal of a well-funded Linux-wide project because it also involves ALSA and the desktop. To do it properly requires a lot more than hacks to either PA or JACK.
 

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Bradley Justice
In reply to this post by Paul Davis
Very interesting comments on pro audio and mobile platforms, lots here to investigate.

I have been looking at Android as a platform for pro audio applications. I am also convinced that true low latency audio on mainstream Android is not an achievable goal. Google priorities, e.g. maintaining call quality and  low power consumption, render it so. What is achievable is the more modest goal of an Android distribution specifically instrumented for pro audio applications. This is still a worthy goal, especially if you consider Android as an embedded system that can run on a low cost dedicated device.

I have a functional prototype of a pro audio Android distribution running on the Nexus 7. At the end of round 1 of the latency wars I am reliably running Simple Client using USB audio at 96k with buffers set at 512 X 2. To accomplish this, JACK and its clients run in native space directly on top of ALSA with client user interfaces running as standard Java Android activities. I am currently finishing up work on client installation and configuration; I hope to return to the latency issue soon. There are approaches I have yet to explore, such as application of the real-time patches.

This work highlights the critical difference between Android and iOS: with iOS you are restricted to what Apple decides to provide in terms of hardware and system software. With Android, if there is a problem that needs corrected, such as audio drivers, you have the ability to do so.

I do have a question regarding iOS and audio latency. Does anyone on this list have reliable metrics? I have seen some low figures reported on Internet postings. However, figures I have encountered from individuals who actually measured it seem out of range for pro audio.

Brad Justice

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Ralf Mardorf
On Wed, 2013-10-16 at 10:07 -0700, Bradley Justice wrote:
> I do have a question regarding iOS and audio latency. Does anyone on
> this list have reliable metrics? I have seen some low figures reported
> on Internet postings. However, figures I have encountered from
> individuals who actually measured it seem out of range for pro audio.

What do you call a latency that isn't good for pro-audio? As long as
there is no jitter, even relatively long latency IMO still is ok for
professional usage. I won an iPad, but don't use it for music, so I
can't say much about it, but at least I installed some free synth
workstations. Not nearly a synth for Linux, even when running on a tower
PC with best hardware, does reach the capabilities of those
workstations. I'm using Linux only, I don't use Apple and Microsoft
stuff, so don't get me wrong, I'm not against Linux. However, don't try
to compare Linux with proprietary solutions. In a competition regarding
to technical specifications and features Linux has got no chance against
Apple and Microsoft stuff for pro-audio usage.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Paul Davis



On Wed, Oct 16, 2013 at 1:25 PM, Ralf Mardorf <[hidden email]> wrote:
 In a competition regarding
to technical specifications and features Linux has got no chance against
Apple and Microsoft stuff for pro-audio usage.

That must be why companies like Harrison, Waves, Lawo and many others use Linux as the OS for their dedicated PRO-AUDIO technology.

God, I have gmail automatically deleting your posts but just for once I took a peek and found it was just as free of content as ever. Back to the delete bin.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Ralf Mardorf
On Wed, 2013-10-16 at 13:41 -0400, Paul Davis wrote:

>
>
>
> On Wed, Oct 16, 2013 at 1:25 PM, Ralf Mardorf
> <[hidden email]> wrote:
>          In a competition regarding
>         to technical specifications and features Linux has got no
>         chance against
>         Apple and Microsoft stuff for pro-audio usage.
>
>
> That must be why companies like Harrison, Waves, Lawo and many others
> use Linux as the OS for their dedicated PRO-AUDIO technology.
>
>
> God, I have gmail automatically deleting your posts but just for once
> I took a peek and found it was just as free of content as ever. Back
> to the delete bin.

That's a misunderstanding. I'm talking about some stuff that is wanted
by the market. That there is professional software available for Linux
and the technical specifications are ok to use it professional, this is
not what I raise to question. You don't need some things, I don't needed
some things, but it's needed by many customers. There are amazing
workstations available and Linux has nothing that can compare to those
workstations. I've got doubts that if somebody would program such a
workstation for Linux, it would need that less resources as the Apple
and Windows workstations do need.

Content free as ever Paul? Should I quote again when you tried to
discredit me, while you were mistaken :D? E.g. regarding to Jack2. No
hard feelings! It's just a joke for me.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Christian Schoenebeck
In reply to this post by Bradley Justice
On Wednesday 16 October 2013 19:07:43 Bradley Justice wrote:
> I do have a question regarding iOS and audio latency. Does anyone on this
> list have reliable metrics? I have seen some low figures reported on
> Internet postings. However, figures I have encountered from individuals who
> actually measured it seem out of range for pro audio.

JACK iOS (RIP) was configurable down to 2.9ms

        http://www.crudebyte.com/jack-ios/jack_ios_shot_3.png

which worked reliable on all iOS devices we tested (while running multiple
audio apps simultaneously), even on older devices. Probably even lower
latencies are possible, but we actually never tested going below that buffer
size (due to other priorities). What I found interesting was that even ancient
iPhone 1 devices provided reliable low latency.

I have a big sympathy for modern Mach derivative kernels, even though Apple's
XNU kernel (Mac & iOS) is not top-notch anymore, it still solves things very
elegant and efficiently. I would love to see some L4 microkernel to enter a
major distro as alternative to the Linux kernel in future. But due to the old
problems of i.e. missing drivers, alternative kernels won't have a chance on
major open source distros that soon I fear ...

CU
Christian
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Bradley Justice
In reply to this post by Paul Davis
On Wed, Oct 16, 2013 at 1:25 PM, Ralf Mardorf <[hidden email]> wrote:
>What do you call a latency that isn't good for pro-audio?

In selling a previous product I found market resistance to any number above the 4 to 5 ms range. For more than a few professional musicians a number larger than 0 was unacceptable; this of course is an unobtainable goal.

For the amateur musician market the number would be softer.

I have no personal opinion, I don't have a musician's ears. I do not know if our customers were truly sensitive to latency at these levels, but their purchases are determined by what they believe.


Brad Justice

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

John Rigg-16
On Wed, Oct 16, 2013 at 12:02:17PM -0700, Bradley Justice wrote:

> On Wed, Oct 16, 2013 at 1:25 PM, Ralf Mardorf <[hidden email]>wrote:
> >What do you call a latency that isn't good for pro-audio?
>
> In selling a previous product I found market resistance to any number above
> the 4 to 5 ms range. For more than a few professional musicians a number
> larger than 0 was unacceptable; this of course is an unobtainable goal.
>
> For the amateur musician market the number would be softer.
>
> I have no personal opinion, I don't have a musician's ears. I do not know
> if our customers were truly sensitive to latency at these levels, but their
> purchases are determined by what they believe.

It depends on the application. I typically use the maximum latency possible
with my interface hardware for multitrack recording (about 21ms at 48kHz sample
rate). If monitoring direct from interface hardware or mixing desk, short
latency isn't required for straighforward recording and overdubbing.

Short latency _is_ required when monitoring from software, but it doesn't
necessarily follow that lack of short latency rules out all pro audio work.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Stéphane Letz
In reply to this post by Christian Schoenebeck

Le 16 oct. 2013 à 20:17, Christian Schoenebeck <[hidden email]> a écrit :

> On Wednesday 16 October 2013 19:07:43 Bradley Justice wrote:
>> I do have a question regarding iOS and audio latency. Does anyone on this
>> list have reliable metrics? I have seen some low figures reported on
>> Internet postings. However, figures I have encountered from individuals who
>> actually measured it seem out of range for pro audio.
>
> JACK iOS (RIP) was configurable down to 2.9ms
>
> http://www.crudebyte.com/jack-ios/jack_ios_shot_3.png
>
> which worked reliable on all iOS devices we tested (while running multiple
> audio apps simultaneously), even on older devices. Probably even lower
> latencies are possible, but we actually never tested going below that buffer
> size (due to other priorities). What I found interesting was that even ancient
> iPhone 1 devices provided reliable low latency.
>
> I have a big sympathy for modern Mach derivative kernels, even though Apple's
> XNU kernel (Mac & iOS) is not top-notch anymore, it still solves things very
> elegant and efficiently. I would love to see some L4 microkernel to enter a
> major distro as alternative to the Linux kernel in future. But due to the old
> problems of i.e. missing drivers, alternative kernels won't have a chance on
> major open source distros that soon I fear ...
>
> CU
> Christian

Well Christian you are speaking of the 2 * buffer size latency here right?

OSX usually decompose I/O latency as = AD conversion latency + input latency offset + 2 * buffer size +  output latency offset + DA conversion latency

So I would guess the minimal I/O latency on IOS is more than the 2.9 ms value….

Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Christian Schoenebeck
On Wednesday 16 October 2013 22:49:01 you wrote:
> Well Christian you are speaking of the 2 * buffer size latency here right?
>
> OSX usually decompose I/O latency as = AD conversion latency + input
> latency offset + 2 * buffer size +  output latency offset + DA conversion
> latency
>
> So I would guess the minimal I/O latency on IOS is more than the 2.9 ms
> value….

Yes, exactly.

Or if the use case is a soft synth with ext. keyboard, you must at least add
1.0 ms on input chain side because of the minimum theoretical USB polling
interval (for "low" & "full speed" USB endpoints that is, which are still used
in most USB MIDI controllers), plus probably even more for poor demultiplexers
in inexpensive keyboards, etc.

So if the original question was rather precise total end to end latency
measurements, then sorry, cannot serve. ;-)

CU
Christian
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Patrick Shirkey
In reply to this post by Paul Davis

On Thu, October 17, 2013 12:59 am, Paul Davis wrote:

> On Wed, Oct 16, 2013 at 2:21 AM, Patrick Shirkey
> <[hidden email]
>> wrote:
>
>>
>>
>> I know for a fact that I am not the only person in the whole world who
>> wants to see JACK running on mobile platforms other than iOS.
>>
>
> You're not. I'd be very happy to see Android be a suitable platform for
> music creation and pro-audio applications. That isn't going to happen
> given
> the current underlying technology in Android.
>
> Regarding other mobile technologies, I would direct you to one of Brian
> Lunduke's talks
>
>     https://www.youtube.com/watch?v=QKwWPQ1Orzs
>
> (remember there is a companion video to this one).
>
>
>>
>> JACK is a very powerful and flexible solution for professional audio. If
>> you think that it is actually inferior to coreaudio I will have to
>> politely disagree with you.
>>
>
> It isn't inferior to any native audio API because it relies on them all
> and
> does something different. However, what CoreAudio does do (which neither
> ALSA nor ASIO do) is provide a native API that works very well for both
> consumer, mobile and pro-audio/music creation apps that all have widely
> differing needs. ALSA can be used to get close, but to do things right,
> ALSA needs to be involved and to be modified/extended.
>
>
>>
>> We have two choices.
>>
>> 1: Add support to JACK so that it can be a drop in replacement for PA
>> 2: Optimise PA so that it can provide the most efficient combination
>> while
>> JAK is running
>>
>
> 3. Provide a proper native API on the platform.
>
> Coming up with a solution to the PulseAudio/JACK situation ought to be the
> goal of a well-funded Linux-wide project because it also involves ALSA and
> the desktop. To do it properly requires a lot more than hacks to either PA
> or JACK.
>

Nobody is talking about *hacking* PA or JACK in order to achieve the goal
of having JACK as a default audio system alternative for very low latency
professional audio on Linux mobile OS's that already run PA as the default
audio management system. We have identified several optimisations to PA
that can be untertaken to enable it to work more efficiently when running
on top of JACK. Sure there will still be an extra step in the graph for
apps that need to run through PA but at least it will allow JACK to run at
the lower layer and provide ease of use for developers and users. This
would also benefit desktop Linux users who run PA too (everyone running
Gnome or KDE) and make the option of running JACK and PA at the same time
a more reliable and efficient process.

The discussion has so far been around what needs to be done to make it
viable for JACK to be included as an officially supported app and
therefore receive some more resources from the various consortiums of
large multinational companies that would be supporting this step. Given
that PA is the existing choice of all the OTHER Linux mobile OS's and
there has been significant ongoing effort and funding channeled into PA
development it makes sense to me that the focus has been on how to deal
gracefully with the things that PA normally looks after if the user
chooses to run JACK.

I disagree that in order to run JACK on the OTHER mobile OS's that already
run PA by default we need to create and pay for a whole new audio system
that replaces both PA and JACK. That is the path that Google have taken
with both Android and ChromeOS and they have not succeeded with several
full time and well funded developers working on the task.

However if the consensus from JACK developers is that they want to build a
completely new audio system rather than spend any time on optimising the
combination of PA and JACK then I will report that back to the interested
and supportive parties who have opened the door to us and let them know
that unfortunately, due to political and personal objections it is very
unlikely JACK will ever be able to be officially supported to run on any
OTHER mobile platform than iOS.

From my perspective we have been given an opportunity to make something
awesome happen and it would be a huge loss to kick it to the ground just
because there is a possibility that interested JACK developers should work
on PA optimisation of the JACK source/sink and optimise PA in other ways
to make running JACK + PA a more reliable and stable user experience. God
forbid that we actually make the complete audio system a more stable and
reliable experience for everyone who runs Linux on the desktop too. What
would we be thinking? That almost sounds like rational behaviour.

Or is the hatred of PA so ingrained  that all JACK developers are blinded
by their desire to see it vanquished from the earthly realm? The ongoing
quest for spiritual freedom of not having to run PA on any desktop system
ever? The righteous quest of holy armagiddeon. The existential threat of
PA dominion. <rant>....</rant>



--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Paul Davis



On Wed, Oct 16, 2013 at 10:13 PM, Patrick Shirkey <[hidden email]> wrote:

the lower layer and provide ease of use for developers and users. This
would also benefit desktop Linux users who run PA too (everyone running
Gnome or KDE) and make the option of running JACK and PA at the same time
a more reliable and efficient process.

There are no real issues with running PA on top of JACK when you combine the right version of PA with the right version of JACK. I'm not sure what problems you think exist - it would be interesting to hear about them. As far as I understand it both PA and JACK developers consider this a done deal in each technology, but one subject to distribution/platform capabilities to make it work or make it fail.
 

The discussion has so far been around what needs to be done to make it
viable for JACK to be included as an officially supported app

Work apparently. From your opening message in this thread:

  "The optimisations that would enable PA to work better with JACK are not trivial and will require some pretty heavy thought and a fair sized chunk of time commitment to make them happen."

It sounds as if you want someone to do some work on this for no other reason that mobile platforms are cool, or something. Oh, except it doesn't actually the MAJOR linux-y mobile platform at all. There is already a massive shortage of resources to put towards JACK development. Maybe some one new will take up your call to arms, and if so, great. Really.

But looking at the "existing" JACK development community as if this is something that anyone here is obligated (or frankly, even likely) to be interested in ... well, to me it is just silly.

You talk below about "various consortiums of large multinational companies that would be supporting this step" - why don't they create a paid position to do whatever it is that needs doing, away from the noise of this list. It would be more efficient, and more likely to get someone to actually do it.

The thing is Patrick, you are talking platforms with tiny market share. JACK is a community of people focused mostly on music creation and pro-audio. The market you are talking about (in terms of devices) is close to meaningless. Linux isn't a big enough market already for this stuff (barely) and now you want to sell us on various secondary linux-y mobile platforms as the new big thing? Sorry, I'm not buying it. I'm not trying to be antagonistic, but you write about this stuff as if it ought to be bloody obvious to everyone how awesomely cool this is. All I see are more variants on meego or whatever that end up with essentially no market and certainly none of the excitement that exists within the iOS music creation/pro-audio community.
 
I disagree that in order to run JACK on the OTHER mobile OS's that already
run PA by default we need to create and pay for a whole new audio system
that replaces both PA and JACK. That is the path that Google have taken

Actually, the seem to have gone further than that, unfortunately.
 
with both Android and ChromeOS and they have not succeeded with several
full time and well funded developers working on the task.

They don't understand the issues, at least it appears to be that way.
 

However if the consensus from JACK developers is that they want to build a
completely new audio system rather than spend any time on optimising the

Not a new audio system. All Linux based systems have access to a perfectly viable audio subsystem. Its name is ALSA. Mobile platforms just want to avoid exposing it (or even using it). Why? And why should we have to cater to that?
 
combination of PA and JACK then I will report that back to the interested
and supportive parties who have opened the door to us and let them know
that unfortunately, due to political and personal objections it is very
unlikely JACK will ever be able to be officially supported to run on any
OTHER mobile platform than iOS.

It cannot run on iOS anymore. You missed the news, apparently.
 
Or is the hatred of PA so ingrained  that all JACK developers are blinded
by their desire to see it vanquished from the earthly realm? The ongoing
quest for spiritual freedom of not having to run PA on any desktop system
ever? The righteous quest of holy armagiddeon. The existential threat of
PA dominion. <rant>....</rant>

This is just stupid. I think PA is a pretty awesome system. In some ways, I may even be responsible for its adoption, having urged this very early at Ye Olde Linux Desktop Architects meetings back in the early 2000s. I have nothing but respect for PA. My respect is tempered with an understanding of its deliberate design limitations, which happen to be roughly opposite those of JACK.

Instead of asking for volunteer help, why don't you try to actually hire someone?

--p

 

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Patrick Shirkey

On Thu, October 17, 2013 1:40 pm, Paul Davis wrote:

> On Wed, Oct 16, 2013 at 10:13 PM, Patrick Shirkey <
> [hidden email]> wrote:
>
>>
>> the lower layer and provide ease of use for developers and users. This
>> would also benefit desktop Linux users who run PA too (everyone running
>> Gnome or KDE) and make the option of running JACK and PA at the same
>> time
>> a more reliable and efficient process.
>>
>
> There are no real issues with running PA on top of JACK when you combine
> the right version of PA with the right version of JACK. I'm not sure what
> problems you think exist - it would be interesting to hear about them. As
> far as I understand it both PA and JACK developers consider this a done
> deal in each technology, but one subject to distribution/platform
> capabilities to make it work or make it fail.
>
>
>>
>> The discussion has so far been around what needs to be done to make it
>> viable for JACK to be included as an officially supported app
>>
>
> Work apparently. From your opening message in this thread:
>
>   "The optimisations that would enable PA to work better with JACK are not
> trivial and will require some pretty heavy thought and a fair sized chunk
> of time commitment to make them happen."
>
> It sounds as if you want someone to do some work on this for no other
> reason that mobile platforms are cool, or something. Oh, except it doesn't
> actually the MAJOR linux-y mobile platform at all. There is already a
> massive shortage of resources to put towards JACK development. Maybe some
> one new will take up your call to arms, and if so, great. Really.
>
> But looking at the "existing" JACK development community as if this is
> something that anyone here is obligated (or frankly, even likely) to be
> interested in ... well, to me it is just silly.
>
> You talk below about "various consortiums of large multinational companies
> that would be supporting this step" - why don't they create a paid
> position
> to do whatever it is that needs doing, away from the noise of this list.
> It
> would be more efficient, and more likely to get someone to actually do it.
>
> The thing is Patrick, you are talking platforms with tiny market share.
> JACK is a community of people focused mostly on music creation and
> pro-audio. The market you are talking about (in terms of devices) is close
> to meaningless. Linux isn't a big enough market already for this stuff
> (barely) and now you want to sell us on various secondary linux-y mobile
> platforms as the new big thing? Sorry, I'm not buying it. I'm not trying
> to
> be antagonistic, but you write about this stuff as if it ought to be
> bloody
> obvious to everyone how awesomely cool this is. All I see are more
> variants
> on meego or whatever that end up with essentially no market and certainly
> none of the excitement that exists within the iOS music creation/pro-audio
> community.
>
>
>> I disagree that in order to run JACK on the OTHER mobile OS's that
>> already
>> run PA by default we need to create and pay for a whole new audio system
>> that replaces both PA and JACK. That is the path that Google have taken
>>
>
> Actually, the seem to have gone further than that, unfortunately.
>
>
>> with both Android and ChromeOS and they have not succeeded with several
>> full time and well funded developers working on the task.
>>
>
> They don't understand the issues, at least it appears to be that way.
>
>
>>
>> However if the consensus from JACK developers is that they want to build
>> a
>> completely new audio system rather than spend any time on optimising the
>>
>
> Not a new audio system. All Linux based systems have access to a perfectly
> viable audio subsystem. Its name is ALSA. Mobile platforms just want to
> avoid exposing it (or even using it). Why? And why should we have to cater
> to that?
>
>
>> combination of PA and JACK then I will report that back to the
>> interested
>> and supportive parties who have opened the door to us and let them know
>> that unfortunately, due to political and personal objections it is very
>> unlikely JACK will ever be able to be officially supported to run on any
>> OTHER mobile platform than iOS.
>>
>
> It cannot run on iOS anymore. You missed the news, apparently.
>
>
>> Or is the hatred of PA so ingrained  that all JACK developers are
>> blinded
>> by their desire to see it vanquished from the earthly realm? The ongoing
>> quest for spiritual freedom of not having to run PA on any desktop
>> system
>> ever? The righteous quest of holy armagiddeon. The existential threat of
>> PA dominion. <rant>....</rant>
>>
>
> This is just stupid. I think PA is a pretty awesome system. In some ways,
> I
> may even be responsible for its adoption, having urged this very early at
> Ye Olde Linux Desktop Architects meetings back in the early 2000s. I have
> nothing but respect for PA. My respect is tempered with an understanding
> of
> its deliberate design limitations, which happen to be roughly opposite
> those of JACK.
>
> Instead of asking for volunteer help, why don't you try to actually hire
> someone?
>

As i said in the opening message there is a possibility that the Linux
Foundation could be interested in funding the development process if we
can come up with a viable plan. I have already committed my own funds to
funding myself to do the work required to get things to this point in the
process. Trust me when I say my wife is not happy about my decision to use
my time in this way. Its not just a case of sitting down and writing some
code. It also requires communicating with multiple "stakeholders" in order
to keep things progressing forward and gain insight into the issues that
need to be resolved. At any rate I am probably not the best person to
write the code that is required.

However while other communities have been very supportive, the results
round here so far have been people ignoring the actual topic of
discussion, focusing on Android development or denial of the viability of
optimising PA so that PA and JACK will work together more reliably on the
OTHER Linux mobile platforms that run PA by default and in the process
better on the desktop too.

In regards to the combination of PA and JACK being a done deal,
unfortunately there are several issues that have been exposed through
recent tests that have been run on the current stable versions of JACK and
PA. The issues are all inside of PA but they can be fixed if there is a
consensus or interest from JACK developers for such an effort. The fixes
are unlikely to come from PA developers as it is not exactly in their
priority list (or personal interests) to put their time/effort into
optimisations specifically to enable PA to run more efficiently on top of
JACK. Apart from that, doesn't it strike you as fairly unprofessional if
we require users to run specific combinations of JACK + PA in order to get
a completely reliable and stable desktop audio system?

- There is a bug in jack source/sink which allows the buffer to grow
continuously
- There is an issue with realtime capabilities in jack source/sink that
needs to be debugged
- It would be useful to make several optimisations to PA to enable even
faster realtime processes like optionally bypassing the Stream Buffer
while JACK is running but that will require some major design changes to
the PA graph and also some threading work to split out control and audio.

I know there are lots of people who advocate disabling PA in order to use
JACK but what about all the people who don't or cannot do that? Surely
they are the majority when it comes to desktop users and absolutely the
majority when it comes to OTHER mobile platforms that use PA as the
default audio management system.

So unless we want to go with option 2 which is to add and maintain support
for Bluez, Murphy and PA API in JACK are there people willing to work on
the PA optimisations that have been identified and if so what would be the
motivator to make it viable? Should we be looking to the Linux Foundation
or other well funded organisations to support us in this process? Can we
do it ourselves with the motivation that we can sell our products on these
OTHER Mobile platforms that run PA as the default audio management system?
Are there people who want to do the work just because they feel the urge
to contribute to the greater good and make open source desktop audio as
good as it can possibly be like in the good ol days before Linux became
the most popular operating system on the planet and the GFC began when
people had plenty of time on their hands to do awesome shizzle just
because they felt like it with no financial motivator (or was that a dream
reality that never really existed anyway)?




--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Ralf Mardorf
In reply to this post by Bradley Justice
On Wed, 2013-10-16 at 12:02 -0700, Bradley Justice wrote:
> On Wed, Oct 16, 2013 at 1:25 PM, Ralf Mardorf wrote:
> >What do you call a latency that isn't good for pro-audio?
>
> In selling a previous product I found market resistance to any number
> above the 4 to 5 ms range.

IMO that's a reasonable value and as far as I know lower latencies are
achievable with iOS, seemingly with JACK too:

On Wed, 2013-10-16 at 20:17 +0200, Christian Schoenebeck wrote:
> JACK iOS (RIP) was configurable down to 2.9ms

Regards,
Ralf


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: JACK on mobile

Joakim Hernberg
In reply to this post by Patrick Shirkey
On Thu, 17 Oct 2013 13:13:40 +1100 (EST)
"Patrick Shirkey" <[hidden email]> wrote:

> of use for developers and users. This would also benefit desktop
> Linux users who run PA too (everyone running Gnome or KDE) and make
> the option of running JACK and PA at the same time a more reliable
> and efficient process.

For what it's worth.  I run KDE on Archlinux and haven't had PA
installed for years (seems like all/most packages are built with a PA
dependency nowdays, but I don't have the server component
running nor do I have it installed) .

KDE works perfectly fine with bare ALSA. I also sometimes use the ALSA
loopback together with alsa_in/out to connect KDE, Skype, Steam,
Wine, XBMC, etc to JACK, and that works perfectly fine too, (at low
latencies too if that is a requisite).  I also routinely run reaper and
all sorts of other windows plugins and virtual instruments using
Wineasio with jack at low latencies.

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
123