Re: jack2's dbus name

[Dominique Michel-2]

Le Mon, 15 Jun 2009 22:55:01 -0400,
Paul Davis <paul@...> a écrit :

> On Mon, Jun 15, 2009 at 10:44 PM, Jacob Meuser<jakemsr@...>
> wrote:
> >
> > maybe that is exactly the problem?  jack is for pro-audio, right?
>
> whether or not i agree with this is irrelevant. distributions are
> pushing PulseAudio in front of users. users want to use JACK. they
> collide. users are unhappy.

This is one of the reasons why I am using gentoo. I can put "-pulseadio" into
my USE flag and get ride of PA.

> our job: make these users happy WITHOUT making fons and other similar
> users unhappy.
>
> > shouldn't a pro know when jack needs to be started and other
> > audio device users stopped?
>
> most people who want to run audio software don't have a clue about how
> this all works.
>
> >why not just have jackd run on top
> > of pulse, or vice-versa?  why would pulseaudio even exist in
> > a pro-audio setup?
>
> in a real pro-audio setup, pulseaudio would play no role and would
> likely not be installed. but thats not the sort of system that the
> VAST majority of people using JACK and JACK enabled software will be
> using. if that is not true today, as PulseAudio starts to spread, it
> will be true tomorrow.
>
> > basically, why is complexity being added to jack to deal with
> > desktop usage issues?  maybe because you yourself said jack backends
> > should not be added to "desktop" applications, that that job
> > is for pulse?
>
> Pulse has a JACK backend. Already. It works. If the user knows what
> they are doing, they will use it and be happy. But many users do not
> know what they are doing, and instead just suffer frustration when
> something they rightfully expect should work simply fails to work and
> for no reason they can discern.
>
> Fixing this issue should not compromise the situation for users who DO
> know what they are doing. But just because some people understand how
> it all works, and what to do and what not to do does not mean that we
> should stop working on behalf of those who don't.
>
> Finally, yes, its possible that some future solution to the mess that
> is Linux Audio might involve solutions that are more integrated that
> "PulseAudio and JACK co-existing". But such solutions do not exist at
> present, are not known to be planned and offer nothing to help the
> problems people face right now.
>
> --p
> ____________

I give PA a try it was a few months ago. I even done some kind of Howto with my
experiment on the gentoo pro-audio overlay's wiki. What I can say here is that
PA is much more complicated to setup than JACK, and that for a less good
result than with JACK.

This is why I just don't understand why most distibutions will force their
user to use PA when they have a much simpler solution with JACK.

And more: for a desktop use, it is absolutely not needed to archive real time
latencies with JACK, so any recent distribution kernel will do the job with
JACK.

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

#########

The best things with this setup is that even flash with firefox on my amd64 box
is 100% stable and reliable. I cannot say the same with flash + firefox and
any other sound server (even ALSA without JACK).

As electronic engineer with a lot of experience into repair and development,
I know one thing: If it is 2 ways to archive the same result, a complicated one
and a simple one, the simple one will work much better on the long run. So
please, keep JACK simple to setup and use.

It is just my 2 cents contribution as JACK user.
 
And thank you all for the good job done with JACK.

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

[Fernando Lopez-Lezcano]

On Tue, 2009-06-16 at 07:52 -0400, Paul Davis wrote:

> On Tue, Jun 16, 2009 at 5:01 AM, Fons Adriaensen<fons@...> wrote:
> > On Mon, Jun 15, 2009 at 10:12:14PM -0400, Paul Davis wrote:
> >
> >> You'd prefer that we spend whatever development time we have for JACK
> >> on *another* plugin system for the ALSA backend, or that we just do
> >> the simple thing and provide ./configure --with-alsa-dbus-negotiation
> >> so that distributors can make this work if they are building a package
> >> that is intended to run on a PulseAudio-equipped machine?
> >
> > Even more simple solutions that will take even less of
> > your time:
> [MUNCH]
> > 2. Run Jack from a script that talks in whatever
> > civilised (dbus ?) or uncivilised (killall) way
> > to PA, runs jackd, waits for it to terminate,
> > restarts PA.
> > Lots of programs today are run from scripts like that.
> > It's completely invisible to the naive user and remains
> > easily run-time configurable for the more savvy ones.
>
> whose responsibility is it to create such a script?

The distribution packagers would do that (that would be me). I think
there is one distro at least (can't remember which one) that already
uses this approach. _Very_ simple. The jack tarball could include an
example script.

You can use pasuspender which is already there, or add some other dbus
notification system to pa if you want to go that way and use that. If pa
is not installed pasuspender will not be there and the script can check
for that easily. If you use dbus I presume the dbus notifier will return
an error if pa is not installed and the script can check for that as
well. I'm sure it would not be as easy, lotsa error checking involved to
make it more foolproof but the concept is really simple.

-- Fernando


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

[Fernando Lopez-Lezcano]

On Tue, 2009-06-16 at 10:56 -0400, Paul Davis wrote:

> On Tue, Jun 16, 2009 at 11:53 AM, Esben Stien<b0ef@...> wrote:
> > Melanie <melanie@...> writes:
> >
> >> I found out the hard way that uninstalling pulseaudio is not an
> >> option on that distro.
> >
> > I don't understand why this isn't crystal clear. Pulse is part of the
> > GNOME framework, so all "gnome" app use a uniform framework to play
> > sounds. These sounds exit through pulseaudio, which allows you to
> > choose backends, such as ALSA or JACK.
>
> This is a bit misleading. PulseAudio is, to this very day, explicitly
> noted to be *NOT* an API that applications should use for audio I/O.
> Instead it is a system to gather, collect, manage and do other cool
> stuff with whatever APIs the application *are* using. Consequently, PA
> is no more a uniform framework for apps to play sound inside GNOME
> than JACK is uniform framework for apps to play sound on OS X. It
> works, but it is actually not required by any apps other than those
> that are actually part of PA. I de-installed PA from my Fedora 10
> systems and had no issues at all, as i expected.

If I build the proposed jack with the --use-dbus-to-cooperate-with-pa
flag it should still be possible to do that, right? (ie: remove pa
without removing jack and all its dependencies with it).

And if I run the jack compiled with the --use-dbus-to-cooperate-with-pa
flag and dbus is not running for whatever reason, then after a (short?)
timeout jack keeps going as if nothing had happened, right?

-- Fernando


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

[Michael Taht]

Esben Stien escribió:
> If pulse doesn't allow itself to be detached from the audio device,
> then this must of course be fixed, cause that's stupid. I never have
> encountered this problem, cause I always run pulse on top of JACK.
>  
Pulse grabs all audio interfaces by default. It would be nice if I could
just give it control of my internal sound card, and leave my pro sound
card alone.
>
> Because it's part of the GNOME framework. I think it makes a lot of
> sense, though.
Pulse has one huge advantage over jack, in that it allows systems to
suspend processing and go into a sleep state. This is very important on
laptops and in an al gore dominated world, desktops. I would like it if
jack applications could suspend, somehow.
> Pulse and JACK currently handles different needs, but
> for me atleast, they cooperate very nicely. After reading all these
> mails, it's obvious that it doesn't work nicely for everybody and this
> needs to be addressed.

I have been unable to get pulse and jack to co-exist for very long on
one machine, but I haven't tried doing it recently. When last I tried:

A) Eventually jack would crash, taking pulse with it, generally
requiring a reboot
B) I would need to work at a different sample rate (I record at 44.1 and
96khz) and, see, A....
C) I heartily disliked the sound of the default resampler in pulse

(lest you think I am merely complaining, I have been working on a sped
up, SSE-enabled version of libsamplerate for some time now, as a
solution to the problem I have the skills to address)

> I run my own distro, so I always set up things
> my own way and make sure they work for my needs. Probably why I don't
> experience all the issues you all see
I would like it if a drummer (insert random drummer joke here) could sit
down, install a music specific distro of linux, create music and play
mp3s, have flash "just work"...

Tried that recently on my drummer.
 
It really is a heck of a learning wall to climb...

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

[Fernando Lopez-Lezcano]

On Tue, 2009-06-16 at 11:26 +0200, Stéphane Letz wrote:

> It is maybe time to clearly express our position at Grame. The  
> following is part of a mail I've sent to Paul some weeks ago.
>
> 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".

I would like to make explicit my support and gratitude for the enormous
effort that has gone into jack2. I use it as the default since Fedora 10
in Planet CCRMA. For quite a while it was the _only_ option IMHO as
jack1 was a bit unstable :-)

So, keep up the good work and sorry for all the noise. Don't get
discouraged, your work is very very much appreciated!

-- Fernando


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

[Rob Fell-2]

Mike Taht wrote:

> Esben Stien escribió:
>  
>> If pulse doesn't allow itself to be detached from the audio device,
>> then this must of course be fixed, cause that's stupid. I never have
>> encountered this problem, cause I always run pulse on top of JACK.
>>  
>>    
> Pulse grabs all audio interfaces by default. It would be nice if I could
> just give it control of my internal sound card, and leave my pro sound
> card alone.
>  

I'm in the same boat, and I'd very much like to 'blacklist' PA from
attempting to use my pro card.

Other than that PA is working for me (though I have other issues with
UbSt 9.04).

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

[Lennart Poettering-8]

On Tue, 16.06.09 16:35, Stéphane Letz (letz@...) wrote:

>> On Tue, Jun 16, 2009 at 6:49 AM, Paul
>> Davis<paul@...> wrote:
>>
>>> waking up this morning, it occured to me that the real place for this
>>> device acquire/release negotiation is in ALSA, but that's another
>>> story altogether.
>>
>> The same idea had occurred to me, just a few minutes before reading
>> your message.
>>
>> Since ALSA manages the resources to be shared, it should provide a
>> better arbitration mechanism.  This introduces no new dependencies,
>> since all potential sharers are ALSA clients already.
>
> So Lennart, what do you think of that?

I don't agree. This kind of application cooperation needs to happen at
a very high level, as part of the user session, otherwise you get into
all kinds of messy security/DoS issues. OTOH ALSA is a rather
low-level library.

Also, the mapping between snd_pcm_t and and rd_device is not 1:1 and
the relation can only be known by the application. For example in PA
some ways to open two snd_pcm_t's of the same device make sense, but
others do not. i.e. the locking of a device is orthogonal to the
actual snd_pcm_t's and would hence require introduction of a
completely independant context object type in ALSA, which of course
questions the whole point of the story: if this is in the API seperate
from snd_pcm_t and everything else in ALSA, why have it part of ALSA?

Finally, this is basically just a contract between PA and JACK, the
number of other applications where this logic might be valid or needed
is next to zero. No need to make this much more public than it
currently is.

I am firmly against moving this into ALSA or any real library
API. I don't see what could be gained through this.

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.

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

[Phil Rhodes]

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

-P

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

[Paul Davis]

On Tue, Jun 16, 2009 at 2:10 PM, Phil Rhodes<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

thanks. that's a deeply helpful contribution to the problem.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Phil Rhodes]

> thanks. that's a deeply helpful contribution to the problem.

Yes, it is, because half of the Linux problem with usability is the dogged
refusal of the body politic to accept that any such problem exists.

I say again:

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

P

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

[Lennart Poettering-8]

On Tue, 16.06.09 17:53, Esben Stien (b0ef@...) wrote:

> Melanie <melanie@...> writes:
>
> > I found out the hard way that uninstalling pulseaudio is not an
> > option on that distro.
>
> I don't understand why this isn't crystal clear. Pulse is part of the
> GNOME framework, so all "gnome" app use a uniform framework to play
> sounds.

This is actually not really true. The choice to adopt PA or not is a
decision for distributions, it is not dictated by GNOME. While all
relevant Linux distributions adopted PA, Solaris as another GNOME user
did not.

> > There is no setup for the audio backend gnome uses
>
> Sure, pulse is the GNOME audio server and has backends. You don't want
> every god damn app in gnome to have support for the myriads of sound
> API's out there, do you?.

As Paul already mentioned I am not really pushing folks to use the
native PA API right now, for many reasons. Depending on what apps need
they should use GStreamer, or libcanberra or the "safe" ALSA API
subset instead. (or another sensible API, see
http://0pointer.de/blog/projects/guide-to-sound-apis.html)

All three mentioned APIs do have backends for PA, but not exclusively
for it.

You know, some people always claim I would be "forcing PA down their
throat". That is nonsense.  I simply don't. The integration points of
PA and GNOME are minimal, and I was responsible to make sure that it
is that way. Almost every part of GNOME (with the exception of the
volume control) you can run with a different sound backend, in a
completely PA-free environment. Also all this is all free software,
nobody forces anyone to do anything.

I try to be a nice guy and add hard dependency between PA and other
apps only were really necessary, in the hope that would make those
always-complaining conservative morons shut up and maybe even
thankful. But heck, that of course was in vain, given that the folks
who complain the loudest seldomly contribute anything but complains
since that is the only thing the can do.

> > - pasuspender's functionality becoming part of the jack system so I
> >   can be sure pulse is gone while jack runs.
>
> Right, or some dynamically way to configure pulse, so that it can
> change backend at runtime.

This is is exactly what I was proposing in the original mail.

> Why is not Lennart taking part in these discussions?. (cc)

Because someone dropped me from the CC.

> > What I need is a way to kick that damn pulseaudio off the device
> > without all the pain that that entails today.
>
> Indeed

Yes, of course. And this was already implemented in jack2 and PA. in
a way so that jack doesn't have to depend on PA and PA doesn't have to
depend on JACK, but if both run at the same time the miraculously
start to cooperate.

> > I wish I knew why PA is being forced down my throat anyway!

Nobody forces you to do anything. You are spreading FUD.

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 2:15 PM, Phil Rhodes<phil_rhodes@...> wrote:
>> thanks. that's a deeply helpful contribution to the problem.
>
> Yes, it is, because half of the Linux problem with usability is the dogged
> refusal of the body politic to accept that any such problem exists.

what body politic? who is it that you believe is "responsible" for
fixing this problem?
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Lennart Poettering-8]

On Tue, 16.06.09 18:06, rob (rob@...) wrote:

>>> If pulse doesn't allow itself to be detached from the audio device,
>>> then this must of course be fixed, cause that's stupid. I never have
>>> encountered this problem, cause I always run pulse on top of JACK.
>>>      
>> Pulse grabs all audio interfaces by default. It would be nice if I could
>> just give it control of my internal sound card, and leave my pro sound
>> card alone.
>>  
> I'm in the same boat, and I'd very much like to 'blacklist' PA from  
> attempting to use my pro card.

If you run PA 0.9.15 then all you have to do for this is select "Off"
in the "Configuration" tab of pavucontrol.

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

[Phil Rhodes]

> what body politic? who is it that you believe is "responsible" for
> fixing this problem?

If there was anyone responsible, if there was anyone in charge, if any of
this stuff was being centrally directed and controlled, this problem would
not exist. I don't see this as a solvable problem under the current "every
man for himself, do whatever you feel like, there are no rules" development
model, but then that's exactly how the opensource folks seem to like it.

-P

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

[Lennart Poettering-8]

On Tue, 16.06.09 10:24, Mike Taht (m@...) wrote:

>
> Esben Stien escribió:
> > If pulse doesn't allow itself to be detached from the audio device,
> > then this must of course be fixed, cause that's stupid. I never have
> > encountered this problem, cause I always run pulse on top of JACK.
> >  
> Pulse grabs all audio interfaces by default. It would be nice if I could
> just give it control of my internal sound card, and leave my pro sound
> card alone.

As mentioned, in PA 0.9.15 just go to pavucontrol's Configuration tab
and set the device to "off" and PA will not touch it.

But even that is not necessary with the device reservation logic
that's in JACK2 and PA. PA will then give up the device when JACK asks
for it and take it back afterwards.

> > Because it's part of the GNOME framework. I think it makes a lot of
> > sense, though.
>
> Pulse has one huge advantage over jack, in that it allows systems to
> suspend processing and go into a sleep state. This is very important on
> laptops and in an al gore dominated world, desktops. I would like it if
> jack applications could suspend, somehow.

There's more than just one advantage actually... ;-)

> A) Eventually jack would crash, taking pulse with it, generally
> requiring a reboot

Uh? Almost nothing requires a reboot on Linux. And certainly not PA crashing.

> C) I heartily disliked the sound of the default resampler in pulse

We offer libsamplerate and speex these days. Don't see what there is
to complain.

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

[Matt Henley-2]

> On Tue, Jun 16, 2009 at 07:52:35AM -0400, Paul Davis wrote:
>
>> On Tue, Jun 16, 2009 at 5:01 AM, Fons Adriaensen<fons@...> wrote:
>>
>> > 1. Run Jack as permanent service, run PA as Jack client
>> > when the user logs in (for users wanting both at a time).
>>
>> this requires decision making at a level way outside of the membership
>> of this list. if you really believe that mainstream distributions
>> which package both PA and JACK are going to do this, then you're a
>> greater believer in <something> than me.
>
> Myabe I am :-). Anyway using PA and Jack at the same time
>is probably something required by users who know how to

 >configure it.

I would just like to pipe in from a user perspective:

I use my home system for watching videos, listening to music as well
as trying to work with a number of jack based programs. I tried to
configure my gentoo system as 1.) above.  I wanted Jackd to be running
all the time with pulseaudio as a client that I could disconnect when
I wanted to record or do anything intensive.  The documentation around
Alsa and Pulseaudio are terrible.  I finally settled on using a
procedure described in
http://ubuntu-utah.ubuntuforums.org/showthread.php?t=548178 .

This kinda worked but it was very unstable as described in
http://pulseaudio.org/ticket/472 .  I was unable to produce the
requested backtraces as it behaved very differently during a debug
session than it did during normal operation.

I finally determined that it was not worth the amount of time involved
and set up scripts that get called in qjackctl to stop PA when jackd
starts and starts PA when jackd stops.  This has worked for me.. but I
would always be in favor a something that works and is well
documented.  I intensively dislike the attitude (that Lennart seemed
to have) that using jack implied that your computer should ONLY be
used for audio production work and nothing else.

I applaud his and any effort to try to sort the issues out.

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

[Paul Davis]

On Tue, Jun 16, 2009 at 2:20 PM, Phil Rhodes<phil_rhodes@...> wrote:
>> what body politic? who is it that you believe is "responsible" for
>> fixing this problem?
>
> If there was anyone responsible, if there was anyone in charge, if any of
> this stuff was being centrally directed and controlled, this problem would
> not exist. I don't see this as a solvable problem under the current "every
> man for himself, do whatever you feel like, there are no rules" development
> model, but then that's exactly how the opensource folks seem to like it.

i don't know anybody involved in developing linux audio infrastructure
who likes it at all.
i don't know anybody who actually uses linux audio software who likes it at all.

so i am confused why you think this situation arises from some people liking it.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Michael Taht]

Lennart Poettering escribió:

> On Tue, 16.06.09 10:24, Mike Taht (m@...) wrote:
>
>  
>> Esben Stien escribió:
>>    
>>> If pulse doesn't allow itself to be detached from the audio device,
>>> then this must of course be fixed, cause that's stupid. I never have
>>> encountered this problem, cause I always run pulse on top of JACK.
>>>  
>>>      
>> Pulse grabs all audio interfaces by default. It would be nice if I could
>> just give it control of my internal sound card, and leave my pro sound
>> card alone.
>>    
>
> As mentioned, in PA 0.9.15 just go to pavucontrol's Configuration tab
> and set the device to "off" and PA will not touch it.
>
>  

Excellent to hear that. That is a nearly perfect solution to most of my
problems.
> But even that is not necessary with the device reservation logic
> that's in JACK2 and PA. PA will then give up the device when JACK asks
> for it and take it back afterwards.
>
>  
Obviously I am running more than a few months behind the times. So are
updates to ubuntu 8.10. PA is still at 0.9.10 there. I have been holding
off on upgrading to a later version of that, or fedora, in the hope that
the dust will settle from the acrimonious dbus/jack2 debate.

After seeing all the debate go by this week I plan to build the latest
and greatest of pa, dbus, jack2, etc, and see if I can actually
contribute something....

>>> Because it's part of the GNOME framework. I think it makes a lot of
>>> sense, though.
>>>      
>> Pulse has one huge advantage over jack, in that it allows systems to
>> suspend processing and go into a sleep state. This is very important on
>> laptops and in an al gore dominated world, desktops. I would like it if
>> jack applications could suspend, somehow.
>>    
>
> There's more than just one advantage actually... ;-)
>  

I concur. I do think linux audio will eventually "get there", and think
it is very close as it is.

>  
>> A) Eventually jack would crash, taking pulse with it, generally
>> requiring a reboot
>>    
>
> Uh? Almost nothing requires a reboot on Linux. And certainly not PA crashing.
>
>  
Well, at the time I was unable to work out what magic was required to
restart jack (at the original or a new samplerate), and restart PA, or
vice versa. Logging in and out left the device locked up. Killing off
everything that had the device open left it locked up. I ran out of
ideas at that point.
>> C) I heartily disliked the sound of the default resampler in pulse
>>    
>
> We offer libsamplerate and speex these days. Don't see what there is
> to complain.
>
>  
libsamplerate is excellent, but slow, and in a harder real-time context
would cause jack to disconnect from pa at the time I gave up on trying
to mix jack and pa. I have been working on speeding up libsamplerate
using a few new ideas and SSE2/3. I achieved a fairly large speedup for
x86_64, thus far, with more improvements on the way. If anyone is
interested the bzr tree for it is at:

bzr get http://www.teklibre.com/~d/libsamplerate/ScreamingRabbitCode

(regrettably the tree contains large amounts of debugging code and
neither the SSE2 or SSE3 code is working at present, the present speedup
for x86_64 came from various things, from gcc 4.4, and using the 387
unit and using doubles throughout... that portion of the code is working)
> Lennart
>
>  

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

[Esben Stien]

Paul Davis <paul@...> writes:

> This is a bit misleading. PulseAudio is, to this very day,
> explicitly noted to be *NOT* an API that applications should use for
> audio I/O.

Right, damn, I meant gstreamer here.

>> What do you propose?. You want apps to have support for more than one
>> API?. This would be bloat and you don't have a unified GNOME platform,
>> then. You're also not remembering the fact that no apps whatsoever
>> should really access ALSA by itself.
>
> This is close to being the opposite of the advice on the PA website.

GNOME "core apps" use gstreamer API, which is the preferred API
there. I'm not saying at all that any apps really should use the PA
API to play sounds. I mixed them up in my post, sorry. I meant
gstreamer.

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

[Lennart Poettering-8]

On Tue, 16.06.09 22:21, Esben Stien (b0ef@...) wrote:

>
> Paul Davis <paul@...> writes:
>
> > This is a bit misleading. PulseAudio is, to this very day,
> > explicitly noted to be *NOT* an API that applications should use for
> > audio I/O.
>
> Right, damn, I meant gstreamer here.

No.

GStreamer is a media streaming API. It is useless for playing simple
PCM, and almost as useless for playing event sounds.

> >> What do you propose?. You want apps to have support for more than one
> >> API?. This would be bloat and you don't have a unified GNOME platform,
> >> then. You're also not remembering the fact that no apps whatsoever
> >> should really access ALSA by itself.
> >
> > This is close to being the opposite of the advice on the PA website.
>
> GNOME "core apps" use gstreamer API, which is the preferred API
> there. I'm not saying at all that any apps really should use the PA
> API to play sounds. I mixed them up in my post, sorry. I meant
> gstreamer.

No. GStreamer is just a media streaming interface. There is more about
audio than just media streaming.

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