ALSA shouldn't be default in LMMS #1600
Comments
|
#1600 whoot whoot! |
|
On 01/11/2015 10:52 PM, Gabe Bauer wrote:
Don't use PulseAudio. |
|
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. |
|
On 01/12/2015 12:01 AM, Gabe Bauer wrote:
ALSA works just fine. PulseAudio is the problem. Setup your ALSA backend |
|
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. |
|
On 01/12/2015 12:55 AM, Tres Finocchiaro wrote:
We can expect a bit more from Linux users than we can from Windows ALSA works just fine for most people. SDL causes more overhead and is an It's simply a fact that if you want to do audio work, PulseAudio is a |
|
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 |
|
... 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. |
|
I completely agree. It preformed well on a Raspberry Pi using SDL. So, we know it doesn't take up THAT many resources. |
|
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
It is evening out though, linux is starting to become so simple, what a shame... |
|
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. |
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.
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 |
|
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 |
|
... 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. |
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.
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 |
|
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. |
|
On 01/12/2015 01:20 AM, Gabe Bauer wrote:
Opinions are like arseholes: everyone has one. It's obvious that this is going nowhere. We've heard your view, |
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. :) |
|
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. |
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? |
I use ALSA, but I always specify my device. If I leave it at 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). |
|
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:
I won't make any guesses at this point whether it's LMMS or PA that's buggy. |
|
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? |
|
Edit... PA says "Bad latency!", so I assume that isn't a good option. |
|
On 01/12/2015 12:14 PM, Raine M. Ekman wrote:
Yeah, what we need is to get the Jack backend working. It's the only And to do that we need to make the engine RT-safe... |
|
On 01/12/2015 03:33 PM, Tres Finocchiaro wrote:
PA is the worst possible choice for audio work. Latencies are horrible, I see absolutely no point in encouraging users to use inferior backends |
That is a good point. @Umcaruje can you confirm this?
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? |
|
On 01/12/2015 04:47 PM, Tres Finocchiaro wrote:
Performance. What we should do (as I already mentioned) is make configuring the ALSA |
|
Agreed |
|
If toby brought SDL up in the mixer code, should we do that across the On Tue, Apr 7, 2015 at 2:49 AM, Gabe Bauer notifications@github.com wrote:
Jonathan Aquilina |
This was already identified and asked above. |
|
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 :( |
|
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. |
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 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.
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... :) |
|
On 12 Jan 2015 15:23, "Vesa V" notifications@github.com wrote:
On the other hand - Ardour, the most professional GPL DAW I know offers no I personally use KX Studio for years now and it uses JACK by default. No I never figured out what the "device" box does in ALSA backend and what to Also the ability to change audio backend without restarting LMMS would be
|
|
I agree with unfa that it should be set up in a way that makes it easiest
for beginners. If you care about what backend you're using, you're probably
also capavle of changing it and setting it up. If you don't, then it's much
better if it just works.
|
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
Then you put the name of the desired soundcard inside lmms in the Hope that helps. |
|
I have implemented the selection of the ALSA device via a combo box. Please check pull request #2135 to see how it looks. Thanks! |
|
👍 |
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.
|
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. |
Partial fix for #1600: ALSA device can be selected using a combo box
|
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). :) |
|
@tresf I apologize in advance: I am not going to read this entire thread so my statement may be redundant. Quote: Diizy
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?) |
@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 It also seems that we also feed ALSA signed 16 bit integers instead of directly the |
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.
|
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:
|
|
👍 |
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.
The text was updated successfully, but these errors were encountered: