1:17 p.m.
Hi,
Though having been able to dedicate a lot less time than before to
Fedora during the past few years, I still maintain all of the packages
I own as well as I can. But some packages I have lost interest in, and
have become a burden to maintain. I'm sure others who are still using
them would do a better job than me at maintaining them, which is why I'd
like to orphan the following packages (open bugzilla reports listed for
reference) :
* djvulibre : 443953, 444699
* js: 341631
* moin : lots
* ucarp : 247082, 427495, 449266, 455394, 458767
* portaudio : 478719
I'll proceed to releasing ownership in the pkgdb now. I'm particularly
ashamed of the shape I've left moin in... please forgive me. I really
hope someone will be able to give these the attention they deserve!
Matthias
2:34 p.m.
su, 2009-04-12 kello 20:17 +0200, Matthias Saou kirjoitti:
* moin : lots
I'll proceed to releasing ownership in the pkgdb now. I'm particularly
ashamed of the shape I've left moin in... please forgive me.
I've done some moin hacking and translations, so I have at least some
experience of it. I am interested in taking it over, but I have no
experience in packaging Python apps or web apps.
I just had a chat with the moin developers on IRC and they wish Fedora
would have at least the latest point release of the 1.8 series in F11.
The development freeze is near, but maybe we could even get a freeze
break for a newer moin if there isn't enough time?
Is there anyone on the list who'd like to co-maintain moin with me,
preferably someone with experience in running python web apps?
--
Ville-Pekka Vainio
7:49 p.m.
On Sun, 2009-04-12 at 22:34 +0300, Ville-Pekka Vainio wrote:
Is there anyone on the list who'd like to co-maintain moin with
me,
preferably someone with experience in running python web apps?
I can help co-maintain, emphasis on the "co". And the "help". And the
"can".
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
3:25 a.m.
su, 2009-04-12 kello 20:49 -0400, Ignacio Vazquez-Abrams kirjoitti:
I can help co-maintain, emphasis on the "co". And the
"help". And the
"can".
Ok, thanks. I've taken ownership of all of the branches on pkgdb, feel
free to add yourself to the package. mmcgrath had requested
co-maintainership to EL-5, which I've now approved, though this might be
from the time Fedora was still using moin.
I've been preparing a 1.8.2 RPM for F11, it's mostly done, the
README.rpm file still needs a bit of work as upstream has requested to
include mod_wsgi instructions and drop mod_python instructions.
I'll probably eventually put 1.6.4 into F-9 and F-10, the EL branches
should IMHO stay at 1.5.9 because there was a major syntax change in the
1.6 series, so updating to that would break any existing installations.
--
Ville-Pekka Vainio
7:12 p.m.
Looks like some of these already found new owners:
Matthias Saou wrote:
* djvulibre : 443953, 444699
Now owned by Rakesh Pandit (rakesh).
* moin : lots
See Ville-Pekka Vainio's reply (he's interested, but is looking for
comaintainers).
* portaudio : 478719
Now owned by Orcan Ogetbil (oget).
Folks, if you take ownership of an orphaned package, can you please reply to
the mail discussing the orphaning so people know? It's annoying to have to
check pkgdb to see what packages have been taken over already.
These ones are still up for grabs:
* js: 341631
* ucarp : 247082, 427495, 449266, 455394, 458767
Kevin Kofler
7:17 p.m.
On Sun, Apr 12, 2009 at 8:12 PM, Kevin Kofler wrote:
Looks like some of these already found new owners:
Matthias Saou wrote:
> * djvulibre : 443953, 444699
Now owned by Rakesh Pandit (rakesh).
> * moin : lots
See Ville-Pekka Vainio's reply (he's interested, but is looking for
comaintainers).
> * portaudio : 478719
Now owned by Orcan Ogetbil (oget).
Folks, if you take ownership of an orphaned package, can you please reply to
the mail discussing the orphaning so people know? It's annoying to have to
check pkgdb to see what packages have been taken over already.
These ones are still up for grabs:
> * js: 341631
> * ucarp : 247082, 427495, 449266, 455394, 458767
Sorry for annoying people, it takes me about the same time to check
the email vs the pkgdb page, so I didn't bother.
Orcan
7:53 p.m.
On Sun, Apr 12, 2009 at 8:17 PM, Orcan Ogetbil wrote:
On Sun, Apr 12, 2009 at 8:12 PM, Kevin Kofler wrote:
> Looks like some of these already found new owners:
>
> Matthias Saou wrote:
>> * djvulibre : 443953, 444699
>
> Now owned by Rakesh Pandit (rakesh).
>
>> * moin : lots
>
> See Ville-Pekka Vainio's reply (he's interested, but is looking for
> comaintainers).
>
>> * portaudio : 478719
>
> Now owned by Orcan Ogetbil (oget).
>
> Folks, if you take ownership of an orphaned package, can you please reply to
> the mail discussing the orphaning so people know? It's annoying to have to
> check pkgdb to see what packages have been taken over already.
>
> These ones are still up for grabs:
>> * js: 341631
>> * ucarp : 247082, 427495, 449266, 455394, 458767
>
Sorry for annoying people, it takes me about the same time to check
the email vs the pkgdb page, so I didn't bother.
Orcan
I re-orphaned portaudio. I see that it is patched to work with
pulseaudio, which, I think, must be banned from the surface of Earth.
I am not planning to maintain a package with such a patch.
Anyone who is interested can take it over.
Orcan
PS: Speaking just for myself, I won't be among those people who'll get
annoyed if someone takes over an orphaned package and does not report
this on the mailing list. For everyone's information.
3:08 a.m.
On Sun, 12 Apr 2009 20:53:09 -0400, Orcan wrote:
I re-orphaned portaudio. I see that it is patched to work with
pulseaudio, which, I think, must be banned from the surface of Earth.
I am not planning to maintain a package with such a patch.
The patch is not specific to pulseaudio, though. A bit more of a problem
is that the patch has not been merged upstream, and it is still unclear
whether or when it will be done.
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
5:22 p.m.
On Mon, 2009-04-13 at 10:08 +0200, Michael Schwendt wrote:
On Sun, 12 Apr 2009 20:53:09 -0400, Orcan wrote:
> I re-orphaned portaudio. I see that it is patched to work with
> pulseaudio, which, I think, must be banned from the surface of Earth.
> I am not planning to maintain a package with such a patch.
The patch is not specific to pulseaudio, though.
Right. It's not some kind of hack - it's a genuine improvement which
allows portaudio to work with more ALSA devices, one of which happens to
include the virtual ALSA device used by PulseAudio.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:10 a.m.
Michael Schwendt wrote:
The patch is not specific to pulseaudio, though. A bit more of a
problem
is that the patch has not been merged upstream, and it is still unclear
whether or when it will be done.
It has been submitted upstream, one of the Mixxx developers has recently
pinged them, but it looks like PortAudio's upstream is in some sort of
dormant/semi-inactive state and not very responsive to patches. :-(
Kevin Kofler
6:26 a.m.
On 04/13/2009 02:53 AM, Orcan Ogetbil wrote:
On Sun, Apr 12, 2009 at 8:17 PM, Orcan Ogetbil wrote:
> On Sun, Apr 12, 2009 at 8:12 PM, Kevin Kofler wrote:
>> Looks like some of these already found new owners:
>>
>> Matthias Saou wrote:
>>> * djvulibre : 443953, 444699
>> Now owned by Rakesh Pandit (rakesh).
>>
>>> * moin : lots
>> See Ville-Pekka Vainio's reply (he's interested, but is looking for
>> comaintainers).
>>
>>> * portaudio : 478719
>> Now owned by Orcan Ogetbil (oget).
>>
>> Folks, if you take ownership of an orphaned package, can you please reply to
>> the mail discussing the orphaning so people know? It's annoying to have to
>> check pkgdb to see what packages have been taken over already.
>>
>> These ones are still up for grabs:
>>> * js: 341631
>>> * ucarp : 247082, 427495, 449266, 455394, 458767
> Sorry for annoying people, it takes me about the same time to check
> the email vs the pkgdb page, so I didn't bother.
>
> Orcan
>
I re-orphaned portaudio. I see that it is patched to work with
pulseaudio, which, I think, must be banned from the surface of Earth.
I am not planning to maintain a package with such a patch.
Anyone who is interested can take it over.
I've taken ownership, but only for Fedora, as I don't maintain any
EPEL packages, so I would very much welcome a co-maintainer who would then
also be *the* maintainer for the EPEl packages.
Regards,
Hans
3:22 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
Orcan Ogetbil wrote:
I re-orphaned portaudio. I see that it is patched to work with
pulseaudio, which, I think, must be banned from the surface of Earth.
I am not planning to maintain a package with such a patch.
PulseAudio is the default sound solution in Fedora, so all packages using
sound SHOULD support it.
IMHO, we should:
* find some solution for JACK apps to work out of the box, without
reconfiguring PulseAudio to work on top of JACK. Maybe this involves
running JACK on top of PulseAudio (something which currently doesn't work
because JACK does not support non-mmap ALSA devices nor the native
PulseAudio protocol), maybe this involves starting up JACK when needed and
having it load the JACK modules into PulseAudio and rerouting running
PulseAudio streams to JACK at runtime (which can be done without
interrupting the PulseAudio streams - the problem with that solution is
that it breaks support for multiple output devices, which work just fine
when using PulseAudio directly), maybe something else, but in any case a
solution is needed to make things just work.
* once that's done, make it a requirement that sound MUST work with
PulseAudio without manual configuration. PulseAudio MUST be the default in
all sound-using applications. JACK SHOULD only be used if PulseAudio (and
any of the compatible APIs, e.g. ALSA, ESD etc.) is not supported (and as I
explained above, it needs to interoperate with PulseAudio more than it
currently does). Likewise, aRts (the deprecated KDE 3 sound server) SHOULD
only be used if outputting directly to PulseAudio is not possible.
It makes no sense to have a sound server configured by default and then have
assorted applications not working with it. It also makes no sense to have a
whole set of applications (JACK-using applications) require manual
reconfiguration of the system according to a readme file shipped with the
jack-audio-connection-kit package to even work at all.
Kevin Kofler
6:56 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 2009-04-15 at 10:22 +0200, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> I re-orphaned portaudio. I see that it is patched to work with
> pulseaudio, which, I think, must be banned from the surface of Earth.
> I am not planning to maintain a package with such a patch.
PulseAudio is the default sound solution in Fedora, so all packages using
sound SHOULD support it.
IMHO, we should:
* find some solution for JACK apps to work out of the box, without
reconfiguring PulseAudio to work on top of JACK. Maybe this involves
running JACK on top of PulseAudio (something which currently doesn't work
because JACK does not support non-mmap ALSA devices nor the native
PulseAudio protocol), maybe this involves starting up JACK when needed and
having it load the JACK modules into PulseAudio and rerouting running
PulseAudio streams to JACK at runtime (which can be done without
interrupting the PulseAudio streams - the problem with that solution is
that it breaks support for multiple output devices, which work just fine
when using PulseAudio directly), maybe something else, but in any case a
solution is needed to make things just work.
There is work happening between PulseAudio and Jack to allow automatic
peaceful coexistence.
See http://0pointer.de/blog/projects/device-reservation.html
7:01 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
Matthias Clasen wrote:
There is work happening between PulseAudio and Jack to allow
automatic
peaceful coexistence.
See http://0pointer.de/blog/projects/device-reservation.html
That's not coexistence, it allows only one or the other to work at a time.
It doesn't solve the real problem at all, e.g. try recording audio output
from a PulseAudio app in a JACK-based audio recorder with this "solution".
Kevin Kofler
7:20 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 2009-04-15 at 14:01 +0200, Kevin Kofler wrote:
Matthias Clasen wrote:
> There is work happening between PulseAudio and Jack to allow automatic
> peaceful coexistence.
> See http://0pointer.de/blog/projects/device-reservation.html
That's not coexistence, it allows only one or the other to work at a time.
It doesn't solve the real problem at all, e.g. try recording audio output
from a PulseAudio app in a JACK-based audio recorder with this "solution".
Yes, it does solve the 'use one sound server at a time' problem. Sounds
like a good starting point to me. I have no idea how relevant your
'free-flowing sound streams' scenario is...
9:14 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 15.04.09 14:01, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Matthias Clasen wrote:
> There is work happening between PulseAudio and Jack to allow automatic
> peaceful coexistence.
> See http://0pointer.de/blog/projects/device-reservation.html
That's not coexistence, it allows only one or the other to work at a time.
It doesn't solve the real problem at all, e.g. try recording audio output
from a PulseAudio app in a JACK-based audio recorder with this "solution".
No. Your scenario is artificial. That's not something more than a
handful of people want to do.
I think you are misunderstanding JACK's purpose.
Let me put it differently: you *never* want you event sound blibs and
plops mixed into your JACK pro audio stream. And hence setting up
connectivity between JACK and PA by default is simply the wrong
thing to do.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:10 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 15.04.09 10:22, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Orcan Ogetbil wrote:
> I re-orphaned portaudio. I see that it is patched to work with
> pulseaudio, which, I think, must be banned from the surface of Earth.
> I am not planning to maintain a package with such a patch.
PulseAudio is the default sound solution in Fedora, so all packages using
sound SHOULD support it.
IMHO, we should:
* find some solution for JACK apps to work out of the box, without
reconfiguring PulseAudio to work on top of JACK. Maybe this involves
As Matthias mentioned PA will now hand over audio device access to
JACK if JACK asks for that. When JACk is done running it will hand the
access back.
running JACK on top of PulseAudio (something which currently
doesn't work
because JACK does not support non-mmap ALSA devices nor the native
PulseAudio protocol), maybe this involves starting up JACK when needed and
having it load the JACK modules into PulseAudio and rerouting running
PulseAudio streams to JACK at runtime (which can be done without
interrupting the PulseAudio streams - the problem with that solution is
that it breaks support for multiple output devices, which work just fine
when using PulseAudio directly), maybe something else, but in any case a
solution is needed to make things just work.
No. JACK is a sound server for audio production. PulseAudio is a sound
server for the desktop. Only in very few cases it makes sense to
connect them to each other -- and that should then be configured
manually by the user. While JACK is running PA should go out of the
way. And that's what the JACK folks and I have agreed on and
implemented very recently.
In an ideal world PA and JACK would be one hybrid audio server. But
that's not going to happen anytime soon and it is also questionnable
if it would make sense at all. So the only realisitic short term
solution is having JACK and PA cooperate better. And that should be
the case now. The cooepration logic is in PA 0.9.15. I don't know
which version of JACK actaully added the other side of the story.
* once that's done, make it a requirement that sound MUST work
with
PulseAudio without manual configuration. PulseAudio MUST be the default in
all sound-using applications. JACK SHOULD only be used if PulseAudio (and
any of the compatible APIs, e.g. ALSA, ESD etc.) is not supported (and as I
explained above, it needs to interoperate with PulseAudio more than it
currently does). Likewise, aRts (the deprecated KDE 3 sound server) SHOULD
only be used if outputting directly to PulseAudio is not possible.
JACK should not be used by anything by default, with the exception of
audio production software.
Arts should not be used by anything at all. Let it die a peaceful
death please. (But I a m bit ignorant of KDE, so maybe I am stepping
on someone's toes by saying something bad bad about arts like that)
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:26 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
Lennart Poettering wrote:
JACK should not be used by anything by default, with the exception
of
audio production software.
The problem there is: where does "desktop software" stop and "audio
production software" start? For example, Audacity (which thankfully
supports PulseAudio these days, and BTW it also supports JACK) is used by
many users who are not audio professionals, yet it is arguably also "audio
production software" (though I guess real professionals will find it too
newbieish ;-) ). It's set up for PulseAudio by default (and before that it
was trying to use OSS by default - yuck!). A tool like qsynth is also an
interesting example: that's a frontend for a MIDI software synthesizer. It
can be used to just play MIDIs or it can be used for audio production.
Right now its Fedora package is set up for JACK by default, though it can
be set to use ALSA (and then works just fine with the PulseAudio ALSA
plugin). What should those tools do? Try to autodetect what server is
running? As long as we have mutually exclusive sound servers, there will
probably always be tools which do the wrong thing by default. :-(
Arts should not be used by anything at all. Let it die a peaceful
death please. (But I a m bit ignorant of KDE, so maybe I am stepping
on someone's toes by saying something bad bad about arts like that)
aRts is just used by legacy stuff, it definitely should not be used by
anything new.
Kevin Kofler
11:48 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 15.04.09 18:26, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Lennart Poettering wrote:
> JACK should not be used by anything by default, with the exception of
> audio production software.
The problem there is: where does "desktop software" stop and "audio
production software" start? For example, Audacity (which thankfully
supports PulseAudio these days, and BTW it also supports JACK) is used by
many users who are not audio professionals, yet it is arguably also "audio
production software" (though I guess real professionals will find it too
newbieish ;-) ). It's set up for PulseAudio by default (and before that it
was trying to use OSS by default - yuck!). A tool like qsynth is also an
interesting example: that's a frontend for a MIDI software synthesizer. It
can be used to just play MIDIs or it can be used for audio production.
Right now its Fedora package is set up for JACK by default, though it can
be set to use ALSA (and then works just fine with the PulseAudio ALSA
plugin). What should those tools do? Try to autodetect what server is
running? As long as we have mutually exclusive sound servers, there will
probably always be tools which do the wrong thing by default. :-(
Of course you have to make a decision somewhere. You cannot make
everyone happy. So pick the one you believe would make sense to the
largest audience and make it easy to swtch to the other backend. And
also keep in mind that the normal desktop users are probably not as
technically versed as the pro audio folks are.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:51 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
I wrote:
A tool like qsynth is also an interesting example: that's a
frontend for a
MIDI software synthesizer. It can be used to just play MIDIs or it can be
used for audio production. Right now its Fedora package is set up for JACK
by default, though it can be set to use ALSA (and then works just fine
with the PulseAudio ALSA plugin).
Well, actually it doesn't. It'll happily start up, but trying to actually
play anything outputs... nothing. With no error message or anything, it
just produces no sound, and AFAICT never actually connects to PulseAudio
(even if I try explicitly setting the ALSA output device to default or
pulse). The command-line fluidsynth is broken the same way. (This shows
another issue with the current situation: some programs claim to support
several APIs, but only one gets actually tested.) Well, at least there's
timidity++ which actually works...
Kevin Kofler
8:59 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
I wrote:
Well, actually it doesn't. It'll happily start up, but trying
to actually
play anything outputs... nothing. With no error message or anything, it
just produces no sound, and AFAICT never actually connects to PulseAudio
(even if I try explicitly setting the ALSA output device to default or
pulse). The command-line fluidsynth is broken the same way. (This shows
another issue with the current situation: some programs claim to support
several APIs, but only one gets actually tested.) Well, at least there's
timidity++ which actually works...
FYI, the issue there is just with the default settings: there is no
soundfont configured by default in QSynth or fluidsynth. (Thanks to Jon
Escombe for pointing this out.) When I configure one by hand (why do I have
to do this? Should it not be the packager's job to set up a default
soundfont?), it "works", for some definition of "working". After
bumping up
the buffer size (with the default, I just get noise as output), it suffers
from horrible arhythmy, probably due to ALSA being used both on the
sequencer end and on the output end, I've seen the same happen with
timidity++ back when I was still using dmix (now with PulseAudio,
timidity++ uses libao which uses the native PulseAudio protocol, so this
issue is gone). Jon Escombe also pointed out that the latest fluidsynth
release has a native PulseAudio driver (but unfortunately it's not
available in Fedora yet), that one should work better.
But this is getting way off topic for this list.
Kevin Kofler
9:56 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, Apr 17, 2009 at 9:59 PM, Kevin Kofler wrote:
I wrote:
> Well, actually it doesn't. It'll happily start up, but trying to actually
> play anything outputs... nothing. With no error message or anything, it
> just produces no sound, and AFAICT never actually connects to PulseAudio
> (even if I try explicitly setting the ALSA output device to default or
> pulse). The command-line fluidsynth is broken the same way. (This shows
> another issue with the current situation: some programs claim to support
> several APIs, but only one gets actually tested.) Well, at least there's
> timidity++ which actually works...
FYI, the issue there is just with the default settings: there is no
soundfont configured by default in QSynth or fluidsynth. (Thanks to Jon
Escombe for pointing this out.) When I configure one by hand (why do I have
to do this? Should it not be the packager's job to set up a default
soundfont?), it "works", for some definition of "working". After
bumping up
the buffer size (with the default, I just get noise as output), it suffers
from horrible arhythmy, probably due to ALSA being used both on the
sequencer end and on the output end, I've seen the same happen with
timidity++ back when I was still using dmix (now with PulseAudio,
timidity++ uses libao which uses the native PulseAudio protocol, so this
issue is gone). Jon Escombe also pointed out that the latest fluidsynth
release has a native PulseAudio driver (but unfortunately it's not
available in Fedora yet), that one should work better.
But this is getting way off topic for this list.
Kevin Kofler
I got comaintainership for QSynth just today and I'll look into this issue now.
Just a little more information about the soundfonts, although we are
really stretching it. The default soundfont is replaced in F-11. It
used to be PersonalCopy-Lite-soundfont, now it is fluid-soundfont-gm
which is probably the only really good free soundfont out there (here
gm stands for General Midi).
Moreover, the new soundfont package provides the virtual
"soundfont2-default". And this is what other packages should require.
If your application/library needs to hardcode a default soundfont
path, please use /usr/share/soundfonts/default.sf2, which is a symlink
that points to fluid-soundfont-gm.sf2.
We did it this way; in case the default soundfont changes again in the
future, there will be an easy transition.
Orcan
1:04 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, Apr 17, 2009 at 10:56 PM, Orcan Ogetbil wrote:
On Fri, Apr 17, 2009 at 9:59 PM, Kevin Kofler wrote:
>
> FYI, the issue there is just with the default settings: there is no
> soundfont configured by default in QSynth or fluidsynth. (Thanks to Jon
> Escombe for pointing this out.)
>
> Kevin Kofler
I got comaintainership for QSynth just today and I'll look into this issue now.
Fixed and built for F-12, F-11, F-10, F-9. For the last two, I
couldn't add the update to the qt45 batch in bodhi. It says: "you
don't have commit access to kdemultimedia".
Anyhow, I'd be glad if someone with commit access could update the
batch with the following:
qsynth-0.3.3-6.fc9
qsynth-0.3.3-6.fc10
qjackctl-0.3.4-1.fc9
qjackctl-0.3.4-1.fc10
Please test the new qsynth defaults and let me know if anything is
wrong. The config files are stored in ~/.config/rncbc.org/
Cheers,
Orcan
4:32 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
Orcan Ogetbil wrote:
Anyhow, I'd be glad if someone with commit access could update
the
batch with the following:
qsynth-0.3.3-6.fc9
qsynth-0.3.3-6.fc10
qjackctl-0.3.4-1.fc9
qjackctl-0.3.4-1.fc10
I'll do that, thanks.
Kevin Kofler
7:06 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Sat, Apr 18, 2009 at 5:32 AM, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> Anyhow, I'd be glad if someone with commit access could update the
> batch with the following:
>
> qsynth-0.3.3-6.fc9
> qsynth-0.3.3-6.fc10
>
> qjackctl-0.3.4-1.fc9
> qjackctl-0.3.4-1.fc10
I'll do that, thanks.
Kevin Kofler
Did anyone test these builds, especially the qsynth? It works for me
but I want to make sure if my patches work for everyone. Also, should
I ask for a freeze break for qsynth?
Orcan
2:24 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 2009-04-15 at 18:26 +0200, Kevin Kofler wrote:
Lennart Poettering wrote:
> JACK should not be used by anything by default, with the exception of
> audio production software.
The problem there is: where does "desktop software" stop and "audio
production software" start? For example, Audacity (which thankfully
supports PulseAudio these days, and BTW it also supports JACK) is used by
many users who are not audio professionals, yet it is arguably also "audio
production software" (though I guess real professionals will find it too
newbieish ;-) ).
Practically speaking, you nailed it right there. There's a fairly small
and well-defined circle of professional audio production apps that
serious creators use, that use JACK by default, and that no-one would
want to be any other way. Everyone involved - the authors and
maintainers of JACK, Pulse, and the apps in question - knows what's
what, so there's not really any practical problem here.
To anyone with sufficient knowledge (and everyone involved has that),
"should this app use Pulse or JACK?" is a pretty simple question to
answer. Audacity is a no-brainer to be Pulse by default.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:22 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 2009-04-15 at 18:26 +0200, Kevin Kofler wrote:
Lennart Poettering wrote:
> JACK should not be used by anything by default, with the exception of
> audio production software.
The problem there is: where does "desktop software" stop and "audio
production software" start? For example, Audacity (which thankfully
supports PulseAudio these days, and BTW it also supports JACK) is used by
many users who are not audio professionals, yet it is arguably also "audio
production software" (though I guess real professionals will find it too
newbieish ;-) ). It's set up for PulseAudio by default (and before that it
was trying to use OSS by default - yuck!). A tool like qsynth is also an
interesting example: that's a frontend for a MIDI software synthesizer. It
can be used to just play MIDIs or it can be used for audio production.
Right now its Fedora package is set up for JACK by default, though it can
be set to use ALSA (and then works just fine with the PulseAudio ALSA
plugin). What should those tools do? Try to autodetect what server is
running? As long as we have mutually exclusive sound servers, there will
probably always be tools which do the wrong thing by default. :-(
If the user hasn't set a preference, such as on the first run, use Jack
if it's running, otherwise fall back on Pulse, otherwise fall back on
ALSA. Easy. There should be a simple obvious UI (Not hidden in the !@#
$ing preferences) that clearly indicates the current output and allows
you to dynamically change the output if it chooses wrong, with a sticky
preference for the next time.
9:45 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 17.04.09 19:22, Callum Lerwick (seg(a)haxxed.com) wrote:
On Wed, 2009-04-15 at 18:26 +0200, Kevin Kofler wrote:
> Lennart Poettering wrote:
> > JACK should not be used by anything by default, with the exception of
> > audio production software.
>
> The problem there is: where does "desktop software" stop and "audio
> production software" start? For example, Audacity (which thankfully
> supports PulseAudio these days, and BTW it also supports JACK) is used by
> many users who are not audio professionals, yet it is arguably also "audio
> production software" (though I guess real professionals will find it too
> newbieish ;-) ). It's set up for PulseAudio by default (and before that it
> was trying to use OSS by default - yuck!). A tool like qsynth is also an
> interesting example: that's a frontend for a MIDI software synthesizer. It
> can be used to just play MIDIs or it can be used for audio production.
> Right now its Fedora package is set up for JACK by default, though it can
> be set to use ALSA (and then works just fine with the PulseAudio ALSA
> plugin). What should those tools do? Try to autodetect what server is
> running? As long as we have mutually exclusive sound servers, there will
> probably always be tools which do the wrong thing by default. :-(
If the user hasn't set a preference, such as on the first run, use Jack
if it's running, otherwise fall back on Pulse, otherwise fall back on
ALSA. Easy. There should be a simple obvious UI (Not hidden in the !@#
$ing preferences) that clearly indicates the current output and allows
you to dynamically change the output if it chooses wrong, with a sticky
preference for the next time.
It's not that easy. There's autospawning of both PA and Jack. Hence
checking 'if it is running' doesn't really work.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:23 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Sat, 2009-04-18 at 16:45 +0200, Lennart Poettering wrote:
On Fri, 17.04.09 19:22, Callum Lerwick (seg(a)haxxed.com) wrote:
> If the user hasn't set a preference, such as on the first run, use Jack
> if it's running, otherwise fall back on Pulse, otherwise fall back on
> ALSA. Easy. There should be a simple obvious UI (Not hidden in the !@#
> $ing preferences) that clearly indicates the current output and allows
> you to dynamically change the output if it chooses wrong, with a sticky
> preference for the next time.
It's not that easy. There's autospawning of both PA and Jack. Hence
checking 'if it is running' doesn't really work.
Why is Jack autospawning now? Bletch. Autospawn is mostly irrelevant. If
Pulse is autospawning properly, presumably the user wants to use it.
Jack is a bit different, presumably we'd want some kind of global (to
the user session) "I want to use Jack" preference. If it's not enabled,
don't touch Jack. And like I said, let the easy obvious UI allow the
user to sort things out.
Jack isn't dynamic last I checked, it likes to lock on to one and *only*
one device for it's lifetime. Making it a not so great candidate for
autospawning without being configured first. Its design goal of
super-low latency doesn't allow for multiple devices, as they aren't
going to be perfectly in sync unless they're specialized pro-gear.
So basically, Jack should not be used until a user checks an "Use Jack"
checkbox somewhere and picks a device to use.
10:08 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, Apr 15, 2009 at 4:22 AM, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> I re-orphaned portaudio. I see that it is patched to work with
> pulseaudio, which, I think, must be banned from the surface of Earth.
> I am not planning to maintain a package with such a patch.
PulseAudio is the default sound solution in Fedora, so all packages using
sound SHOULD support it.
There are two issues here.
JACK is the default for audio production software (period) I
personally do record multitrack audio and make use ladspa, lv2 etc.
Nothing beats JACK. Audio production software don't need to support
PulseAudio because people who are into audio recording/mixing won't
use it while there is Jack.
IMHO, we should:
* find some solution for JACK apps to work out of the box, without
reconfiguring PulseAudio to work on top of JACK. Maybe this involves
running JACK on top of PulseAudio (something which currently doesn't work
because JACK does not support non-mmap ALSA devices nor the native
PulseAudio protocol), maybe this involves starting up JACK when needed and
having it load the JACK modules into PulseAudio and rerouting running
PulseAudio streams to JACK at runtime (which can be done without
interrupting the PulseAudio streams - the problem with that solution is
that it breaks support for multiple output devices, which work just fine
when using PulseAudio directly), maybe something else, but in any case a
solution is needed to make things just work.
* once that's done, make it a requirement that sound MUST work with
PulseAudio without manual configuration. PulseAudio MUST be the default in
all sound-using applications. JACK SHOULD only be used if PulseAudio (and
any of the compatible APIs, e.g. ALSA, ESD etc.) is not supported (and as I
explained above, it needs to interoperate with PulseAudio more than it
currently does). Likewise, aRts (the deprecated KDE 3 sound server) SHOULD
only be used if outputting directly to PulseAudio is not possible.
It makes no sense to have a sound server configured by default and then have
assorted applications not working with it. It also makes no sense to have a
whole set of applications (JACK-using applications) require manual
reconfiguration of the system according to a readme file shipped with the
jack-audio-connection-kit package to even work at all.
Now the second issue: If you look at it that way, PulseAudio needs a
manual configuration too. Very very many people complained about sound
problems in F-10 and had to do the tsched=0 hack to make things work.
I read that even this hack is not enough for some folks.
For me, PulseAudio did not work at all, until F-10. And on F-10, I had
to do the above hack too. But still, it is choppy. I recently wiped
off PulseAudio from my system and returned to plain ALSA. Believe it
or not, every sound application is more responsive and works better
now. Even Firefox works twice faster (no exaggeration).
I do believe that making PulseAudio the default is a shame for Fedora
(and bigger shame than disabling ctrl+alt+backspace). While I have
nothing against testing and supporting pre-alpha quality software, I
don't think such should be the default on Fedora. The way it was
released by their upstream and it was introduced in Fedora are plain
wrong. The 0.9 series should have been called 0.0.0.1 or something in
that line. I agree that PulseAudio proposes nice features and if they
came to me and asked for help to get their code to alpha quality, I
would have gladly helped. But these nice features that you propose
count nothing if you can't support the most basic tasks a sound server
should support.
I also believe that PulseAudio is a cancer, and it is growing. Even if
we are going to lose a leg to get rid of this cancer, we should do it
NOW. Otherwise it will spread and become irrevocable. The topic of the
discussion should be: How can we get rid of PulseAudio? How can we ban
this project for the good of humanity?
Plain ALSA is good enough. And what do they say? "If it's not broken,
do not fix it." I do not understand the need of adding a buggy,
unfinished layer on top of good mother ALSA.
Regards,
Orcan, the "Pulse Against"
10:20 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
Orcan Ogetbil (oget.fedora(a)gmail.com) said:
I also believe that PulseAudio is a cancer, and it is growing. Even
if
we are going to lose a leg to get rid of this cancer, we should do it
NOW. Otherwise it will spread and become irrevocable. The topic of the
discussion should be: How can we get rid of PulseAudio? How can we ban
this project for the good of humanity?
Ban this project for the good of humanity?
You know, one way to ensure you're not taken seriously is to elevate
a few thousand lines of C code to something that needs to be exterminated
for the future of the human race. To the best of my knowledge, PulseAudio
is not going to become Skynet.
(Besides, obviosly we'd need to remove Xaw, Tcl/Tk, Pascal, Ada, and about
a thousand other harmful things from Fedora first. And don't forget emacs,
progenitor of X-windows fascism everywhere!)
Plain ALSA is good enough. And what do they say? "If it's
not broken,
do not fix it."
'Work' is a strong word. It's possibly the most baroque example of second
system software in all of Fedora.
Bill
1:12 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, Apr 15, 2009 at 11:20 AM, Bill Nottingham wrote:
Orcan Ogetbil said:
> I also believe that PulseAudio is a cancer, and it is growing. Even if
> we are going to lose a leg to get rid of this cancer, we should do it
> NOW. Otherwise it will spread and become irrevocable. The topic of the
> discussion should be: How can we get rid of PulseAudio? How can we ban
> this project for the good of humanity?
Ban this project for the good of humanity?
Indeed.
You know, one way to ensure you're not taken seriously is to
elevate
a few thousand lines of C code to something that needs to be exterminated
for the future of the human race.
Maybe not directly. But having a broken audio server as a default is a
show stopper. It is a repellent for new people. And allowing it will
infect the Linux experience of everyone. I hope you got my point.
Orcan
11:44 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 15.04.09 11:08, Orcan Ogetbil (oget.fedora(a)gmail.com) wrote:
I also believe that PulseAudio is a cancer, and it is growing. Even
if
we are going to lose a leg to get rid of this cancer, we should do it
NOW. Otherwise it will spread and become irrevocable. The topic of the
discussion should be: How can we get rid of PulseAudio? How can we ban
this project for the good of humanity?
If PulseAudio is a cancer than I am the evil bio weapons scientist who
engineered it. Muahahah! Muahahahahaaaa!
Now that my plan for world domination with biologic WMDs got exposed
like this, what can I do? Oh hell, let's just do what we always
do. Hijack some nuclear weapons and hold the world hostage. Yeah?
Good!
Plain ALSA is good enough. And what do they say? "If it's
not broken,
do not fix it." I do not understand the need of adding a buggy,
unfinished layer on top of good mother ALSA.
You are more catholic than the pope.
Maybe the fact that even the ALSA guys themselves think that having a
userspace sound daemon on top of ALSA like PA is a good idea and
necessary might give you a hint how distorted your view of the world
is.
Lennart, bio weapons scientist
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:35 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Wed, 2009-04-15 at 10:22 +0200, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> I re-orphaned portaudio. I see that it is patched to work with
> pulseaudio, which, I think, must be banned from the surface of Earth.
> I am not planning to maintain a package with such a patch.
PulseAudio is the default sound solution in Fedora, so all packages using
sound SHOULD support it.
IMHO, we should:
* find some solution for JACK apps to work out of the box, without
reconfiguring PulseAudio to work on top of JACK. Maybe this involves
running JACK on top of PulseAudio (something which currently doesn't work
because JACK does not support non-mmap ALSA devices nor the native
PulseAudio protocol)
I think it is clear from the thread (and I arrived to it late - I was in
LAC2009), but just in case:
NO.
That solution (Jack on top of PA) does not work not because of mmap
access requirements of Jack. It does not work because Jack and PA are
_conceptually_ different and cater to different segments of the audio
users of Fedora and other distros.
Jack is designed for very very low latency. Jack needs access to the
hardware devices. It cannot and should not run on "top of something
else". The requirement is not capricious. It is designed that way, and
works very well. Please don't break it.
After I don't know how many Fedora releases that incorporated
(prematurely) PA, PA and Jack developers are starting to talk to make an
audio workstation that has both installed work, let's leave them to work
things out. At least the proposed scheme is an improvement over things
just not working.
-- Fernando
maybe this involves starting up JACK when needed and
having it load the JACK modules into PulseAudio and rerouting running
PulseAudio streams to JACK at runtime (which can be done without
interrupting the PulseAudio streams - the problem with that solution is
that it breaks support for multiple output devices, which work just fine
when using PulseAudio directly), maybe something else, but in any case a
solution is needed to make things just work.
* once that's done, make it a requirement that sound MUST work with
PulseAudio without manual configuration. PulseAudio MUST be the default in
all sound-using applications. JACK SHOULD only be used if PulseAudio (and
any of the compatible APIs, e.g. ALSA, ESD etc.) is not supported (and as I
explained above, it needs to interoperate with PulseAudio more than it
currently does). Likewise, aRts (the deprecated KDE 3 sound server) SHOULD
only be used if outputting directly to PulseAudio is not possible.
It makes no sense to have a sound server configured by default and then have
assorted applications not working with it. It also makes no sense to have a
whole set of applications (JACK-using applications) require manual
reconfiguration of the system according to a readme file shipped with the
jack-audio-connection-kit package to even work at all.
Kevin Kofler
3:36 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 2009-04-23 at 10:35 -0700, Fernando Lopez-Lezcano wrote:
On Wed, 2009-04-15 at 10:22 +0200, Kevin Kofler wrote:
> Orcan Ogetbil wrote:
> > I re-orphaned portaudio. I see that it is patched to work with
> > pulseaudio, which, I think, must be banned from the surface of Earth.
> > I am not planning to maintain a package with such a patch.
>
> PulseAudio is the default sound solution in Fedora, so all packages using
> sound SHOULD support it.
>
> IMHO, we should:
> * find some solution for JACK apps to work out of the box, without
> reconfiguring PulseAudio to work on top of JACK. Maybe this involves
> running JACK on top of PulseAudio (something which currently doesn't work
> because JACK does not support non-mmap ALSA devices nor the native
> PulseAudio protocol)
I think it is clear from the thread (and I arrived to it late - I was in
LAC2009), but just in case:
NO.
That solution (Jack on top of PA) does not work not because of mmap
access requirements of Jack. It does not work because Jack and PA are
_conceptually_ different and cater to different segments of the audio
users of Fedora and other distros.
Jack is designed for very very low latency. Jack needs access to the
hardware devices. It cannot and should not run on "top of something
else". The requirement is not capricious. It is designed that way, and
works very well. Please don't break it.
+1
The thing to do route Pulseaudio through Jack. Pulseaudio already has a
Jack plugin.
Though as pointed out, *real* pro audio people have an expensive pro
audio card dedicated to Jack, while Pulseaudio can dink around with the
motherboard audio and keep its damn dirty mitts off the pro card.
4:01 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 23.04.09 15:36, Callum Lerwick (seg(a)haxxed.com) wrote:
> That solution (Jack on top of PA) does not work not because of
mmap
> access requirements of Jack. It does not work because Jack and PA are
> _conceptually_ different and cater to different segments of the audio
> users of Fedora and other distros.
>
> Jack is designed for very very low latency. Jack needs access to the
> hardware devices. It cannot and should not run on "top of something
> else". The requirement is not capricious. It is designed that way, and
> works very well. Please don't break it.
+1
The thing to do route Pulseaudio through Jack. Pulseaudio already has a
Jack plugin.
As I already pointed out there is no point in running PA and JACK on
top of each other. Certainly not JACK on top of PA and not the other
way either.
PA and JACK have different purposes. For pro audio PA needs to go out
of the way and that's what it does with the device reservation
logic.
The Jack plugin for PA is more a toy for exotic uses. It is nothing to
enable by default. Running PA on JACK is simply pointless, there is
simply no reason why you'd want that. You don't want to have event
sounds mixed in your pro audio stream, you don't want ekiga audio in
it, and you don't want flash sounds or rhythmbox or totem streams
it. The whole discussion of something like this is just complete and
utter nonsense.
So, no, "the thing" is NOT "to route PA through Jack". The thing is
to
not have them interfere with each other and cooperate. And that's what
has been implemented now.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:29 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 2009-04-23 at 23:01 +0200, Lennart Poettering wrote:
On Thu, 23.04.09 15:36, Callum Lerwick (seg(a)haxxed.com) wrote:
> > That solution (Jack on top of PA) does not work not because of mmap
> > access requirements of Jack. It does not work because Jack and PA are
> > _conceptually_ different and cater to different segments of the audio
> > users of Fedora and other distros.
> >
> > Jack is designed for very very low latency. Jack needs access to the
> > hardware devices. It cannot and should not run on "top of something
> > else". The requirement is not capricious. It is designed that way, and
> > works very well. Please don't break it.
>
> +1
>
> The thing to do route Pulseaudio through Jack. Pulseaudio already has a
> Jack plugin.
As I already pointed out there is no point in running PA and JACK on
top of each other. Certainly not JACK on top of PA and not the other
way either.
PA and JACK have different purposes. For pro audio PA needs to go out
of the way and that's what it does with the device reservation
logic.
The Jack plugin for PA is more a toy for exotic uses. It is nothing to
enable by default. Running PA on JACK is simply pointless, there is
simply no reason why you'd want that.
Sorry, no, no reason that you can see.
You don't want to have event
sounds mixed in your pro audio stream, you don't want ekiga audio in
it, and you don't want flash sounds or rhythmbox or totem streams
it.
In the general case that is probably true.
The whole discussion of something like this is just complete and
utter nonsense.
Nope. The dividing line between the two worlds is actually made of
shades of grey, we don't live in a black and white world. Just because
you don't do it or can't think of an application does not mean it is
"utter nonsense"[*].
So, no, "the thing" is NOT "to route PA through
Jack". The thing is to
not have them interfere with each other and cooperate. And that's what
has been implemented now.
Sure, on that we agree completely.
-- Fernando
[*] for example: an art installation that takes several audio feeds
coming from web browsers and processes them through a "professional"
audio chain running under Jack, records the multichannel output to
Ardour and then perhaps ships the whole thing to another place maybe
halfway around the world using netjack or jacktrip. Yes, people do that
kind of thing :-)
Well, of course, thinking about it, you can also say this is "utter
nonsense"... oh well...
10:22 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 2009-04-23 at 15:36 -0500, Callum Lerwick wrote:
On Thu, 2009-04-23 at 10:35 -0700, Fernando Lopez-Lezcano wrote:
> On Wed, 2009-04-15 at 10:22 +0200, Kevin Kofler wrote:
> > Orcan Ogetbil wrote:
> > > I re-orphaned portaudio. I see that it is patched to work with
> > > pulseaudio, which, I think, must be banned from the surface of Earth.
> > > I am not planning to maintain a package with such a patch.
> >
> > PulseAudio is the default sound solution in Fedora, so all packages using
> > sound SHOULD support it.
> >
> > IMHO, we should:
> > * find some solution for JACK apps to work out of the box, without
> > reconfiguring PulseAudio to work on top of JACK. Maybe this involves
> > running JACK on top of PulseAudio (something which currently doesn't work
> > because JACK does not support non-mmap ALSA devices nor the native
> > PulseAudio protocol)
>
> I think it is clear from the thread (and I arrived to it late - I was in
> LAC2009), but just in case:
>
> NO.
>
> That solution (Jack on top of PA) does not work not because of mmap
> access requirements of Jack. It does not work because Jack and PA are
> _conceptually_ different and cater to different segments of the audio
> users of Fedora and other distros.
>
> Jack is designed for very very low latency. Jack needs access to the
> hardware devices. It cannot and should not run on "top of something
> else". The requirement is not capricious. It is designed that way, and
> works very well. Please don't break it.
+1
The thing to do route Pulseaudio through Jack. Pulseaudio already has a
Jack plugin.
Though as pointed out, *real* pro audio people have an expensive pro
audio card dedicated to Jack, while Pulseaudio can dink around with the
motherboard audio and keep its damn dirty mitts off the pro card.
And Fedora, as of recent (f10?, or was that f9?), makes even _that_
difficult. The _order_ of the sound cards after a reboot is
unpredictable and is not repeatable.
So the usual way of dealing with the "pro" card within jack does not
work (ie: on one boot hw:0 could be pointing to the motherboard card, on
the next boot it could be pointing to the "pro" card).
The only fix AFAIK is to add a modprobe.conf that defines the order of
the cards. Easy, right? (in ancient, less civilized times, the order
would always be the same, and if you did not like it there would be an
small app that would let you configure it - that's progress :-)
-- Fernando
11:47 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 2009-04-23 at 20:22 -0700, Fernando Lopez-Lezcano wrote:
The only fix AFAIK is to add a modprobe.conf that defines the order
of
the cards. Easy, right? (in ancient, less civilized times, the order
would always be the same, and if you did not like it there would be an
small app that would let you configure it - that's progress :-)
I don't recall that ever being the case. The order has *always* been
unpredictable unless you had a modprobe.conf. I definitely remember
experiencing this several years ago.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:44 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 2009-04-23 at 21:47 -0700, Adam Williamson wrote:
On Thu, 2009-04-23 at 20:22 -0700, Fernando Lopez-Lezcano wrote:
> The only fix AFAIK is to add a modprobe.conf that defines the order of
> the cards. Easy, right? (in ancient, less civilized times, the order
> would always be the same, and if you did not like it there would be an
> small app that would let you configure it - that's progress :-)
I don't recall that ever being the case. The order has *always* been
unpredictable unless you had a modprobe.conf. I definitely remember
experiencing this several years ago.
I never had any problems with this till _something_ changed fairly
recently in Fedora. Maybe it was the actual disappearance of Fedora
sound card configuration from the modprobe.conf landscape. And the
matching disappearance act of the sound configuration utility.
Anyway, my experience in many many machines over many many years has
been no problems ever before, and then the impossibility of predicting
which soundcard will be hw:0 and no way of fixing it, save for manually
creating a system configuration file as root.
I have to document this workaround in my Planet CCRMA installation pages
to make the overall system usable. It is interesting to observe how,
over the years, Fedora gets closer and closer to a usable out of the box
sound experience for Planet CCRMA users and then, suddenly, we are all
back to editing system files as root to make it usable again.
-- Fernando
noon
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 24.04.09 09:44, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
I have to document this workaround in my Planet CCRMA installation
pages
to make the overall system usable. It is interesting to observe how,
over the years, Fedora gets closer and closer to a usable out of the box
sound experience for Planet CCRMA users and then, suddenly, we are all
back to editing system files as root to make it usable again.
Please update those documents and teach folks to use the
card names instead of the card index.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
1:02 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 2009-04-24 at 19:00 +0200, Lennart Poettering wrote:
On Fri, 24.04.09 09:44, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
> I have to document this workaround in my Planet CCRMA installation pages
> to make the overall system usable. It is interesting to observe how,
> over the years, Fedora gets closer and closer to a usable out of the box
> sound experience for Planet CCRMA users and then, suddenly, we are all
> back to editing system files as root to make it usable again.
Please update those documents and teach folks to use the
card names instead of the card index.
What would be the name that corresponds to hw:x, and how do I find it?
-- Fernando
1:19 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 24.04.09 11:02, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
On Fri, 2009-04-24 at 19:00 +0200, Lennart Poettering wrote:
> On Fri, 24.04.09 09:44, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
>
> > I have to document this workaround in my Planet CCRMA installation pages
> > to make the overall system usable. It is interesting to observe how,
> > over the years, Fedora gets closer and closer to a usable out of the box
> > sound experience for Planet CCRMA users and then, suddenly, we are all
> > back to editing system files as root to make it usable again.
>
> Please update those documents and teach folks to use the
> card names instead of the card index.
What would be the name that corresponds to hw:x, and how do I find it?
Please read my responses to your emails. That's why I write them.
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01950.html
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
4:16 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 2009-04-24 at 20:19 +0200, Lennart Poettering wrote:
On Fri, 24.04.09 11:02, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
>
> On Fri, 2009-04-24 at 19:00 +0200, Lennart Poettering wrote:
> > On Fri, 24.04.09 09:44, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU)
wrote:
> >
> > > I have to document this workaround in my Planet CCRMA installation pages
> > > to make the overall system usable. It is interesting to observe how,
> > > over the years, Fedora gets closer and closer to a usable out of the box
> > > sound experience for Planet CCRMA users and then, suddenly, we are all
> > > back to editing system files as root to make it usable again.
> >
> > Please update those documents and teach folks to use the
> > card names instead of the card index.
>
> What would be the name that corresponds to hw:x, and how do I find it?
Please read my responses to your emails. That's why I write them.
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01950.html
Thanks!
-- Fernando
4:24 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 2009-04-24 at 20:19 +0200, Lennart Poettering wrote:
On Fri, 24.04.09 11:02, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
>
> On Fri, 2009-04-24 at 19:00 +0200, Lennart Poettering wrote:
> > On Fri, 24.04.09 09:44, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU)
wrote:
> >
> > > I have to document this workaround in my Planet CCRMA installation pages
> > > to make the overall system usable. It is interesting to observe how,
> > > over the years, Fedora gets closer and closer to a usable out of the box
> > > sound experience for Planet CCRMA users and then, suddenly, we are all
> > > back to editing system files as root to make it usable again.
> >
> > Please update those documents and teach folks to use the
> > card names instead of the card index.
>
> What would be the name that corresponds to hw:x, and how do I find it?
Please read my responses to your emails. That's why I write them.
(BTW, I read them. I see the message in the archives, it is not <yet?>
in my mailbox, Evolution FC10, don't know why - delayed, spam filtered,
don't know).
Thanks again.
-- Fernando
4:34 p.m.
New subject: evolution as mta not showing emails (was Re: PulseAudio and sound apps (was: Re: Orphaning a few packages))
On Friday 24 April 2009 17:24:25 Fernando Lopez-Lezcano wrote:
(BTW, I read them. I see the message in the archives, it is not <yet?>
in my mailbox, Evolution FC10, don't know why - delayed, spam filtered,
don't know).
Thanks again.
-- Fernando
Try 'mutt' or 'kmail' or 'pine' and see if the problem persists.
If not, file a
bug report against evo-- that's the only way these issues can be addressed.
8:43 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Thu, 23.04.09 20:22, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
And Fedora, as of recent (f10?, or was that f9?), makes even _that_
difficult. The _order_ of the sound cards after a reboot is
unpredictable and is not repeatable.
So the usual way of dealing with the "pro" card within jack does not
work (ie: on one boot hw:0 could be pointing to the motherboard card, on
the next boot it could be pointing to the "pro" card).
The only fix AFAIK is to add a modprobe.conf that defines the order of
the cards. Easy, right? (in ancient, less civilized times, the order
would always be the same, and if you did not like it there would be an
small app that would let you configure it - that's progress :-)
system-config-soundcard used to write 'stable' card index into a
modprobe fragment. Doing that often broke hotplug however: if you plug
in a card for which no such modprobe.conf fragment exists it will take
up the first available index. If you then plug in a card for which
such an index has been configured it might find the index taken and
hence fails to initialize. We got gazillions of bug reports about
situations like this. s-c-s has been deprecated due to that.
You don't need stable card indexes. Use the card names instead. Just
have a look in /proc/asound/cards and use the names in the
[]. I.e. "front:Intel" instead of "front:0". Or
"hw:AudioPCI" instead
of "hw:1" and so on.
Relying on card indexes is simply broken. The same as it would be to
handle network interfaces with ifindexes. It's time people forget
about them.
The card names are based on the card model mostly. For most people
that should be stable enough. Only very few folks have more than once
card of the same model plugged in. There has been some talk at making
those completely as well, similar to how network interface names are
stable. You can rename cards during runtime by writing to a sysfs
file. Unfortunately sound cards usually bear no unique identifier like
the MAC address for network cards and hence doing this is not as
straightforward as it seems. Nonetheless we really should do this
eventually. Would be great if someone could take this up and prepare
patches for udev.
Better still then using the card name is using the hal path or some
udev path/identifier for identifying cards. PA does that.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:18 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, Apr 24, 2009 at 9:43 AM, Lennart Poettering wrote:
Better still then using the card name is using the hal path or some
udev path/identifier for identifying cards. PA does that.
Lennart
Lennart,
please stop implying CA supporting features that it actually can't. CA
does not work with multiple soundcards. AT ALL... (tested it with 100%
different hardware, different machines)
It might be working on your system and possibly a handful of other
people's. But that's all.
Orcan
10:23 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 24.04.09 11:18, Orcan Ogetbil (oget.fedora(a)gmail.com) wrote:
On Fri, Apr 24, 2009 at 9:43 AM, Lennart Poettering wrote:
>
> Better still then using the card name is using the hal path or some
> udev path/identifier for identifying cards. PA does that.
>
> Lennart
>
Lennart,
please stop implying CA supporting features that it actually can't. CA
does not work with multiple soundcards. AT ALL... (tested it with 100%
different hardware, different machines)
It might be working on your system and possibly a handful of other
people's. But that's all.
What is CA?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:33 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, Apr 24, 2009 at 11:23 AM, Lennart Poettering wrote:
On Fri, 24.04.09 11:18, Orcan Ogetbil wrote:
>
> On Fri, Apr 24, 2009 at 9:43 AM, Lennart Poettering wrote:
> >
> > Better still then using the card name is using the hal path or some
> > udev path/identifier for identifying cards. PA does that.
> >
> > Lennart
> >
>
> Lennart,
> please stop implying CA supporting features that it actually can't. CA
> does not work with multiple soundcards. AT ALL... (tested it with 100%
> different hardware, different machines)
>
> It might be working on your system and possibly a handful of other
> people's. But that's all.
What is CA?
It is an evil *curse*. And Fedora is waiting for its hero to lift it.
Orcan
10:39 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 24.04.09 11:33, Orcan Ogetbil (oget.fedora(a)gmail.com) wrote:
>> It might be working on your system and possibly a handful of
other
>> people's. But that's all.
>
> What is CA?
>
It is an evil *curse*. And Fedora is waiting for its hero to lift it.
Ah, got it. You are such a funny guy.
I mean, I have a pretty good idea of the bugs in bz that are posted
against PA. And I am not aware of any bug that would describe issues
with PA mishandling multiple sound card setups *ever*. So for a
change, what about actually referring to an actual bug report about
this.
Ok, this really enough. You, sir, are a lier, are clueless, poisonous
and spreading FUD. Please just go away, will you?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:26 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, Apr 24, 2009 at 11:39 AM, Lennart Poettering wrote:
On Fri, 24.04.09 11:33, Orcan Ogetbil wrote:
> >> It might be working on your system and possibly a handful of other
> >> people's. But that's all.
> >
> > What is CA?
> >
>
> It is an evil *curse*. And Fedora is waiting for its hero to lift it.
Ah, got it. You are such a funny guy.
I mean, I have a pretty good idea of the bugs in bz that are posted
against PA. And I am not aware of any bug that would describe issues
with PA mishandling multiple sound card setups *ever*. So for a
change, what about actually referring to an actual bug report about
this.
Ok, this really enough. You, sir, are a lier, are clueless, poisonous
and spreading FUD. Please just go away, will you?
Okay, I think I delivered all my points. I'm going not going to say
more for now.
But, please recognize that your confusion of facts with FUDs ruins the
Linux experience of many people, including those who want to "switch"
to Linux. It is really not nice to switch to a system where your
computer freezes 5 times a day. It causes bad reputation not only for
Fedora, but also for Linux and free software.
I'm returning the "lier, clueless and poisonous" accusations, and I
stand behind everything I said, which are nothing but facts, including
(but not limited to) CA is 99.99% crap; it freezes systems; it does
not properly support multiple soundcards; and it must be wiped off of
our planet for the good of humanity.
Best,
Orcan
12:03 p.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 2009-04-24 at 12:26 -0400, Orcan Ogetbil wrote:
On Fri, Apr 24, 2009 at 11:39 AM, Lennart Poettering wrote:
> On Fri, 24.04.09 11:33, Orcan Ogetbil wrote:
>
>> >> It might be working on your system and possibly a handful of other
>> >> people's. But that's all.
>> >
>> > What is CA?
>> >
>>
>> It is an evil *curse*. And Fedora is waiting for its hero to lift it.
>
> Ah, got it. You are such a funny guy.
>
> I mean, I have a pretty good idea of the bugs in bz that are posted
> against PA. And I am not aware of any bug that would describe issues
> with PA mishandling multiple sound card setups *ever*. So for a
> change, what about actually referring to an actual bug report about
> this.
>
> Ok, this really enough. You, sir, are a lier, are clueless, poisonous
> and spreading FUD. Please just go away, will you?
>
Okay, I think I delivered all my points. I'm going not going to say
more for now.
But, please recognize that your confusion of facts with FUDs ruins the
Linux experience of many people, including those who want to "switch"
to Linux. It is really not nice to switch to a system where your
computer freezes 5 times a day. It causes bad reputation not only for
Which bug #
in bugzilla tracks this "freezing 5 times a day" that you
encountered?
Fedora, but also for Linux and free software.
I'm returning the "lier, clueless and poisonous"
accusations, and I
stand behind everything I said, which are nothing but facts, including
(but not limited to) CA is 99.99% crap; it freezes systems; it does
Which bug # in
bugzilla tracks the "freezing systems" that you
encountered?
not properly support multiple soundcards; and it must be wiped off of
Which bug # in bugzilla tracks the issue(s) you encountered with
multiple soundcards?
our planet for the good of humanity.
9:38 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, Apr 24, 2009 at 6:26 PM, Orcan Ogetbil <oget.fedora(a)gmail.com> wrote:
<snip>
it does
not properly support multiple soundcards;
WTF?
Multiple soundcard support is one of the reasons why I don't want to
go back to raw alsa (where this is a pain).
I can hotplug soundcards, move streams between without having to
reconfigure or restarts apps.
10:28 a.m.
New subject: PulseAudio and sound apps (was: Re: Orphaning a few packages)
On Fri, 2009-04-24 at 11:18 -0400, Orcan Ogetbil wrote:
On Fri, Apr 24, 2009 at 9:43 AM, Lennart Poettering wrote:
>
> Better still then using the card name is using the hal path or some
> udev path/identifier for identifying cards. PA does that.
>
> Lennart
>
Lennart,
please stop implying CA supporting features that it actually can't. CA
does not work with multiple soundcards. AT ALL... (tested it with 100%
different hardware, different machines)
It might be working on your system and possibly a handful of other
people's. But that's all.
Oh, would you please just *shut up*.
I have four output devices in my system. Each is correctly identified
and I can move output across them at will. No, I am not being paid by
Lennart to say this, and I did not drink the Kool-Aid, I can just
recognize working software when I see it.
Anyone who was to claim Pulse was perfect and worked for everyone would
be wrong, but you claiming it works for no-one but Lennart and his
sinister sidekicks is equally absurd.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:23 a.m.
Matthias Saou wrote:
Hi,
Though having been able to dedicate a lot less time than before to
Fedora during the past few years, I still maintain all of the packages
I own as well as I can. But some packages I have lost interest in, and
have become a burden to maintain. I'm sure others who are still using
them would do a better job than me at maintaining them, which is why I'd
like to orphan the following packages (open bugzilla reports listed for
reference) :
* djvulibre : 443953, 444699
* js: 341631
* moin : lots
* ucarp : 247082, 427495, 449266, 455394, 458767
* portaudio : 478719
I'll proceed to releasing ownership in the pkgdb now. I'm particularly
ashamed of the shape I've left moin in... please forgive me. I really
hope someone will be able to give these the attention they deserve!
Matthias
I've taken ucarp.
--
in your fear, speak only peace
in your fear, seek only love
-d. bowie
2:51 p.m.
Matthias Saou пишет:
Hi,
Though having been able to dedicate a lot less time than before to
Fedora during the past few years, I still maintain all of the packages
I own as well as I can. But some packages I have lost interest in, and
have become a burden to maintain. I'm sure others who are still using
them would do a better job than me at maintaining them, which is why I'd
like to orphan the following packages (open bugzilla reports listed for
reference) :
* djvulibre : 443953, 444699
* js: 341631
I take it
2:54 p.m.
Matthias Saou пишет:
Hi,
Though having been able to dedicate a lot less time than before to
Fedora during the past few years, I still maintain all of the packages
I own as well as I can. But some packages I have lost interest in, and
have become a burden to maintain. I'm sure others who are still using
them would do a better job than me at maintaining them, which is why I'd
like to orphan the following packages (open bugzilla reports listed for
reference) :
* djvulibre : 443953, 444699
* js: 341631
I've taken js.
5477
days inactive
5491
days old
57 comments
18 participants
participants (18)
-
Adam Williamson -
Bill Nottingham -
Callum Lerwick -
David Malcolm -
drago01 -
Fernando Lopez-Lezcano -
Hans de Goede -
Ignacio Vazquez-Abrams -
Jeff MacDonald -
Jon Ciesla -
Kevin Kofler -
Lennart Poettering -
Matthias Clasen -
Matthias Saou -
Michael Schwendt -
Orcan Ogetbil -
Pavel Alexeev (aka Pahan-Hubbitus) -
Ville-Pekka Vainio