Re: jack2's dbus name

[Esben Stien]

Esben Stien <b0ef@...> writes:

Too hasty post here, and I need to correct myself;).

> Pulse is part of the GNOME framework, so all "gnome" app use a
> uniform framework to play sounds.

I mean gstreamer here.

> These sounds exit through pulseaudio,

You can of course configure gstreamer to use ALSA directly, but you're
missing out on many features that pulseaudio provides, then.

> pulse is the GNOME audio server

Well, not entirely true, but it should be.

> You don't want every god damn app in gnome to have support for the
> myriads of sound API's out there, do you?.

Right, we don't want that.

> it's part of the GNOME framework.

Right, I'm mixing up here, too. It's gstreamer that is part of
GNOME. Pulse still has a place on every system, though, cause it's a
better alternative than accessing ALSA directly. Of course, this is
only my opinion, but it's also a quantifiable truth;).

Sorry for the mix up.

--
Esben Stien is b0ef@e     s      a            
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e
           jid:b0ef@    n     n
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 16, 2009 at 4:34 PM, Esben Stien<b0ef@...> wrote:
> Right, I'm mixing up here, too. It's gstreamer that is part of
> GNOME.

gstreamer is not particularly related to GNOME. GNOME just happens to use it.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Esben Stien]

Lennart Poettering <lennart@...> writes:

> Because someone dropped me from the CC.

It would be nice if you subscribed to the JACK list.

JACK and Pulse has different areas covered and they supplement
each other very well, in my opinion.

Pulse has fixed very many problems related to ALSA applications and is
also working on getting OSS apps to work just as flawlessly. (For me,
atleast;)

I don't think there's any doubt that I'm a die hard JACK guy, but
Pulse does address current problems with legacy applications that use
ALSA and OSS directly. There's also alot of areas that Pulse covers,
that JACK doesn't deal with at all.

I'm still hoping for some kind of unification in the future.

JACK and Pulse needs to work nice together or we'll see lots of these
threads;)

--
Esben Stien is b0ef@e     s      a            
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e
           jid:b0ef@    n     n
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Esben Stien]

Paul Davis <paul@...> writes:

> gstreamer is not particularly related to GNOME. GNOME just happens
> to use it.q

Right, but haven't they sort of adopted it?. I mean, isn't it
gstreamer they say you should use for writing "core" GNOME apps that
should be part of GNOME?.

It's not like one GNOME app uses ALSA and another one uses JACK and
yet another use the Pulse API.

--
Esben Stien is b0ef@e     s      a            
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e
           jid:b0ef@    n     n
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[melanie-36]

Do you mean to say I can set up gstreamer to use ALSA and remove
pulse and I will still have my desktop sounds?

Melanie

Esben Stien wrote:

> Esben Stien <b0ef@...> writes:
>
> Too hasty post here, and I need to correct myself;).
>
>> Pulse is part of the GNOME framework, so all "gnome" app use a
>> uniform framework to play sounds.
>
> I mean gstreamer here.
>
>> These sounds exit through pulseaudio,
>
> You can of course configure gstreamer to use ALSA directly, but you're
> missing out on many features that pulseaudio provides, then.
>
>> pulse is the GNOME audio server
>
> Well, not entirely true, but it should be.
>
>> You don't want every god damn app in gnome to have support for the
>> myriads of sound API's out there, do you?.
>
> Right, we don't want that.
>
>> it's part of the GNOME framework.
>
> Right, I'm mixing up here, too. It's gstreamer that is part of
> GNOME. Pulse still has a place on every system, though, cause it's a
> better alternative than accessing ALSA directly. Of course, this is
> only my opinion, but it's also a quantifiable truth;).
>
> Sorry for the mix up.
>

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Lennart Poettering-8]

On Wed, 17.06.09 00:35, Melanie (melanie@...) wrote:

> Do you mean to say I can set up gstreamer to use ALSA and remove pulse
> and I will still have my desktop sounds?

Event sounds in GNOME are generated through libcanberra, not
GStreamer. So yes, if you set the libcanberra backend to ALSA then
event sounds are generated without PA.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 16, 2009 at 6:35 PM, Melanie<melanie@...> wrote:
> Do you mean to say I can set up gstreamer to use ALSA and remove pulse and I
> will still have my desktop sounds?

I have gstreamer setup to use JACK, and when i tried it with system
sounds just now as a test, it worked.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Lennart Poettering-8]

On Tue, 16.06.09 19:23, Paul Davis (paul@...) wrote:

>
> On Tue, Jun 16, 2009 at 6:35 PM, Melanie<melanie@...> wrote:
> > Do you mean to say I can set up gstreamer to use ALSA and remove pulse and I
> > will still have my desktop sounds?
>
> I have gstreamer setup to use JACK, and when i tried it with system
> sounds just now as a test, it worked.

Uh?

GNOME used to play event sounds with esd, and then we switched that
over to libcanberra, gst was never involved.

How exactly did you test that?

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 16, 2009 at 7:24 PM, Lennart
Poettering<lennart@...> wrote:

> On Tue, 16.06.09 19:23, Paul Davis (paul@...) wrote:
>
>>
>> On Tue, Jun 16, 2009 at 6:35 PM, Melanie<melanie@...> wrote:
>> > Do you mean to say I can set up gstreamer to use ALSA and remove pulse and I
>> > will still have my desktop sounds?
>>
>> I have gstreamer setup to use JACK, and when i tried it with system
>> sounds just now as a test, it worked.
>
> Uh?
>
> GNOME used to play event sounds with esd, and then we switched that
> over to libcanberra, gst was never involved.
>
> How exactly did you test that?

yes, oops, i went over it again and realized i was using the wrong
tester. sound events are indeed still silent, even though the "test"
of the "output route" works ok (in gnome-sound-properties, where
"Sound Events" is set to use a default config that routes via JACK).
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Dragan Noveski]

Dominique Michel wrote:

> I can use any linux application with JACK and this very simple setup:
>
> cat ~/.asoundrc
> # convert alsa API over jack API
> # use it with
> # % aplay foo.wav
> # use this as default
> pcm.!default {
>     type plug
>     slave { pcm "jack" }
> }
> # pcm type jack
> pcm.jackplug{
>     type plug
>     slave {pcm "jack"}
> }
>
> pcm.jack {
>     type jack
>     playback_ports {
> 0 alsa_pcm:playback_1
> 1 alsa_pcm:playback_2
> }
>     capture_ports {
> 0 alsa_pcm:capture_1
> 1 alsa_pcm:capture_2
> }
> }
>
> # oss will use the alsa to jack API by default
> @ test it with
> # % aoss mpg123 some.mp3
> pcm.dsp pcm.!default
>
> ############
>
> That's all. Almost, firefox with flash need jacklaunch:
>
> jacklaunch firefox
>
> #########
>  

this is awsome!! works for me too...no idea about dbus or pa, like to
use jackd for everything  (jack1 on this laptop here).
with this script even myspace&co. works here.
thanks!!

cheers,
doc
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[John Rigg-3]

On Tue, Jun 16, 2009 at 07:07:01PM +0200, Lennart Poettering wrote:
> If this is just a case of anti-D-Bus FUD, then for god's sake make the
> reserve logic compile-time optional. I am pretty sure that most
> distros will enable it, but the crackpots who detest D-Bus and PA can
> leave it disabled.

I can't see D-Bus or PA being useful (or even usable) in my recording
systems. That doesn't mean I hate them on principle, just that they are
likely to compromise the performance of the tools I rely on to do my job
as an audio engineer. No FUD here, just different requirements.

John
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[John Rigg-3]

On Tue, Jun 16, 2009 at 07:10:17PM +0100, Phil Rhodes wrote:
> I no longer have even the slightest idea what's being discussed here.

But you'll make a comment anyway.

> When I joined this list it was to find out if jack or any jack-related  
> software was capable of streaming audio over unreliable networks, such as
> wifi (the answer was then no and I believe remains no, but I'd love to be
> told otherwise).
>
> As it is, I stick around to unscientifically monitor the state of Linux  
> audio in the hopes of finding out when it's ready for the big time. My  
> feeling right now is "check again in ten years."

Are you referring to its usability for pro audio here
(this being a list for a pro audio app after all)?
Maybe someone should tell Midas and Harrison Consoles.

>
> http://matt.bottrell.com.au/uploads/Pics/linuxaudio.png

This diagram mostly consists of stuff that has no business being
on a pro-level DAW. It would be easy to produce an equivalent
for Windows or Mac if you're going to include the kitchen sink,
as has been done here.

There are no doubt problems for people who want normal desktop
audio and pro audio apps to coexist on the same system. This
thread shows that the jack developers are trying to make allowances
for these users, even though it's outside the main purpose of jack.
Would you complain to Digidesign if you installed Pro Tools HD and
it messed up the desktop sounds on your Mac?

John
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Dominique Michel-2]

Le Tue, 16 Jun 2009 19:10:17 +0100,
"Phil Rhodes" <phil_rhodes@...> a écrit :

> I no longer have even the slightest idea what's being discussed here.
>
> When I joined this list it was to find out if jack or any jack-related
> software was capable of streaming audio over unreliable networks, such as
> wifi (the answer was then no and I believe remains no, but I'd love to be
> told otherwise).
>
> As it is, I stick around to unscientifically monitor the state of Linux
> audio in the hopes of finding out when it's ready for the big time. My
> feeling right now is "check again in ten years."
>
> http://matt.bottrell.com.au/uploads/Pics/linuxaudio.png

If you are expecting nothing but are able to look at the things like they are,
you just will find that every progress is just marvellous. But, if you are
expecting big things (like the big time, or wharever), your expectations will
make you blind and fully unhappy with everything.

As already explained in this thread, in order to understand how things are
working, one will have some homework to do: RTFM. And if it is not enough, it
is plenty of linux forums, wikis and email lists. And also google that is very
good with stuffs like linux.

Ciao,
Dominique

> -P
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Dominique Michel-2]

Le Wed, 17 Jun 2009 06:22:37 +0200,
Dragan Noveski <perodog@...> a écrit :

> Dominique Michel wrote:
> > I can use any linux application with JACK and this very simple setup:
> >
> > cat ~/.asoundrc
> > # convert alsa API over jack API
> > # use it with
> > # % aplay foo.wav
> > # use this as default
> > pcm.!default {
> >     type plug
> >     slave { pcm "jack" }
> > }
> > # pcm type jack
> > pcm.jackplug{
> >     type plug
> >     slave {pcm "jack"}
> > }
> >
> > pcm.jack {
> >     type jack
> >     playback_ports {
> > 0 alsa_pcm:playback_1
> > 1 alsa_pcm:playback_2
> > }
> >     capture_ports {
> > 0 alsa_pcm:capture_1
> > 1 alsa_pcm:capture_2
> > }
> > }
> >
> > # oss will use the alsa to jack API by default
> > @ test it with

Oops!

# test it with

would be better.

> > # % aoss mpg123 some.mp3
> > pcm.dsp pcm.!default
> >
> > ############
> >
> > That's all. Almost, firefox with flash need jacklaunch:
> >
> > jacklaunch firefox
> >
> > #########
> >  
> this is awsome!! works for me too...no idea about dbus or pa, like to
> use jackd for everything  (jack1 on this laptop here).
> with this script even myspace&co. works here.
> thanks!!

You are welcome. It is more on this setuo
here: http://en.gentoo-wiki.com/wiki/JACK

Ciao,
Dominique

>
> cheers,
> doc
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Ralf Mardorf]

Melanie wrote:
> This is not about getting those things at the same time. I don't want
> desktop sound while DJing. But I don't want to have to uninstall
> desktop sound permanently just to make DJing possible.
>
> Melanie

You're right with the wish to have this option, but at atm there seems
to be more serious issues that needed to be solved for rt-audio and MIDI.

--
http://www.dailywav.com/1002/beginning.wav

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Marc-Olivier Barre-3]

Hi,

You seem to ask for some feedback, so I'll try to give you some even if
it's not worth much...

On Tue, 16 Jun 2009 11:26:05 +0200, Stéphane Letz <letz@...> wrote:
> I have to say that I'm quite worried and tired about what is going on.  
> I've put a *lot* of time and energy in the past 2 years to try to keep  
> things in a good shape into the JACK2 source tree, trying to integrate  
> contributions/improvements from a lot of people (even if the DBus work  
> was probably not integrated the way it should have been..) and in the  
> hope it would finally reach a stable and robust state to be considered  
> the "new JACK reference implementation".

And we're certainly all grateful for that ! jack2 is a wonderful piece of
software.

> Even if there is no official fork of the source code, we are not far  
> from that. We at Grame cannot afford to put more time into trying to  
> solve (probably without real effect..) those endless political issues.  
> I had a discussion with Yann about the situation and the result is  
> that we will continue to work on JACK(2) only if the overall situation  
> can be clarified.

Understandable

> The latest discussion about JACK/DBus again shows a very interesting  
> effect: a *lot* of people are ready to argue, we get *tons* of  
> commenting mails, but when we shift on real *technical* proposals then  
> almost nobody takes time to only comment, test and improve the  
> sucessives proposal that have been sent.
>
> I've sent several mail on the list ("Keeping "guardians" and "rebels"  
> on the same boat", "Status of server control plug-ins branch"...) and  
> I am still waiting for *real constructive* feedback : Nedko the main  
> JACK/DBus contributor is supposed to say *something* please...

I'm not Nedko, but since I'm one of the guys with a piece of software
making use of the Dbus interface... Here goes:

The last proposal I saw was this one :
http://www.grame.fr/~letz/jackcontrol2.pdf. At first sight, I'd say it
works for me, just like the plugin idea and many of the other proposals
that have been made (Nedko had a good one too). And that's kind of my
problem... There's been so much proposals, counter proposals, etc. that at
one point I got lost. Really lost. I do not know how the right solution
should look like. All I know is that as far as functionalities are
concerned, the dbus interface does a good job. What went wrong is it's
integration and I would find it a shame to drop it just because of that.
So let's just stick to whatever design choice seems fit for Grame and make
it look good. You (Stephane and Grame in general) are in a position to play
dictator here, JACK2 is your baby. I'll be more than happy to help test and
improve whatever technical solution would seem fit.

During the past year, I failed to see how the current dbus design was
wrong. What I've learned from that is that testing the dbus interface alone
isn't good enough. I'll certainly include more scenarii in my testing
process, and eventually document them to make then reproducible. Frankly
speaking, I will probably not be able to do much more than testing. My
career is a big mess right now, I'm not sure what's gonna happen to me in
the near future (just got dumped from nokia).

All this to say: I know I'm not helping much. Sorry... But I'm trying :)

> The JACK community is surely quite "fragile", contributing developers  
> are very few.  We cannot afford to break it up into even smaller  
> pieces. I guess it is time for the JACK community to mature a bit and  
> find better ways to structure it's work, otherwise we'll end up with a  
> even bigger "Linux audio is a mess" state...
>
> Do we really want that?

Sure, we don't !

--
Marc-Olivier Barre
XMPP ID : marco@...
www.MarcOChapeau.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Ralf Mardorf]

Paul Davis wrote:
> ok. i never use desktop sounds, and there is no 64 bit flash. that
> would explain my experience.
>  

Do you mean 64 bit proprietary flash player? There is one! I don't use
desktop sounds too, but run a 64 bit proprietary flashplayer,
http://linux.softpedia.com/get/Internet/HTTP-WWW-/Adobe-Flash-Player-for-64-bit-Linux-42958.shtml.

--
http://www.dailywav.com/1002/beginning.wav

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jörn Nettingsmeier-5]

Phil Rhodes wrote:

> I no longer have even the slightest idea what's being discussed here.
>
> When I joined this list it was to find out if jack or any jack-related
> software was capable of streaming audio over unreliable networks, such
> as wifi (the answer was then no and I believe remains no, but I'd love
> to be told otherwise).
>
> As it is, I stick around to unscientifically monitor the state of Linux
> audio in the hopes of finding out when it's ready for the big time. My
> feeling right now is "check again in ten years."
>
> http://matt.bottrell.com.au/uploads/Pics/linuxaudio.png

funny graph. this is how open source works :)
as you will have noticed, this is also how closed source software works,
only that someone else decides for you which subset of the available
nodes you can use. pick your poison.

to amuse you during your ten-year waiting period, try netjack from the
current jack svn for low-latency, or use ices-kh to stream jack via
icecast if you can live with latency of 1-3 seconds.


--
Jörn Nettingsmeier

Verantwortlicher für Veranstaltungstechnik

Audio and event engineer
Ambisonic surround recordings

http://stackingdwarves.net
[phone]

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Ralf Mardorf]

Coders shouldn't waste their time with this mail, please skip it.

Jörn Nettingsmeier wrote:

> Phil Rhodes wrote:
>  
>> [snip]
>>
>> http://matt.bottrell.com.au/uploads/Pics/linuxaudio.png
>>    
>
> funny graph. this is how open source works :)
> [snip]
>  

This is how FLOSS didn't work for e.g. musicians, who are nothing more
than musicians. Some musicians are lucky if they know how to turn on the
computer and to use a desktop environment. They need to learn how to use
a sequencer and hard disk recorder and even because they aren't audio
engineers, how to use a mixing console, effects etc. and Linux mixing
consoles aren't 'normal' mixing consoles, it's not only that aux
channels are missing. Composing an opera should become more easy when
using the computer, but it can become a Google-orgy, a PITA instead of a
helping tool. Using a piano, you don't have to learn how to build a
piano, using Linux you need to know how to build a computer that is fine
with Linux, how to build a Linux that is fine for pro-audio and after
you have learned this, Linux still has got it's pitfalls and handy-caps.
Okay, there's still the 'libre' not to use Linux and I guess a lot of
people know that, without the recommendation not to use Linux and that
causes a dilemma, e.g. a lot of hardware isn't fine with Linux, because
people choose not to use Linux and so the companies don't need to take
care about Linux.

Nobody can google to accomplish the required self-responsibility, if he
don't know what he has to search for by Google and how should a user
know about this?

I guess the 'libre' to choose between e.g. several
consumer-audio-thingummies only will confuse the simple user who is just
a musician. Just writing a script for init.d etc., so easy to learn for
self-responsible people, isn't so easy for musicians. Musicians don't
know responsibility, see
http://med.stanford.edu/clinical_trial/brain_of_musicians/sex_drugs_and_rock_and_roll_study/complete_loss_of_responsibillity/the_no_self-responsibillity_effect.

It's fine to have the 'libre' to choose between many ways and it's fine
that it's allowed to program the 100th audio-server etc., but for
musicians and pro-rt-audio-and-midi it would be more satisfying if the
coders will spend their time in enabling a stable and jitter-free
rt-audio-midi for more and more hardware combinations, without taking
care for consumer applications. They should have the 'libre' to do or
not to do this. I guess it shouldn't be a problem to run a restricted
pro-audio Linux and people who like to have one installation for
professional and  consumer needs, it might be an alternative to run a
special consumer install on a virtual machine in this Linux installation
with the complete 'libre' of running 1001 different audio servers, maybe
this also won't work that easy.

The 'libre' to choose between many ways only is an advantage if it's
easy to do and if at least the half of the ways will be fine.

Maybe this is the main problem for Linux and life in any way, we did
start with a bad move:

http://www.dailywav.com/1002/beginning.wav

Ralf

--
http://www.dailywav.com/1002/beginning.wav

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

On Mon, Jun 15, 2009 at 04:37:09PM +0200, Lennart Poettering wrote:

> On Mon, 15.06.09 15:34, Stéphane Letz (letz@...) wrote:
>
> > What I'm personally trying to achieve is a more "flexible" way (compared
> > to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus
> > control component can be coded as a "plugin" to be possibly loaded in
> > JACK server process. This new plugin model allows to keep basically 2
> > ways of using JACK server :  the "old way" (typically starting the jackd
> > server using Qjackctl control application) or the new way using DBus
> > based control applications (after the DBus control plug-in has been
> > properly loaded in JACK server).  (Keeping the "old-way" is also
> > important on others platforms JACK2 runs on.)
>
> Distributions will certainly enable the D-Bus code in JACK if they
> ship it. So, I have no problem with depending on a dbus'ified jack for
> this logic to work. After all crazy folks who disable the dbus support
> in jack because they think it's an abomination probably think that PA
> is an even worse abomination anyway, so there's not need to cater for
> them.
>
> > If this new "control plugin" model is finally accepted by JACK  
> > community, then we'll distribute/package JACK2 compiled with the 1)  
> > option, so that it (at least) cooperates with PulseAudio. But 2) would  
> > then be optional, so PA can not rely on the DBus control plug-in to  
> > always be present.
> >
> > The 1) code uses  "org.freedesktop.ReserveDevice1.AudioXX" name, and 2)
> > optional DBus plugin uses "org.jackaudio.service" name. If we want to
> > implement your proposal, the we would need to request another name in  1)
> > part, is that correct?
>
> I think org.jackaudio.service should be fine. I don't think this
> automatic logic needs to work on non-D-Bus jack builds. As I see it
> you don't need to make any changes on jack for this to work. All I
> need is the guarantee that by the time the service name is registered
> on the bus jack is fully accessible. Otherwise we had a race here: if
> PA looks for the org.jackaudio.service name to appear on the bus and
> then imemdiately connects to it while jack isn't fully accessible yet
> PA would fail.

the existence of org.jackaudio.service object does not guarantee,
that jackd is connectable.

i guess we need a signal, which tells that a server has been started,
but i leave this to the dbus guys.

my primary concern is to have the pa jack backend fixed.
lennart himself said its a TOY. and it really is.

i dont really understand why it works, but its pretty broken, for sure.


static int jack_process(jack_nframes_t nframes, void *arg) {
    struct userdata *u = arg;
    unsigned c;
    jack_nframes_t frame_time;
    pa_assert(u);

    /* We just forward the request to our other RT thread */

    for (c = 0; c < u->channels; c++)
        pa_assert_se(u->buffer[c] = jack_port_get_buffer(u->port[c], nframes));

    frame_time = jack_frame_time(u->client);

    pa_assert_se(pa_asyncmsgq_send(u->jack_msgq, PA_MSGOBJECT(u->sink), SINK_MESSAGE_RENDER, &frame_time, nframes, NULL) == 0);
    return 0;
}


it needs to be decoupled using a ringbuffer.
and maybe pulse should be running with a higher blocksize than jack ?

>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org