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

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

1358309130.10669_0.ltw:2,a <64987.5.12.188.139.1358309114.squirrel at boosthardware dot com>