#265 oget refuses to enable fluidsynth's PulseAudio backend
Closed None Opened 14 years ago by kkofler.

Fluidsynth is a software implementation of the ALSA sequencer API, which (unlike alternatives like timidity) can be controlled through a GUI (qsynth). The fluidsynth project is now (as of version 1.0.9) supporting !PulseAudio with a native backend (its ALSA backend doesn't work properly with !PulseAudio, see [https://bugzilla.redhat.com/show_bug.cgi?id=500087]). It is important for Fedora packages to support Fedora's default sound solution. But the maintainer, Orcan Ogetbil (oget), refuses to enable this support (which nobody would be forced to use, it'd be just another option next to JACK and ALSA) for no other reason than that this makes fluidsynth require pulseaudio-libs: [https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13] and he hates !PulseAudio. (Unfortunately, subpackaging is not an option as the backends are all statically compiled into the one shared library.) That argument makes no sense to me as pulseaudio-libs is basically required anyway (due to dependencies in other packages), even if you don't use !PulseAudio. But oget insists and refuses to change anything. His argument that fluidsynth is exclusively for audio production and thus only needs to support JACK is not valid as the ALSA sequencer interface is also used by desktop-user-oriented pure playback apps like KMid.

I consider it to be completely against Fedora's interests to actually DISABLE a !PulseAudio backend where upstream provides one unless it's broken, so I would like FESCo to rule that fluidsynth must be built with !PulseAudio support. Part of shipping a default audio solution is to make sure the distribution supports it wherever possible.


Yeah I agree here, disabling the PA backend for political reasons like that "I hate PA so I won't build support for it" is just ridiculous.

If there where technical reasons fine, but this one is pure BS.

Hmm...

A ticket containing false information got opened with my name on it, only hours before the FESCo meeting, and the topic got discussed and a decision has been made.

I wasn't even given the opportunity to correct the false information given in the ticket, let alone to defend my views. (I was away from internet since yesterday).

What is the hurry? Do I at least have a right to appeal?

Sure. According to the bug report, however, and this may or may not be accurate, is that you have to remove pulseaudio-libs in order to effectively use fluidsynth. I just installed fluidsynth, and it's use is beyond me, so I can't independently confirm or deny that it works on my system (which uses PA).

But if there's more information that we didn't cover during the meeting, we'd be more than happy to hear it.

What information I posted in the ticket is false?

The way we came to this point consists of a chain of ironies. Let me briefly go over these.

The Audio Production team took a long way to get to this point. With a considerably large selection of tools which work in a harmony (mainly thanks to Jack), and libraries that these tools are link to, a comparison with other distros shows that we are offering the latest and most reliable audio production software among all distributions. Here "we" refers to the joint efforts of our team and the PlanetCCRMA. The difference between two cannot even be made in certain cases. I, as the most active member of the Audio production team, am proud to be here at this point. And I believe that I am doing a good job. To make this claim solid, you can have a look at the number of bugs assigned to me and see how many of them are still open and how many were resolved.

Over the last week I was going over the open bugs that weren't even assigned to me, just to minimize F-12 bugs as much as I can. I even fixed a bug of a package, which was open for months, that I wasn't a comaintainer or maintainer of it but the ticket opener was. I also came across this fluidsynth bug and posted the information why it was not built against pulseaudio. I was not in the CC of this bug because I didn't get ACLs for fluidsynth until after the bug was filed. The bug was open for months and it was likely to be kept open many more months if I did not find it in the list and I did not reply. Considering the number of people who are happy with our current status, and there is only one unhappy user who filed the bug, I consider our team successful. This is indeed an example of the fact that you cannot make everyone happy.

The base argument of the ticket relies on making packages compatible with Fedora "defaults". The biggest irony here is that the person who filed the ticket is the most active fighter against certain Fedora defaults. I don't think anyone in Fedora family will not find this ironic.

Now some corrections:

Fact 1: I am a man of love. I don't hate any piece of software. In fact, there is no entity in the face of the earth that I hate. I even try to teach love to my kid, my students, my colleagues. Hate is not a healthy emotion. Hate leads to suffering. Please be careful and think twice before accusing people with hatred.

Fact 2: I cannot orphan fluidsynth no matter what decision comes out of FESCo. Why? Because '''I am not the primary maintainer of fluidsynth! ''' I am just a comaintainer. I wish a FESCo member looked at pkgdb before talking about orphaning/taking over of fluidsynth.

Fact 3: If fluidsynth works perfect without pulseaudio, and if it stops working upon installation of alsa-plugins-pulseaudio, then this shows that pulseaudio is poorly written: '''This is a bug of pulseaudio.''' Enabling the pulseaudio backend in fluidsynth is a workaround and not a solution. I do not have the obligation to workaround bugs of pulseaudio in fluidsynth.

Now here comes my defense:
Gnome, a default which the ticket opener makes his biggest fights on, might be ugly, counter-intuitive, unconfigurable for some people. It is their opinions and this is normal. But gnome is not harmful. On the other hand, pulseaudio is not only poorly written but also '''harmful''' [1]. I am trying to find a time slot to collect necessary evidence to file a request to FESCo to get it removed from (or at least made non-default in) Fedora.

I hereby declare that I am '''not''' going to promote or support pulseaudio whatsoever. Since we do all our Fedora work voluntarily, we have the right to choose what we want to support. I choose to not support pulseaudio. I find pulseaudio a shame to Fedora and I believe that it is a growing burden that is slowing down Fedora and thus the Linux/free software community. Besides, pulseaudio is definitely not needed for audio production, as was said by the primary pulseaudio developer.

Fluidsynth is a very important library for MIDI and it has been one of our ("our" means Audio Production people's) building blocks. Currently, there are about 15 packages that depend on it. With the dependencies of dependencies, I think the number goes above 20 and I am the primary maintainer of many of these packages. Many of these are essential packages for audio production. I was trying to say that in case fluidsynth is compiled against pulseaudio, I will choose to drop my support from all of them. This means, if fluidsynth is a direct dependency, I will orphan the package. If it is optional, I will compile the package without fluidsynth support. I repeat that this is my choice. However, at the end of the day this will piss of many of our users, and in fact Fedora will not be the best audio production distro anymore.

"Fedora is a distro, it is not a collection of incompatible packages" is a valid argument. Our audio production packages are indeed compatible with each other. And I do not want to introduce a possible incompatibility (the poorly written pulseaudio) to our stack.

So FESCo's decision is not just about whether a library should be linked against another one or not. It is about what community they want Fedora to support. An important fraction of the audio production community or certain people who are not into audio production but want to listen to midi files just for the fun of it? Midi files are not like MP3's, OGG's. How many people do you know who fill their IPOD's with Midi files? Midi files are indeed tools for audio production. I would like FESCo to reconsider their decision keeping the big picture in mind.

In either case, if some packages are decided to be re-owned, I hope that they are taken over by someone who really knows about audio production (plays at least a couple instruments, did some sort of audio recording, mixing in the past etc).

A possible '''solution''' that I want to propose:

If we really have to taint or audio production stack with pulseaudio, FESCo can assign someone to take care of pulseaudio origined bugs that will be filed against our audio production software. I really do not have the time, will and energy to deal with them. I don't think anyone in the team does. The best we can do is to direct these bugs to the assignee. However, this, I believe, has the potential of decreasing our quality.

Best,

Orcan Ogetbil

[1] http://osdir.com/ml/fedora-devel-list/2009-04/msg01849.html''''''

and there is only one unhappy user who filed the bug

There is also me genuinely interested in using fluidsynth with !PulseAudio, and a few more people are CCed to the bug, so I presume they are, too.

This is a bug of pulseaudio.

No, it's a bug in fluidsynth, it is not using the ALSA API correctly.

Enabling the pulseaudio backend in fluidsynth is a workaround and not a solution.

It is a solution. A native backend is preferred over using the ALSA plugin, even if the ALSA backend were actually working with the !PulseAudio ALSA plugin. (That said, fluidsynth's ALSA backend ideally should be fixed, too.)

On the other hand, pulseaudio is not only poorly written but also harmful [1].

That's a bug in an ALSA hardware driver which !PulseAudio just happens to expose.

I am trying to find a time slot to collect necessary evidence to file a request to
FESCo to get it removed from (or at least made non-default in) Fedora.

Good luck! (Count on me to vote it down.)

Since we do all our Fedora work voluntarily, we have the right to choose what we
want to support. I choose to not support pulseaudio.

We just voted that you can't do that. If you're not happy, feel free to leave.

If it is optional, I will compile the package without fluidsynth support.

So do we need another ruling that you can't do that? :-/ Sabotaging things just to avoid an indirect dependency on pulseaudio-libs is not a solution. And in fact, I think you'll have to orphan a lot of stuff if you want to orphan everything indirectly depending on pulseaudio-libs.

"Fedora is a distro, it is not a collection of incompatible packages" is a valid
argument. Our audio production packages are indeed compatible with each other. And
I do not want to introduce a possible incompatibility (the poorly written
pulseaudio) to our stack.

Enabling the fluidsynth !PulseAudio support doesn't introduce !PulseAudio into the audio stack at all. In fact, it doesn't even require the pulseaudio package, only pulseaudio-libs, which is also dragged in by many other packages in the distribution. I doubt you can do any serious audio production on a current Fedora 11 or 12 without pulseaudio-libs installed, at least not if you don't use --nodeps or similar hacks (and even then, things might just not start because they're missing the library they're linked to). And using the pulseaudio backend would just be an '''option''' for the user. It wouldn't even be the default. They can keep on using JACK or straight ALSA as always. I don't see how providing that option is an issue at all.

Replying to [comment:6 kkofler]:

This is a bug of pulseaudio.

No, it's a bug in fluidsynth, it is not using the ALSA API correctly.

Wrong. This is not the first time pulseaudio tried to block something related to realtime scheduling (mmap etc). The fluidsynth is doing correct.

Enabling the pulseaudio backend in fluidsynth is a workaround and not a solution.

It is a solution. A native backend is preferred over using the ALSA plugin, even if the ALSA backend were actually working with the !PulseAudio ALSA plugin. (That said, fluidsynth's ALSA backend ideally should be fixed, too.)

You shouldn't fix something that is not broken. Actually this is what pulseaudio tries to accomplish too: it is a solution in search of a problem. <-- Google this phrase with "pulseaudio". No wonder that you like pulseaudio. I am disappointed with you, in that most KDE folks that I know are against it too.

Since we do all our Fedora work voluntarily, we have the right to choose what we
want to support. I choose to not support pulseaudio.

We just voted that you can't do that. If you're not happy, feel free to leave.

This is so not nice. I remind you that you are a member of FESCo.

Enabling the fluidsynth !PulseAudio support doesn't introduce !PulseAudio into the audio stack at all. In fact, it doesn't even require the pulseaudio package, only pulseaudio-libs, which is also dragged in by many other packages in the distribution. I doubt you can do any serious audio production on a current Fedora 11 or 12 without pulseaudio-libs installed, at least not if you don't use --nodeps or similar hacks (and even then, things might just not start because they're missing the library they're linked to).

Wrong. I have a "rm -f /usr/lib/libpulse" kind of hack in my cron jobs and everything works perfect.

And using the pulseaudio backend would just be an '''option''' for the user. It wouldn't even be the default. They can keep on using JACK or straight ALSA as always. I don't see how providing that option is an issue at all.

It is an issue since pulseaudio is terrible with dealing real-time scheduling, which is a must in audio production. Can you tell me your use case of pulseaudio+fluidsynth? What will you say when a user files a bug and complains that pulseaudio leaves annoying gaps and cracks in his recordings?

Wrong.

Prove that fluidsynth's use of the ALSA API is correct then. The PA ALSA plugin works fine with many other apps, so I'm fairly sure fluidsynth is doing something wrong.

This is not the first time pulseaudio tried to block something related to realtime scheduling (mmap etc).

mmap support is an OPTIONAL part of the ALSA spec which drivers explicitly DO NOT HAVE to support. In fact there are even some HARDWARE drivers which, for various technical reasons, do not support mmap. Applications using the mmap API MUST have a fallback to the plain read/write API, or they're NOT compliant with the ALSA spec. And such API abuse is an application bug. Not supporting mmap is NOT a bug in the PA ALSA plugin.

But in this case, I suspect this is some other API abuse, such as abusing functions which check the current buffer state for synchronization or the other way round. (There are 2 different functions for those 2 different purposes for a reason.) But I really don't have the time to debug this, nor do I think it's worth it as native PA support is available.

You shouldn't fix something that is not broken.

It is. See above for a more detailed explanation.

I am disappointed with you, in that most KDE folks that I know are against it too.

The Fedora KDE SIG works hard on integrating with shared Fedora technologies, especially in cases like this where it's needed for interoperability. (We don't want KDE apps and GNOME apps stealing the audio devices from each other.) Look forward to improved Phonon support for PA in Fedora 13 (thanks to Colin Guthrie from Mandriva). (And BTW, that means Phonon will be linked to libpulse and thus your rm -f hack will break KDE.)

Wrong. I have a "rm -f /usr/lib/libpulse" kind of hack in my cron jobs and
everything works perfect.

That is, as you write yourself, a hack. And I don't see what this is supposed to accomplish. Having the library installed doesn't change anything if you don't run the daemon.

It is an issue since pulseaudio is terrible with dealing real-time scheduling,
which is a must in audio production.

But your audio production users ARE NOT REQUIRED to use PA just because fluidsynth is built to OPTIONALLY SUPPORT it! You can choose between at least 3 backends, 2 of which are the same 2 backends available now, PA would just be the 3rd option.

Can you tell me your use case of pulseaudio+fluidsynth?

Listening to MIDI files with KMid. The other users CCed on the bug may have other usecases.

What will you say when a user files a bug and complains that pulseaudio leaves
annoying gaps and cracks in his recordings?

If you think it's related to fluidsynth, ask the reporter to report it to fluidsynth upstream as they're the ones providing the PA backend, if you genuinely think it's PA's fault, reassign it to Lennart. While PA is not designed for audio production, that doesn't mean basic sound recording is not supposed not be free of gaps and cracks. And you don't have to fix the bugs in the PA backend yourself.

I am not going to take the dialog further as it won't accomplish anything.

I stated my reasons for not supporting pulseaudio and I even proposed a solution. I will respect FESCo's decision.

Replying to [comment:10 jstanley]:

closing ticket

So my objection and proposal will not be considered?

I thought that you had dropped them - did I read your last comment wrong? I'd be more than happy to reopen it if I did :)

What I meant was, I will respect FESCo's decision after they review and discuss my objection. I really do not want to ruin our audio production stack with pulseaudio. But if you feel like we really must do this, I proposed the assignment of someone by FESCo to take care of pulseaudio originated bugs that will be filed against our audio production stack.

For instance:
If someone files a bug to our "muse" package which directly depends on fluidsynth, complaining that muse fails to work when he uses it with pulseaudio, we will not try to debug this. Supporting Pulseaudio is not within our scope (we = audio production team). Even the pulseaudio developer says that pulseaudio shall not be used for this purpose.

Also the last decision is flawed:

  • I cannot orphan fluidsynth even if I want to. If you want to take the package over because I do not want to support pulseaudio, you need to talk to the primary maintainer, not me. I am just a comaintainer.

I will be at work but I will try to attend the meeting today.

For the curious, to test fluidsynth:

1- do a

'''
sudo yum install qsynth jack-keyboard'''

2- Then start qsynth.

3- Go to Setup -> Audio tab. Select "alsa" for the audio driver. Click OK.

(3b-) If it asks you to restart fluid engine, say Yes.

4- Now open jack-keyboard.

5- On the "Connected to" combobox, pick one of the "midi playback" options (usually the option with the biggest index works).

6- Now click on the piano keys. You should hear the piano sound.

(6b-) If you don't hear a sound, go back to step 5 (and select a different "midi playback" option from the "Connected to" combobox.)

Please try it with both with and without alsa-plugins-pulseaudio (and pulseaudio{,-libs}) installed.

FWIW, in following those steps, all I get is jackd crashing.

@oget:

You still failed to explain why a dependency on pulseaudio-libs (it doesn't require pulseaudio itself) will even '''AFFECT''' your use case, Kevin have stated that multiple times and you seem to avoid this question (probably because you already know that you don't have a valid point here).

{{{
Wrong. I have a "rm -f /usr/lib/libpulse" kind of hack in my cron jobs and everything works perfect.
}}}

Well I can assure you that besides some saved diskspace (and an inconsistent rpm db), this gains you absolutely NOTHING (if you don't want to use pulse remove pulseaudio and/or alsa-plugins-pulseaudio).

So do you want to achieve here? Just blocking a feature that users want (see the bug report for evidence) for NO reasons whatever.

Sorry but I disagree that you are doing a "good job" here as you explained above.

Sorry if the words sound a bit harsh this isn't meant to be a personal attack, but I just upset about this IMHO childish behavior. (I do not like $software [1], so I do whatever I can to make the life of its users harder, should not be acceptable).

If you have technical reasons, fine, we can live with it until somebody who cares fixes them. But in your case you simply block a feature for political reasons that do even harm users and gains you (or anybody else) NOTHING.

Please fight your war against PA somewhere else (or not at all) but not at the cost of our users.

1: You stated that you do not hate PA, which might be true or not but your comments indicate otherwise, you try to sabotage it wherever possible.

Of course you are free to prove me wrong but actual facts can backup my claim, while yours simply mean (I hate to repeat myself). "I don't like PA so I will do whatever I can to kill it".

Replying to [comment:16 drago01]:

@oget:

You still failed to explain why a dependency on pulseaudio-libs (it doesn't require pulseaudio itself) will even '''AFFECT''' your use case, Kevin have stated that multiple times and you seem to avoid this question (probably because you already know that you don't have a valid point here).

drago01, please re-read comment #13. There I gave an example of a technical reason.
I am afraid that people will file bugs against audio production applications that use fluidsynth, and complain that they don't work with pulseaudio. But they are not expected to work with pulseaudio in the first place.

For instance, such a situation occurred in the bug with the link given in the original post above. The user complains that fluidsynth doesn't work if alsa-plugins-pulseaudio is installed. Only after removing the alsa-plugins-pulseaudio package, he says, he has a low latency midi application. Now the proposal is to build the pulseaudio backend into fluidsynth. But if we compile fluidsynth with pulseaudio, he will not get a low latency midi application anyway, because pulseaudio does not work in low latency, as was said by its developer. So, compiling pulseaudio support into fluidsynth is not a solution for this problem. He needs to use jack.

I don't need to support pulseaudio in midi applications for professional work. Nobody does.

{{{
Wrong. I have a "rm -f /usr/lib/libpulse" kind of hack in my cron jobs and everything works perfect.
}}}

Well I can assure you that besides some saved diskspace (and an inconsistent rpm db), this gains you absolutely NOTHING (if you don't want to use pulse remove pulseaudio and/or alsa-plugins-pulseaudio).

I gave this as an evidence against a claim from comment #6: "(and even then, things might just not start because they're missing the library they're linked to)"

I tried achieve nothing more than that. I did not and will not recommend this to any user, unless they specifically ask for it.

Sorry if the words sound a bit harsh this isn't meant to be a personal attack, but I just upset about this IMHO childish behavior. (I do not like $software [1], so I do whatever I can to make the life of its users harder, should not be acceptable).

No offence taken. The facts that

  • I have never had problems with audio since RH 7.0 in any of the computers I had until pulseaudio came up,

  • I have never personally met anyone who had audio problems with OSS or ALSA in this timeframe,

  • I have not seen a computer with a working pulseaudio setup with my bare eyes,

  • Pulseaudio caused data loss and damaged hardware in my wife's computer,

  • So many workaround are out there written in HOWTO format to bypass pulseaudio in various distros

might have reinforced my distance to pulseaudio. But this is not hate. Hate has a different meaning.

Sorry, I couldn't make it to the meeting today. I will try hard next week.

Replying to [comment:15 notting]:

FWIW, in following those steps, all I get is jackd crashing.

I suspect that jack is selected as the MIDI driver or the Audio driver in QSynth. Make sure you have alsa_seq and alsa selected, respectively.

Or alternatively, you can setup jack as outlined in
/usr/share/doc/jack-audio-connection-kit-0.116.1/README.Fedora
(this is the way we set things up), but then you will need to logout/relogin.

I gave this as an evidence against a claim from comment #6: "(and even then,
things might just not start because they're missing the library they're linked
to)"

As I wrote in comment:8, this will no longer work in Fedora 13, you will break your KDE by removing libpulse.

In fact, I'm surprised this works at all, but it must be because things like xine-lib have a plugin architecture and only dlopen the backend they actually use (something fluidsynth should be doing too, because then we could ship the different backends as subpackages, but that's an upstream issue).

Replying to [comment:17 oget]:

For instance, such a situation occurred in the bug with the link given in the original post above. The user complains that fluidsynth doesn't work if alsa-plugins-pulseaudio is installed. Only after removing the alsa-plugins-pulseaudio package, he says, he has a low latency midi application.

Yeah I saw that, asking a user to remove another software for yours to work is one of the worst suggestions ever. Building the PA backend would fix that by simply talking to PA instead of trying to use mmaped alsa.

Also I don't buy the "it is not supposed to work with PA" comment, because why on earth do upstream ship a backend that is not supposed to work?

It might not be the best choice for every use case but that does not mean "it is not supposed to work".

No offence taken. The facts that

  • I have never had problems with audio since RH 7.0 in any of the computers I had until pulseaudio came up,

Well PA works fine for me (had only minor issues due to broken sound drivers that where fixed).

  • I have never personally met anyone who had audio problems with OSS or ALSA in this timeframe,

Well many people had the "one app blocks everything" issue with OSS, and ALSA isn't really easy to configure if you have multiple sound cards, you have to use modprobe hacks like passing an index to the sound driver module.

  • I have not seen a computer with a working pulseaudio setup with my bare eyes,

Should I send you a photo of one of mine? ;)
Did you seen any Palm Pre owner complaing about sound not working? (it is using PA for sound).

  • Pulseaudio caused data loss and damaged hardware in my wife's computer,

That is a pretty far fetched claim. A crash might cause data loss but I can't see how pa can damage your hardware, please back that up else this is pure FUD.

  • So many workaround are out there written in HOWTO format to bypass pulseaudio in various distros

Sure there are bugs and apps that do not behave well, so there are HOWTOs to cover that.
But you get this with every change, same happened for the OSS->ALSA move, the firewire stack switch etc.

might have reinforced my distance to pulseaudio. But this is not hate. Hate has a different meaning.

I never used the word hate in comment.

Replying to [comment:20 drago01]:

Replying to [comment:17 oget]:

For instance, such a situation occurred in the bug with the link given in the original post above. The user complains that fluidsynth doesn't work if alsa-plugins-pulseaudio is installed. Only after removing the alsa-plugins-pulseaudio package, he says, he has a low latency midi application.

Yeah I saw that, asking a user to remove another software for yours to work is one of the worst suggestions ever.

I didn't give such a suggestion to this user.

Building the PA backend would fix that by simply talking to PA instead of trying to use mmaped alsa.

No. Building pulseaudio backend will not be a solution for him. He wants to have low latency keyboard. With pulseaudio he will get a working keyboard but it will not be low latency. Thus it will be useless. I thought I explained this.

He needs to use pure alsa (by removing alsa-plugins-pulseaudio) or use jack. Using jack is the correct solution because his goal of low latency is jack's purpose.

Here you can see the fundamental flaw of pulseaudio. It tries to achieve everything in userspace. It runs a daemon for this purpose. You can't have low latency this way. You need to have sound handled globally by kernel.

Also I don't buy the "it is not supposed to work with PA" comment, because why on earth do upstream ship a backend that is not supposed to work?

Very interesting question. I have talked to the primary author in the past. Next time, I will ask this question. Thanks for bringing it up.

  • I have never personally met anyone who had audio problems with OSS or ALSA in this timeframe,

Well many people had the "one app blocks everything" issue with OSS, and ALSA isn't really easy to configure if you have multiple sound cards, you have to use modprobe hacks like passing an index to the sound driver module.

Uhm, what is so hard about passing a flag? If that's such a problem one could even write a wrapper GUI tool to adjust modprobe.conf. No need for an inferior userspace daemon to achieve things like this.

  • I have not seen a computer with a working pulseaudio setup with my bare eyes,

Should I send you a photo of one of mine? ;)

No I want to smell it :)

Did you seen any Palm Pre owner complaing about sound not working? (it is using PA for sound).

Honestly, no. But that might be because I have not seen a Palm Pre or Palm Pre owner in the first place.

  • Pulseaudio caused data loss and damaged hardware in my wife's computer,

That is a pretty far fetched claim. A crash might cause data loss but I can't see how pa can damage your hardware, please back that up else this is pure FUD.

It's not pure FUD. I thought I gave the link above where I gave backup... Yes I did in comment #5.

Briefly,

  • I install Fedora on wife's computer, leaving pulseaudio out.

  • Everything works fine for a while.

  • Then her computer starts to freeze randomly whenever she used a application that produced sound, some freezes cause data loss.

  • I investigate this thoroughly. I find that somehow pulseaudio made its way back in through updates or with some software she installed via yum/package kit.

  • I remove it for good and take necessary measurements (blocking pulseaudio* in yum.conf)

  • Her computer doesn't freeze anymore.

I know that it is not a 100% proof but from my experience, I am 99.9% confident that freezes were caused by pulseaudio. I am not going to reinstall pulseaudio on her computer to reproduce the freezes. She might kill me. :)

  • So many workaround are out there written in HOWTO format to bypass pulseaudio in various distros

Sure there are bugs and apps that do not behave well, so there are HOWTOs to cover that.
But you get this with every change, same happened for the OSS->ALSA move, the firewire stack switch etc.

So are we still in the transition period? How many releases has there been having pulseaudio default?

We should swallow the big piece and accept that it didn't work. I say that the pulseaudio developers have to start over. (no. not start over coding pulseaudio from nil. I meant elementary school :) )

might have reinforced my distance to pulseaudio. But this is not hate. Hate has a different meaning.

I never used the word hate in comment.

ok. Sorry if I implied you did.

Here you can see the fundamental flaw of pulseaudio. It tries to achieve
everything in userspace. It runs a daemon for this purpose.

As opposed to JACK which, well, runs a daemon in userspace? Huh?

You can't have low latency this way.

This sentence is inconsistent with your "Using jack is the correct solution because his goal of low latency is jack's purpose." sentence (which is correct, thus the claim that userspace daemons cannot provide low latency is a false one).

The truth is that PA is not primarily designed for low latency unlike JACK, but for things like ease of use etc., but it's not fundamentally impossible with PA's design to achieve a low latency. In fact, it's possible for an application to tweak PA's runtime settings to minimize latency (to the extent possible under PA): [http://pulseaudio.org/wiki/LatencyControl].

I think having 2 competing sound servers with supposedly distinct target userbases separated by an arbitrary and fuzzy line is a problem, not a solution (and that's one point of frustration I do have with PA). (It's "fuzzy" because people who are not professional audio artists work with tools like Audacity from time to time and PA is good enough for their use. Quite a few people thanked me for fixing !PortAudio and thus Audacity to work with non-mmapped ALSA and thus !PulseAudio, and I'm sure the silent happy users are many more.) This ticket shows one of the trouble points. Believe it or not, playing MIDI files (which is all the ALSA sequencer interface really is for) is not necessarily "audio creation". So there is value in fluidsynth supporting both solutions and thus both userbases. And the cost (a dependency on pulseaudio-libs, NOT on the daemon) is almost nil (as half of the distro drags that package in as a dependency anyway).

Replying to [comment:21 oget]:

Replying to [comment:20 drago01]:

Replying to [comment:17 oget]:

For instance, such a situation occurred in the bug with the link given in the original post above. The user complains that fluidsynth doesn't work if alsa-plugins-pulseaudio is installed. Only after removing the alsa-plugins-pulseaudio package, he says, he has a low latency midi application.

Yeah I saw that, asking a user to remove another software for yours to work is one of the worst suggestions ever.

I didn't give such a suggestion to this user.

OK, but your wording implied that. Still this is the only solution right now if the user does want to use it.

Building the PA backend would fix that by simply talking to PA instead of trying to use mmaped alsa.

No. Building pulseaudio backend will not be a solution for him. He wants to have low latency keyboard. With pulseaudio he will get a working keyboard but it will not be low latency. Thus it will be useless. I thought I explained this.

He needs to use pure alsa (by removing alsa-plugins-pulseaudio) or use jack. Using jack is the correct solution because his goal of low latency is jack's purpose.

Yes you did but having an option for "just works" and "I want the lowest possible latency" isn't really a bad thing.

Here you can see the fundamental flaw of pulseaudio. It tries to achieve everything in userspace. It runs a daemon for this purpose. You can't have low latency this way. You need to have sound handled globally by kernel.

Doing what pa does in the kernel isn't really a solution (if possible at all).
Also userspace does not imply high latency, does not matter how often people repeat that it does not make it true. Also jack runs in userspace.

Also I don't buy the "it is not supposed to work with PA" comment, because why on earth do upstream ship a backend that is not supposed to work?

Very interesting question. I have talked to the primary author in the past. Next time, I will ask this question. Thanks for bringing it up.

So we can trust that upstream knows there software and ship there backends rather than overriding there decision on the basis of "we don't know" ?

  • I have never personally met anyone who had audio problems with OSS or ALSA in this timeframe,

Well many people had the "one app blocks everything" issue with OSS, and ALSA isn't really easy to configure if you have multiple sound cards, you have to use modprobe hacks like passing an index to the sound driver module.

Uhm, what is so hard about passing a flag? If that's such a problem one could even write a wrapper GUI tool to adjust modprobe.conf. No need for an inferior userspace daemon to achieve things like this.

Well it is
1) a cure hack to begin with
2) you have to reload ALL sound modules for that (good luck with that if there is an app playing audio), so you end up requiring a reboot.
3) such GUI would need root access
4) You can't move an audio stream to the second soundcard without restarting it.

  • I have not seen a computer with a working pulseaudio setup with my bare eyes,

Should I send you a photo of one of mine? ;)

No I want to smell it :)

Did you seen any Palm Pre owner complaing about sound not working? (it is using PA for sound).

Honestly, no. But that might be because I have not seen a Palm Pre or Palm Pre owner in the first place.

Well OK, but do you really believe that they trust a in your view "broken software" for such an important device in there business? (which also acts as a music player so sound is important).

  • Pulseaudio caused data loss and damaged hardware in my wife's computer,

That is a pretty far fetched claim. A crash might cause data loss but I can't see how pa can damage your hardware, please back that up else this is pure FUD.

It's not pure FUD. I thought I gave the link above where I gave backup... Yes I did in comment #5.

Briefly,

  • I install Fedora on wife's computer, leaving pulseaudio out.

  • Everything works fine for a while.

  • Then her computer starts to freeze randomly whenever she used a application that produced sound, some freezes cause data loss.

  • I investigate this thoroughly. I find that somehow pulseaudio made its way back in through updates or with some software she installed via yum/package kit.

  • I remove it for good and take necessary measurements (blocking pulseaudio* in yum.conf)

  • Her computer doesn't freeze anymore.

I know that it is not a 100% proof but from my experience, I am 99.9% confident that freezes were caused by pulseaudio. I am not going to reinstall pulseaudio on her computer to reproduce the freezes. She might kill me. :)

But you can try a recent live cd and see if the issues are fixed already.
OK, so pulseaudio for some reasons was causing freezes, which did result into data loss, but where is the damaged hardware?

  • So many workaround are out there written in HOWTO format to bypass pulseaudio in various distros

Sure there are bugs and apps that do not behave well, so there are HOWTOs to cover that.
But you get this with every change, same happened for the OSS->ALSA move, the firewire stack switch etc.

So are we still in the transition period? How many releases has there been having pulseaudio default?

Yes there are still apps that do not work well with PA. (there are even ancient apps that do not work well with pure ALSA)

Replying to [comment:23 drago01]:

Replying to [comment:21 oget]:

Replying to [comment:20 drago01]:

Replying to [comment:17 oget]:

Also I don't buy the "it is not supposed to work with PA" comment, because why on earth do upstream ship a backend that is not supposed to work?

Very interesting question. I have talked to the primary author in the past. Next time, I will ask this question. Thanks for bringing it up.

So we can trust that upstream knows there software and ship there backends rather than overriding there decision on the basis of "we don't know" ?

Okay, let's assume that we build pulseaudio support into fluidsynth. That will mean we need to support midi applications with the pulseaudio backend, even pro applications like muse, or ardour3 when it comes out with midi support.

What if people start filing bugs that they have annoying gaps and cracks in their recordings? Who is going to support pulseaudio backend of these applications in Fedora? Certainly not me. Are you willing to help? Can I assign such bugs to you?

Honestly, no. But that might be because I have not seen a Palm Pre or Palm Pre owner in the first place.

Well OK, but do you really believe that they trust a in your view "broken software" for such an important device in there business? (which also acts as a music player so sound is important).

Reading so much feedback on pulseaudio on the internet makes me believe that pulseaudio only works for its developer, maybe a couple friends of him, and a few random lucky people.

Maybe that is only because only those who are unhappy are raising their voice so loud. Still, I haven't seen such an opposition against any other sound backends we had in the last 8 years (I don't know much about before 2001). Just google: " <your favorite insult>" and compare the results between 's.

I know that it is not a 100% proof but from my experience, I am 99.9% confident that freezes were caused by pulseaudio. I am not going to reinstall pulseaudio on her computer to reproduce the freezes. She might kill me. :)

But you can try a recent live cd and see if the issues are fixed already.
OK, so pulseaudio for some reasons was causing freezes, which did result into data loss, but where is the damaged hardware?

Oh, it blew up a harddrive. I initially thought that the harddrive was the main cause and it died eventually, probably because of so many improper shutdowns. But replacing the harddrive didn't stop the freezes. Wiping pulseaudio did.

  • So many workaround are out there written in HOWTO format to bypass pulseaudio in various distros

Sure there are bugs and apps that do not behave well, so there are HOWTOs to cover that.
But you get this with every change, same happened for the OSS->ALSA move, the firewire stack switch etc.

So are we still in the transition period? How many releases has there been having pulseaudio default?

Yes there are still apps that do not work well with PA. (there are even ancient apps that do not work well with pure ALSA)

I hope that before going into ancient applications, they first fix the fundamental issues with pulseaudio, such as outputting sound with common hardware such as emuk101.

By the way, I got my inspiration from this guy who was trying to make a non-ancient sound application work:
http://mail.kde.org/pipermail/amarok/2009-May/008524.html

Not sure I really want to dive into this since this smells a lot like a FUD vendetta, but here are my opinions as the PA maintainer: if this app is mostly useful for audio production it should certainly default to output to jack. That said if there's a native PA backend too there is really nor reason not to enable it. Disabling that is simply an act of dickishness. Something we hopefully don't want in Fedora.

oget is spreading fud. And it is quite obvious that it is, given that all bigger distros have adopted PA and both the Nokia N900 and Palm Pre are built on it for all things audio. I don't think there that vote of confidence is substantially more dependable then the opinion of oget. Its quite unlikely that oget is so much smarter than then combined engineering of the companies backing those distributions and devices. Also, note that the author of JACK, which is the solution so loved by oget, many times at various conferences came out in support of PA.

Anyway, I am pretty sure all discussions regarding the pros and cons of PA have already happened, no need to repeat them here in more detail. Also, even if PA was as bad as oget thinks it is this should not be any reason not to enable that plugin, given that we do ship PA and enabling the plugin but not defaulting to it comes at no cost except for pulling in a bit more code -- which is pulled in anyway by other packages.

Oops, s/I don't think there that vote/I believe that vote/

Replying to [comment:25 lennart]:

...all bigger distros have adopted PA and both the Nokia N900 and Palm Pre are built on it for
all things audio.

Hmm, industry manipulation on free software? You are going into a direction that is very open to debate but this is not the place. Why don't you send this to the devel mailing list?

Nevertheless, the fact that these companies adopted pulseaudio is enough proof that this conjecture

Its quite unlikely that oget is so much smarter than then combined engineering of the
companies backing those distributions and devices.

is not so unlikely. Nevertheless, if I were you, I wouldn't touch an area that I had no idea.

I do believe that we should do such personal attacks privately. I am sorry if I offended you personally. I appreciate all the time and effort you spend on free software. I want to believe that you are trying to do something good. But I don't appreciate your product. As I backed up, it is harmful.

Login to comment on this ticket.

Metadata