Re: [Jack-Devel] JACK in Chrome !!

PrevNext  Index
DateWed, 16 Jan 2013 16:17:24 +1100
From Paul Sheean <[hidden] at gmail dot com>
To"∴ triune ." <[hidden] at gmail dot com>
Ccjack-devel <[hidden] at lists dot jackaudio dot org>
In-Reply-To∴ triune . Re: [Jack-Devel] JACK in Chrome !!
I hope so. If not then I hope that the two work together better.


On 16 January 2013 16:10, ∴ triune . <[hidden]> wrote:

> Maybe this will happen if CRAS is ported/extracted from ChromiumOS and
> becomes part of the major distros replacing both jack and pulseaudio while
> at the same time merging them?
>
>
> On Wed, Jan 16, 2013 at 12:00 AM, Paul Sheean <[hidden]> wrote:
>
>> I agree that it is *technically* easier to fix the problem in the current
>> system(s), but if it is such a political challenge then perhaps the more
>> difficult technical path (writing a new underlying system) makes more
>> sense? I have no real preference either way, I just hope that we one day
>> get to the point where this kind of thing is not just possible but the
>> normal experience "out of the box".
>>
>>
>> On 16 January 2013 15:54, Patrick Shirkey <[hidden]>wrote:
>>
>>>
>>> On Wed, January 16, 2013 3:38 pm, Paul Sheean wrote:
>>> > I am aware of the ability for pulse to be wired through jack, but as
>>> far
>>> > as
>>> > I am aware jack does not play well in a "consumer" setup - plugging in
>>> and
>>> > out sound cards etc. If it worked correctly in this case then I think
>>> it
>>> > would be a great default.
>>> >
>>> > An example (on a laptop for instance):
>>> >
>>> > soundcard1: onboard with builtin speakers
>>> > soundcard2: onboard with headphones (autodetected)
>>> > soundcard3: usb or firewire interface
>>> >
>>> > laptop boots up and all sound is routed through soundcard1. user plugs
>>> in
>>> > headphones and (optionally) all sound routes through headphones. user
>>> > starts ardour and works on project. user wants to record a guitar and
>>> > plugs
>>> > in soundcard3. (optional) popup asks user if they wish to use newly
>>> > detected card as the primary device. if so then all sound is now routed
>>> > through soundcard3. if not then soundcard3's inputs and outputs are
>>> > available in the list.
>>> >
>>>
>>> This integration is completely solveable with pulse and jack. The problem
>>> is that neither the jack devs or the pulse devs are interested in
>>> spending
>>> the time to write the code for this specific use case and run the test
>>> procedures to make sure that it is consistently supported.
>>>
>>>  JACK seeks only to provide support for pro audio devices. Pulse seeks
>>> only to provide support for consumer devices.
>>>
>>> The people who want support for consumer and pro devices at the same time
>>> are left to figure out things for themselves and provide patches to make
>>> life easier for everyone.
>>>
>>> In this specific use case you would be best served by joining the pulse
>>> audio mailing list and making your case there. Unfortunately nothing will
>>> get done until enough people jump up and down about it or someone submits
>>> a patch that is acceptable to pulse devs.
>>>
>>> However that should not be a reason for ChromeOS to rewrite the Linux
>>> Audio Stack again. Actually fixing this problem will be a hell of a lot
>>> less effort than writing a whole new audio stack. It is mostly about
>>> convincing the pulse team that consumers want to have a fully integrated
>>> JACK experience too. Currently the pulse position is if you want to use
>>> JACK you should figure out how to make it work on your distro. The JACK
>>> position is that as long as pulse can be easily disabled everything is
>>> fine.
>>>
>>>
>>>
>>>
>>> > obviously there are issues with sync etc with multiple cards at once on
>>> > one
>>> > application, so either this would have to be warned against or only
>>> > accessible by manually patching things. this sounds complex but is
>>> almost
>>> > identical to how OSX does it. it saves a lot of hassle and means that a
>>> > "consumer" build or distro is also ready to go as a pro setup (as OSX
>>> is
>>> > ready to go without needing to install various packages to get 'pro
>>> audio'
>>> > working).
>>> >
>>> > note that this isn't an 'OSX is better than Linux' post - i use linux
>>> > almost exclusively other than for some audio work that requires certain
>>> > virtual instruments.
>>> >
>>> >
>>> > On 16 January 2013 15:05, Patrick Shirkey
>>> > <[hidden]>wrote:
>>> >
>>> >>
>>> >> On Wed, January 16, 2013 2:40 pm, Paul Sheean wrote:
>>> >> > I don't know. I think there is a definite advantage to having an
>>> audio
>>> >> > server that can cover both Jack and PulseAudio use cases. I do think
>>> >> that
>>> >> > this is one of the areas that OSX has it right. I love Jack but it
>>> >> would
>>> >> > be
>>> >> > nice if it's features were "always on". By this I mean if that this
>>> >> new
>>> >> > audio server (or a modification of Jack) could be run in the
>>> >> background
>>> >> at
>>> >> > all times then I think that pro audio on linux will be much more
>>> >> flexible
>>> >> > and simple.
>>> >> >
>>> >> > In OSX I can run Jack on top of CoreAudio and still have
>>> functionality
>>> >> of
>>> >> > non-jack applications without restarting them or wrapping them into
>>> >> Jack
>>> >> > at
>>> >> > the same time. If I close Jack then those applications are still
>>> >> working.
>>> >> > If I decide to pipe the output of one of those applications into a
>>> >> Jack
>>> >> > application then I can do that as well, without the application
>>> >> needing
>>> >> to
>>> >> > be written in a special way to take advantage of it (just using
>>> >> > CoreAudio).
>>> >> >
>>> >> > If there was a way for Jack to be set up like this reliably (ie.
>>> major
>>> >> > distributions being able to and confident to have this enabled by
>>> >> default)
>>> >> > then there would be no need for such a thing.
>>> >>
>>> >> It is already possible to route pulseaudio through jack. The system
>>> will
>>> >> automatically reconfigure itself if you have the correct pulse-jack
>>> >> configuration.
>>> >>
>>> >> Fedora gets this right ootb but Debian and Ubuntu packagers have made
>>> it
>>> >> an optional manual configuration step.
>>> >>
>>> >> My suggestion is to write a blog post about why Ubuntu and Debian
>>> >> packagers don't see the obvious benefit of making pulse and jack play
>>> >> together nicely ootb.
>>> >>
>>> >> The other option is that the pulse team just hardwire this
>>> functionality
>>> >> into pulse but that means they have to add testing pulse-jack
>>> >> integration
>>> >> into their QA procedures. However as long as nothing changes
>>> >> dramatically
>>> >> in the existing system configuration this should just be a minor test
>>> >> procedure to run before a major release.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> > My understanding of Jack,
>>> >> > however is that it is not flexible enough to do this and cope with
>>> >> dynamic
>>> >> > adding and removing of sound devices etc. Perhaps something from
>>> >> > PulseAudio
>>> >> > can be pulled out into a (say) PulseAudioCore or something similar
>>> and
>>> >> > then
>>> >> > both PulseAudio and Jack can live on top of it? I assume from the
>>> >> amount
>>> >> > of
>>> >> > hate that PulseAudio gets that this wouldn't please too many people
>>> >> > though.
>>> >> >
>>> >> > I think the *idea* of a low level library that can satisfy both
>>> sides
>>> >> (in
>>> >> > the way CoreAudio does for OSX) and allow simultaneous operation is
>>> a
>>> >> > great
>>> >> > one though.
>>> >> >
>>> >> >
>>> >> > On 16 January 2013 14:26, Patrick Shirkey
>>> >> > <[hidden]>wrote:
>>> >> >
>>> >> >>
>>> >> >> On Wed, January 16, 2013 9:39 am, ∴ triune . wrote:
>>> >> >> > You've almost capture what I was about to add, Sam:
>>> >> >> >
>>> >> >> > In ChromeOS, the only thing talking to the sound card is
>>> Chrome...
>>> >> you
>>> >> >> > can't install any local apps (apps in the traditional sense...
>>> not
>>> >> web
>>> >> >> > apps). So, there is no contention between different apps, just
>>> >> Chrome.
>>> >> >> At
>>> >> >> > the moment, all they are doing is having Chrome talk to the ALSA
>>> >> >> driver.
>>> >> >> > So, this is a step up from that very simple implementation.
>>> >> >> >
>>> >> >>
>>> >> >> I agree with Stephane on thins one. What is with Google and having
>>> to
>>> >> >> reinvent the Linux Audio Stack. They did it with Audio Flinger with
>>> >> the
>>> >> >> result that Android is still useless for pro audio applications and
>>> >> now
>>> >> >> they want to do it with ChromeOS too by effectively rewriting
>>> >> pulseaudio
>>> >> >> and JACK.
>>> >> >>
>>> >> >> These guys are really taking the piss.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> > On Tue, Jan 15, 2013 at 5:33 PM, Sam Mulvey <[hidden]> wrote:
>>> >> >> >
>>> >> >> >>
>>> >> >> >> On Jan 15, 2013, at 2:30 PM, Stéphane Letz wrote:
>>> >> >> >>
>>> >> >> >> I really don't see the point.. It seems to me that their need is
>>> >> >> exactly
>>> >> >> >> the purpose of PulseAudio no? Moreover if their audio server is
>>> >> going
>>> >> >> to
>>> >> >> >> "take the audio card" (possibly a exclusive manner right?) how
>>> >> other
>>> >> >> >> audio
>>> >> >> >> applications (PA based or JACK based...) are going to work at
>>> the
>>> >> >> same
>>> >> >> >> time? Or do they want this new audio server to completely
>>> replace
>>> >> >> >> everything? A new audio API (!?!)
>>> >> >> >>
>>> >> >> >> Hum....
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> If this is the ChromeOS in the new chromebooks, I think the idea
>>> >> is
>>> >> >> that
>>> >> >> >> there aren't going to be a lot of applications requesting the
>>> >> sound
>>> >> >> >> card,
>>> >> >> >> and most of it is going to be stuff written for ChromeOS.    For
>>> >> the
>>> >> >> >> most
>>> >> >> >> part, ChromeOS is just enough of an operating system to run the
>>> >> >> browser.
>>> >> >> >>
>>> >> >> >> -Sam
>>> >> >> >>
>>> >> >> >> 
>>> >> >> >> Jack-Devel mailing list
>>> >> >> >> [hidden]
>>> >> >> >>
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> ∴*triune.*
>>> >> >> >> <
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
>>> >> >> > 
>>> >> >> > Jack-Devel mailing list
>>> >> >> > [hidden]
>>> >> >> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Patrick Shirkey
>>> >> >> Boost Hardware Ltd
>>> >> >> 
>>> >> >> Jack-Devel mailing list
>>> >> >> [hidden]
>>> >> >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Patrick Shirkey
>>> >> Boost Hardware Ltd
>>> >> 
>>> >> Jack-Devel mailing list
>>> >> [hidden]
>>> >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>> >>
>>> >
>>>
>>>
>>> --
>>> Patrick Shirkey
>>> Boost Hardware Ltd
>>> 
>>> Jack-Devel mailing list
>>> [hidden]
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>>
>>
>>
>> 
>> Jack-Devel mailing list
>> [hidden]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>>
>
>
> --
> ∴*triune.*
>
PrevNext  Index

1358313494.17375_0.ltw:2,a <CAA9fWniVsRxzCo64tMT1bNOfY5LZBxhakQVi51PGDc7hakU75A at mail dot gmail dot com>