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

PrevNext  Index
DateWed, 16 Jan 2013 00:10:13 -0500
From ∴ triune . <[hidden] at gmail dot com>
ToPaul Sheean <[hidden] at gmail dot com>
Ccjack-devel <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPaul Sheean Re: [Jack-Devel] JACK in Chrome !!
Follow-UpPaul Sheean Re: [Jack-Devel] JACK in Chrome !!
Follow-UpPatrick Shirkey Re: [Jack-Devel] JACK in Chrome !!
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

1358313063.16678_0.ltw:2,a <CADcjGi6oa=OjUYO8NAXNuSu+fVemiK+AbSKRrjH0oc-bGbhofA at mail dot gmail dot com>