Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ALSA shouldn't be default in LMMS #1600

Closed
crank123 opened this issue Jan 11, 2015 · 101 comments
Closed

ALSA shouldn't be default in LMMS #1600

crank123 opened this issue Jan 11, 2015 · 101 comments
Labels
Milestone

Comments

@crank123
Copy link

@crank123 crank123 commented Jan 11, 2015

When using LMMS on Linux using the default settings one large problem is apparent. At any moment the sound can become very very distorted. Sometimes restarting pulseaudio will fix it. Other times you will have to restart the computer. However, switching to SDL will ALWAYS solve this problem. SDL does take up a bit more resources, but it is manageable. I ran LMMS on SDL on a RPI without overclocking while running Chromium, Scratch, and a terminal window without a hitch.

@crank123
Copy link
Author

@crank123 crank123 commented Jan 11, 2015

#1600 whoot whoot!

@diizy
Copy link
Contributor

@diizy diizy commented Jan 11, 2015

On 01/11/2015 10:52 PM, Gabe Bauer wrote:

When using LMMS on Linux using the default settings one large problem
is apparent. At any moment the sound can become very very distorted.
Sometimes restarting pulseaudio will fix it.

Don't use PulseAudio.

@crank123
Copy link
Author

@crank123 crank123 commented Jan 11, 2015

By default LMMS uses ALSA. Which is the cause of this problem. However, this problem is not apparent when using SDL. But, SDL is not the default.

@diizy
Copy link
Contributor

@diizy diizy commented Jan 11, 2015

On 01/12/2015 12:01 AM, Gabe Bauer wrote:

By default LMMS uses ALSA. Which is the cause of this problem.
However, this problem is not apparent when using SDL. But, SDL is not
the default.

ALSA works just fine. PulseAudio is the problem. Setup your ALSA backend
to use ALSA directly, instead of letting PulseAudio intercept the output.

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

IIRC it already is default on Windows, for similar reasons (the direct sound drivers had bugs that made the startup experience bad for the majority of users)

I see no problem with changing this if it is the general consensus. I'd like to hear from more people that compose on Linux @Umcaruje @unfa @mikobuntu and see if this would appease the masses.

The solution "don't use PulseAudio" is like telling Windows users not to use DirectSound, or telling Apple users not to use CoreAudio. Sometimes we have to ship with sane defaults, and we changed it on one platform for this exact reason. Reasons against it should offer some good supporting arguments. I've been using Linux for too long to still see "Don't use pulse audio" still as solutions to these things.

@diizy
Copy link
Contributor

@diizy diizy commented Jan 11, 2015

On 01/12/2015 12:55 AM, Tres Finocchiaro wrote:

IIRC it already is default on Windows, for similar reasons (the direct
sound drivers had bugs that made the startup experience bad for the
majority of users)

I see no problem with changing this if it is the general consensus.
I'd like to hear from more people that compose on Linux and see if
this would appease the masses.

The solution "don't use PulseAudio" is like telling Windows users not
to use direct sound, or telling Apple users not to use CoreAudio.
Sometimes we have to ship with sane defaults, and we changed it on one
platform for this exact reason. Reasons against it should offer some
good reasoning. I've been using Linux for too long to still see "Done
use pulse audio" still as solutions to these things.

We can expect a bit more from Linux users than we can from Windows
users. Linux users are generally more tech-savvy and know how to setup
their computers, it's a much more DIY environment.

ALSA works just fine for most people. SDL causes more overhead and is an
additional dependency which not everyone may want to install. Everyone
has ALSA installed, which makes it a safe default.

It's simply a fact that if you want to do audio work, PulseAudio is a
piece of crap. You don't need to get rid of it, just configure your
backend to use ALSA directly so that PA can't intercept it. Our user
wiki has step-by-step instructions for doing this.

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

So the argument is a dependency and performance argument?

The performance problems exist identically on all platforms, but in Windows Port Audio just doesn't work 90% of the time. Fortunately for the proprietary OSs, these SDL libraries are bundled, so the dependency argument is out the window for those platforms.

It is unfortunate that the very platform our software is built on can't use it OOTB. 😢

-Tres

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

... and from a performance perspective, from what I observe, SDL uses a lot of resources at idle, but performs quite well otherwise. This seems to be consensus on SDL in general due to the way its engine is written.

@crank123
Copy link
Author

@crank123 crank123 commented Jan 11, 2015

I completely agree. It preformed well on a Raspberry Pi using SDL. So, we know it doesn't take up THAT many resources.

@Sti2nd
Copy link
Contributor

@Sti2nd Sti2nd commented Jan 11, 2015

diizy is right in that because PortAudio is default on Ubuntu (right?) it interferes with Alsa which is default for LMMS. At least that sounds familiar, look at the last Q/A https://lmms.io/documentation/User_FAQ

We can expect a bit more from Linux users than we can from Windows
users.

It is evening out though, linux is starting to become so simple, what a shame...

@crank123
Copy link
Author

@crank123 crank123 commented Jan 11, 2015

Not every linux user is advanced. If you are new and just want to install LMMS and have it work out of the box than it would make sense to have SDL by default. You want this project to get better right? If your answer was yes than you should do everything in your power to do so. Which, would include making the audio work universally out of the box. If your answer was no than you should have nothing to do with the project.

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

diizy is right in that because PortAudio is default on Ubuntu (right?) it interferes with Alsa which is default for LMMS.

Is this a statement or a question? Have you ever composed on Linux? If you're saying he's right about the wiki, we can deduct that ourselves, thank you. Peanut gallery is over to the right.

It is evening out though, linux is starting to become so simple, what a shame...

Is has been this way for years and years. So has PulseAudio. PulseAudio pisses off many Linux users, however with its anger it has brought some of the most basic multi-tasking capabilities out of cheap sound cards that seemed to have previously fought over sound devices (and one of them would lose, making life even sadder for most end-users).

If we want to fight a battle against PulseAudio, this is the wrong place to do it. If SDL fixes this, we can always offer lmms-nosdl to the purists while giving sane defaults to the masses. I personal prefer stuff that works out of the box. When I install a DAW often I don't even know if I'm going to use it for more than a day. If the audio doesn't work OOTB, it does more to damage that software than it does PulseAudio.

@crank123
Copy link
Author

@crank123 crank123 commented Jan 11, 2015

And, switching to SDL doesn't mean you can't switch back. There is a reason for the settings. That being said, I do like the idea of the simple lmms-nosdl.

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

... but that said, I do agree with Vesa that the average Linux user is used to this sort of crap. That's why I'd like to sample the Linux users a bit. I'd like to know how the community usually configures their system and if the majority of them are already doing this, or if they are utilizing our workarounds in our wiki.

@Sti2nd
Copy link
Contributor

@Sti2nd Sti2nd commented Jan 11, 2015

Is this a statement or a question? Have you ever composed on Linux?

Statement, but it is a long time ago since I used Ubuntu now, and if I recall correctly they changed sound driver sometime the last five years? That is why I were unsure what sound driver they use now. Talking about Ubuntu.

PulseAudio pisses off many Linux users,

Oh, so it isn't just a LMMS problem? I agree on that out of the box is the best, so yes, if SDL works on more distros/computers it should be default on linux too

@tresf tresf added the enhancement label Jan 11, 2015
@tresf tresf added this to the 1.2.0 milestone Jan 11, 2015
@crank123
Copy link
Author

@crank123 crank123 commented Jan 11, 2015

Linux users who have used for more than a year are generally used to crap like this. But, that is exactly what it is...crap. Users shouldn't be force to go through useless steps to get a single application to work.

@diizy
Copy link
Contributor

@diizy diizy commented Jan 11, 2015

On 01/12/2015 01:20 AM, Gabe Bauer wrote:

Not every linux user is advanced. If you are new and just want to
install LMMS and have it work out of the box than it would make sense
to have SDL by default. You want this project to get better right? If
your answer was yes than you should do everything in your power to do
so. Which, would include making the audio work universally out of the
box. If your answer was no than you should have nothing to do with the
project.

Opinions are like arseholes: everyone has one.

It's obvious that this is going nowhere. We've heard your view,
repeating it over and over is not going to change anything. I consider
this issue closed.

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

If your answer was no than you should have nothing to do with the project.

Careful... These are fighting words and Vesa's opinion matters here regardless of whether or not you agree with it. Furthermore, he does belong on this project. He's our 2nd most active coder in the history of ever. (both 2nd and 3rd according to our about dialog). Let's not bite the hand that feeds us now. :)

@diizy
Copy link
Contributor

@diizy diizy commented Jan 11, 2015

An audio software/DAW is not like a notepad or a browser flash game. It requires some investment and RTFM to get going. That's how it should be. LMMS does not need to be "a DAW for the dummies" and we really need to be careful not to head towards that direction. I've written about the reasons why we should avoid that before on the mailing list, and don't really care to repeat it here...

ALSA is currently the backend that works the most reliably and provides the best performance on Linux. I see no reason to change the default.

However, there has been talk about making the configuration of the ALSA backend easier. The idea was to replace the "device" textbox with a dropdown menu, similar to how Audacity handles it. This way configuring your ALSA backend properly becomes much easier and possibly less of a hassle for a beginner.

@tresf
Copy link
Member

@tresf tresf commented Jan 11, 2015

It requires some investment and RTFM to get going. That's how it should be. LMMS does not need to be "a DAW for the dummies" and we really need to be careful not to head towards that direction.

I think the creative process appeals differently to all types of artists. I also feel there is a difference between an "Easy Button" and saner defaults. This is why I think opinions matter here. Hopefully we'll get some more feedback about this....

What happens if SDL is not available? Does it fall back to Dummy Audio, or does it fall back to ALSA?

@Umcaruje
Copy link
Member

@Umcaruje Umcaruje commented Jan 12, 2015

I'd like to sample the Linux users a bit. I'd like to know how the community usually configures their system and if the majority of them are already doing this, or if they are utilizing our workarounds in our wiki.

I use ALSA, but I always specify my device. If I leave it at default PulseAudio adopts it and the sound becomes crap. As a linux user I don't see why SDL shouldn't be default though. Its the only audio backend that worked out of the box every time, on any platform.

Also, SDL does not take over your soundcard like ALSA. Sure, it is more CPU heavy, but its a relief for people with only one soundcard, which I guess is most of our users (I do not fall in that category though).

@softrabbit
Copy link
Member

@softrabbit softrabbit commented Jan 12, 2015

Could be that the LMMS ALSA output isn't 100% compatible with PulseAudio. Did a quick test, and on this system it went like this:

  • ALSA "default" -> PA: distorted sound
  • ALSA -> hw:0,0: OK
  • SDL -> PA (not sure if this goes through some ALSA interface as well): OK
  • straight to PA: OK

I won't make any guesses at this point whether it's LMMS or PA that's buggy.

@tresf
Copy link
Member

@tresf tresf commented Jan 12, 2015

So should PulseAudio be default then? That way we are not relying on optional packages?

I started looking around for the SDL packages last night on Ubuntu and wasn't able to find them. Are they installed by default now? Is the dependency argument moot for the *buntus?

@tresf
Copy link
Member

@tresf tresf commented Jan 12, 2015

Edit... PA says "Bad latency!", so I assume that isn't a good option.

@diizy
Copy link
Contributor

@diizy diizy commented Jan 12, 2015

On 01/12/2015 12:14 PM, Raine M. Ekman wrote:

Could be that the LMMS ALSA output isn't 100% compatible with
PulseAudio. Did a quick test, and on this system it went like this:

  • ALSA "default" -> PA: distorted sound
  • ALSA -> hw:0,0: OK
  • SDL -> PA (not sure if this goes through some ALSA interface as
    well): OK
  • straight to PA: OK

I won't make any guesses at this point whether it's LMMS or PA that's
buggy.

Yeah, what we need is to get the Jack backend working. It's the only
real option for pro-quality audio on Linux, which also allows other
sound sources working at the same time.

And to do that we need to make the engine RT-safe...

@diizy
Copy link
Contributor

@diizy diizy commented Jan 12, 2015

On 01/12/2015 03:33 PM, Tres Finocchiaro wrote:

So should PulseAudio be default then?

PA is the worst possible choice for audio work. Latencies are horrible,
etc. If SDL uses PA as a backend then SDL probably will have problems
with latencies as well.

I see absolutely no point in encouraging users to use inferior backends
just to make it "easier" for them - it'll only hurt them in the long
run, they'll have to learn how to setup their system anyway. I
personally have no interest whatsoever in creating a "toy DAW for
dummies". The whole mentality where everything has to "just work" - even
at the cost of functionality - is the problem with software these days,
everything getting dumbed down... we can expect more from our users.

@tresf
Copy link
Member

@tresf tresf commented Jan 12, 2015

If SDL uses PA as a backend then SDL probably will have problems with latencies as well.

That is a good point. @Umcaruje can you confirm this?

The whole mentality where everything has to "just work" - even at the cost of functionality - is the problem with software these days, everything getting dumbed down... we can expect more from our users.

Perhaps what you are describing is a growing problem, but the problem in bug #1600 is not about things being dumbed down. It's not about coddling our users. This is about a default setting that breaks our software for most users and if we have the ability to improve this out of the box.

I still fail to see what this setting hurts. If your argument has merit, why don't we force "DummyAudio" by default so that the masses on Linux are forced to learn and investigate their back-end?

@diizy
Copy link
Contributor

@diizy diizy commented Jan 12, 2015

On 01/12/2015 04:47 PM, Tres Finocchiaro wrote:

I still fail to see what this setting hurts.

Performance.

What we should do (as I already mentioned) is make configuring the ALSA
backend easier. Replace textbox with dropdown. Instead of offering an
inferior backend to make things "easier", offer the users the tools they
need to more easily setup their system for good quality audio playback.

@crank123
Copy link
Author

@crank123 crank123 commented Apr 7, 2015

Agreed

@eagles051387
Copy link

@eagles051387 eagles051387 commented Apr 7, 2015

If toby brought SDL up in the mixer code, should we do that across the
board?

On Tue, Apr 7, 2015 at 2:49 AM, Gabe Bauer notifications@github.com wrote:

Agreed


Reply to this email directly or view it on GitHub
#1600 (comment).

Jonathan Aquilina

@tresf
Copy link
Member

@tresf tresf commented Apr 7, 2015

If toby brought SDL up in the mixer code, should we do that across the board?

This was already identified and asked above.

@curlymorphic
Copy link
Contributor

@curlymorphic curlymorphic commented Apr 7, 2015

Unfortunately I cant help with the decision, I cant make up my mind what is a better approach. My inner geek is shouting leave it as it is. The rest of me says SDL, you dont get a second change to make a first impression.

really sorry I cant be of more help :(

@tobydox
Copy link
Member

@tobydox tobydox commented Apr 9, 2015

Suggestion: runtime detection of whether PulseAudio (do not mix up with PortAudio!) is running or not. If not, always prefer ALSA because all other backends like SDL introduce an additional layer causing additional problems and/or latencies.

The AudioDevice class could have another virtual method which returns whether the backend-specific implementation is available/running on that platform. Before probing AudioDevice-classes in a certain order, the Mixer could call this new method for all backends (BTW: we should rename AudioDevice to AudioBackend) and if one returns true, it's chosen first.

@tresf
Copy link
Member

@tresf tresf commented Apr 9, 2015

Always prefer ALSA because all other backends like SDL introduce an additional layer causing additional problems and/or latencies.

Normally, I'd agree with this statement, but as can be observed in my testing, our ALSA instructions cause more work for the end-user and in the average-user-use-case examples, provided equal or worse output (despite slightly better performance), see MOMO64 TEST above.

PulseAudio seems to be the black sheep here because it notoriously has been awful, but that's not necessarily the case anymore as in testing it performed just as well as SDL on the modern *buntu flavors out of the box (which wasn't the case years ago -- thus we've removed the warning). SDL on the other hand seems to "just works" on all platforms.

I'm not trying to form a camp around a particular setting, I just have a hard time telling people ALSA should be default when our own wiki instructions don't work out of the box.

do not mix up with PortAudio

Speaking of PortAudio... If we could fix the issues with DirectSound on Windows, that would be a viable default back-end as well I feel... :)

@unfa
Copy link
Contributor

@unfa unfa commented Apr 11, 2015

On 12 Jan 2015 15:23, "Vesa V" notifications@github.com wrote:

On 01/12/2015 03:33 PM, Tres Finocchiaro wrote:

So should PulseAudio be default then?

PA is the worst possible choice for audio work. Latencies are horrible,
etc. If SDL uses PA as a backend then SDL probably will have problems
with latencies as well.

I see absolutely no point in encouraging users to use inferior backends
just to make it "easier" for them - it'll only hurt them in the long
run, they'll have to learn how to setup their system anyway. I
personally have no interest whatsoever in creating a "toy DAW for
dummies". The whole mentality where everything has to "just work" - even
at the cost of functionality - is the problem with software these days,
everything getting dumbed down... we can expect more from our users.
I think that appealing to beginners is also a good thing, as they might
grow up and become a valuable part of our community. And if they install 5
DAWs to try out where one has distorted sound from the beggining - it means
our future with that user might cease to exist.

On the other hand - Ardour, the most professional GPL DAW I know offers no
choice here. You either use JACK or no Ardour for you! However it's highly
understandable when you look at what Ardour does, being able to capture 60
tracks of audio simultaneously and doing advanced routing of the signals,
both internally and externally (JACK makes it the same thing).

I personally use KX Studio for years now and it uses JACK by default. No
Pulse Audio. However I find myself in need to use ALSA backend, as LMMS
tends to loose it's connection with JACK every time I open Zyn GUI. I have
to use an ALSA-JACK bridge with increased quality (KX Studio defaults are
cheap on CPU but introduce quantization noise and aliasing), and that costs
me around 10% of CPU time and often introduces bad xruns.

I never figured out what the "device" box does in ALSA backend and what to
put there. A combo box would be great help indeed, but I'd prefer the JACK
backend to be reliable instead.

Also the ability to change audio backend without restarting LMMS would be
great.


Reply to this email directly or view it on GitHub.

@Spekular
Copy link
Contributor

@Spekular Spekular commented Apr 11, 2015

@Umcaruje
Copy link
Member

@Umcaruje Umcaruje commented Apr 11, 2015

I never figured out what the "device" box does in ALSA backend and what to
put there.

The device box is there so you select the desired soundcard to use with alsa.

You can see a list of all your devices by doing aplay -l in the terminal:

screenshot from 2015-04-11 15 13 21

Then you put the name of the desired soundcard inside lmms in the hw:X,X format:
screenshot from 2015-04-11 15 20 15

Hope that helps.

@michaelgregorius
Copy link
Contributor

@michaelgregorius michaelgregorius commented Jun 27, 2015

I have implemented the selection of the ALSA device via a combo box. Please check pull request #2135 to see how it looks. Thanks!

@midi-pascal
Copy link
Contributor

@midi-pascal midi-pascal commented Jun 27, 2015

👍

michaelgregorius added a commit to michaelgregorius/lmms that referenced this issue Jun 27, 2015
Removal of a superfluous include in AudioAlsaSetupWidget.cpp

Removal of the function "bool hasCapabilities(char *device_name)" which
was not used anyway. It implemented a test for ALSA device capabilities
needed by LMMS (SND_PCM_ACCESS_RW_INTERLEAVED, SND_PCM_FORMAT_S16_LE,
etc.).

Corrected header name in AudioAlsaSetupWidget.h.

Created an implementation file for AudioDeviceSetupWidget to make more
clear that it's part of the GUI.

Fix build for builds that use Port Audio. The setup widget of
AudioPortAudio.h still inherited from AudioDevice::setupWidget instead
of the new AudioDeviceSetupWidget.
@Umcaruje Umcaruje added the ux label Jul 4, 2015
@sunnystormy
Copy link

@sunnystormy sunnystormy commented Jul 26, 2015

On my budget ASUS and DELL inspiron, I've needed to switch to SDL in order to get sound to play properly. Prior to doing so, some of the complimentary "cool songs" wouldn't play properly (ALSA with distorted, buggy sound, sometimes inaudible). My ASUS has an Ivy-Bridge Intel Chip, and my DELL a Kaveri AMD. I'm also running Debian Jessie on both machines.

TLDR: +1 for SDL as default.

Wallacoloo added a commit that referenced this issue Aug 26, 2015
Partial fix for #1600: ALSA device can be selected using a combo box
@tresf
Copy link
Member

@tresf tresf commented Aug 27, 2015

Can I get a new poll of the SDL vs. ALSA vs. whatever?

Last we asked, most agreed and a few strongly disagreed that SDL should be default in Linux.

I did some low-performance bench-marking on Ubuntu via #1600 (comment) and found SDL was our lowest common denominator for a new Linux workstation with minimum setup fuss and decent performance in those tests (Sorry, I didn't test other distros).

So I'd like to be able to either make this change or close this issue out entirely. Your vote counts (if you use Linux/Unix). :)

@Wallacoloo
Copy link
Member

@Wallacoloo Wallacoloo commented Aug 27, 2015

@tresf I apologize in advance: I am not going to read this entire thread so my statement may be redundant.

Quote: Diizy

Don't use PulseAudio.

My understanding from the ALSA wikipedia page is that ALSA is a kernel component. Therefore it seems a totally valid assumption that it should work on any desktop Linux system. So I agree with @diizy's first comment. It seems like SDL working on a system with broken ALSA support only serves to mask the underlying issues that the user is really having, and doing that is likely to only cause more pain in the future.

OTOH, and speaking as a developer of this generally frightening codebase, it's not unlikely that the bugs lie in our ALSA implementation. Statistically speaking, if SDL seems to be more reliable than ALSA, then sure, my vote is: default to SDL. It's a trivial thing to change down the road if ALSA support improves, or if we can dynamically detect when a backend is fundamentally broken & fallback to SDL (what is the source of the distortion, anyway? Buffer underruns?)

@michaelgregorius
Copy link
Contributor

@michaelgregorius michaelgregorius commented Aug 27, 2015

OTOH, and speaking as a developer of this generally frightening codebase, it's not unlikely that the bugs lie in our ALSA implementation.

@Wallacoloo I have made some performance analysis with Valgrind. You can find the results in #2295. There is also lots of inefficient code that's called which is not related to ALSA. However even neutralizing these calls still leads to a high CPU load. Is it possible that the busy waiting in AudioAlsa::run is the cause for this? If that's the case: is it possible to use ALSA with callbacks similar to the Jack API?

It also seems that we also feed ALSA signed 16 bit integers instead of directly the float values. The floats are converted in AudioDevice::convertToS16 which is quite inefficient. So one thing to consider is to feed ALSA directly the float data instead of doing the conversion.

ThomasJClark added a commit to ThomasJClark/lmms that referenced this issue Sep 12, 2015
Removal of a superfluous include in AudioAlsaSetupWidget.cpp

Removal of the function "bool hasCapabilities(char *device_name)" which
was not used anyway. It implemented a test for ALSA device capabilities
needed by LMMS (SND_PCM_ACCESS_RW_INTERLEAVED, SND_PCM_FORMAT_S16_LE,
etc.).

Corrected header name in AudioAlsaSetupWidget.h.

Created an implementation file for AudioDeviceSetupWidget to make more
clear that it's part of the GUI.

Fix build for builds that use Port Audio. The setup widget of
AudioPortAudio.h still inherited from AudioDevice::setupWidget instead
of the new AudioDeviceSetupWidget.
@tresf tresf closed this in 1bb276b Sep 18, 2015
@tresf
Copy link
Member

@tresf tresf commented Sep 18, 2015

I've made SDL default for all platform on a fresh install. Since this is a controversial topic, I'd like to end this thread with the quote from @Wallacoloo:

It's a trivial thing to change down the road if ALSA support improves, or if we can dynamically detect when a backend is fundamentally broken & fallback to SDL

@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Sep 18, 2015

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.