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

On Wed, January 16, 2013 4:00 pm, Paul Sheean 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".
>

It's not political. It's just that very few people are paid to work on
this stuff and they have their priorities defined for them.

In this case where you want to easily be able to switch between consumer
and pro cards over USB the apparently normal experience is defined by the
OSX integration method. Whereas the normal Linux experience is that
prosumer audio is a complete PITA. That is already working ootb and has
been for the past several years ;-)

In situations like this where the solution is obvious it is up to the
person who feels the itch to scratch it. That is the Open Source way. The
methods at your disposal are to /harrass/ the *right* developers until
they decide it is easier to fix the problem than to argue about it or to
write a patch and submit it for inclusion. Join the pulse list and make
your case. If you don't do it you can't expect anyone else to do it for
you. It takes people like you to make an effort to get the message out to
the right people.

I find it sad and incredibly frustrating that an organisation like Google
prefers to pay people to reinvent open source audio causing significant
pain and suffering rather than contribute to the existing infrastructure
so everyone can benefit from their funded efforts.




>
> 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
>>
>


--
Patrick Shirkey
Boost Hardware Ltd

1358313600.17527_0.ltw:2,a <49347.5.12.188.139.1358313588.squirrel at boosthardware dot com>