LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-20-2017, 09:56 AM   #46
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 3,750

Rep: Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845Reputation: 1845

Quote:
Originally Posted by cynwulf View Post
Sorry to interject, but this is not a "professional environment". It's a Linux community forum, populated overwhelmingly by volunteers.

That's a very different scenario, users are not customers/consumers and those providing any help/responding to posts are not employees with customer services training.
I know it isn't professional like a formal store front, however, we are the defacto support forum for Slackware. When users need help, they turn here. What they see here is a reflection on Slackware, whether or not it is intended to be, or whether or not we are the official or unofficial support forum (Slackware.com doesn't list it as official, however, slackbook does... I'm not sure which is the case). Calling anything a POS should be avoided...

Quote:
Originally Posted by cynwulf View Post
No offense intended, but you may be nitpicking here - and referring to a piece of software as a "POS" is not name calling by anyone's definition - as that would usually mean targeting a person(s).

Most users/potential users are mature and level headed enough to be able to judge software on it's merits, usefulness and how well it fulfills their needs, not from some off the cuff comments and opinions being expressed on a forum.
If it were one or two posts, that is easily disregarded, however, this, for a lack of a better word, name calling been used since pulseaudio made an appearance. When people run into problems with pulseaudio, searches could lead them to these threads and they could get a bad taste of the type of support we try and provide in this forum. Since pulseaudio integration is likely to just get deeper in Slackware, and people will no doubt want to remove it, we don't need to consistently call it a POS. We should be able to just calmly discuss what needs to be done to remove it. We can easily discuss the removal of KDE or XFCE without all the names, why can't we do it with pulseaudio as well?

I don't have any problems with people desiring to remove pulseaudio from their system. Slackware is quite versatile in allowing users to customize their systems. And as I said earlier, if no one else wants to, I'd be willing to host a slackpkg+ capable repo of the rebuilt packages needed to remove pulseaudio... I just won't do the work on rebuilding the packages myself since I wouldn't use them and it wouldn't be easy to test them.
 
1 members found this post helpful.
Old 03-20-2017, 10:54 AM   #47
selfprogrammed
Member
 
Registered: Jan 2010
Location: Minnesota, USA
Distribution: Slackware 13.37
Posts: 306

Original Poster
Rep: Reputation: 63
Angry

I have no interest at all in how some other users may have such a limited usage of sound that PulseAudio is perfectly fine for them. Those people should go away right now.

Now it is the first paragraph. Dumping an irrelevant how it "works for me" is of no help to those who are having trouble with PulseAudio. If it is not the same hardware as I have, it is not relevant. As for all the other garbage going on in MY thread, go take it to another thread.

Someone is clicking on "Did you find this post helpful" for political reasons. I see it on little one liners that offer nothing except opinion. Apparently the reps are tainted by political supporters.

I am going to continue with what I have discovered. I want any further comments to be about configuration. If you feel the need to defend PulseAudio, please sit on your lips, fingers, or whatever.

I cannot think well of the PulseAudio development. Outright declaration that it is hostile takeover of the Linux sound system, with little consideration of how it breaks existing programs and working environments. That hostile attitude basically invited lots of angry users, so if you hear of any angry users on this thread, shut up about it. I am looking for ways to restore what worked before and make PulseAudio (where needed) get along in a secondary role. That is not an invitation to argue anything. If you want to comment on this or argue PulseAudio, start your own thread.

** SDL MIDI music
I have SDL MIDI music working again. Upon booting the next day, SDL could play MIDI music.
The SDL library IS still supporting MIDI. I tested it a second day too, just to make sure it was reliable, and it still works. There is probably a gotcha out there that blocks it, and I have yet to discover what it is.

** pavucontrol
This PulseAudio volume control is part of the problem. It leads you to believe that it is the volume control for the sound system, and it is not. It is only the PulseAudio mixer volume control (controls).

** ALSA mixer loading is disabled in the installation Slackware 14.2
You need to make executable the file /etc/rc.d/rc.alsa, so that the saved mixer settings will be restored upon boot. Otherwise the ALSA master volume control is initialized at about 30%.

** ALSA needs a default setting of the ALSA mixer controls.
To save the mixer settings.
> alsactl store

You can do this manually once, after setting up the controls using alsamixer.
You can have the mixer controls saved automatically on shutdown by putting it in
/etc/rc.d/rec.local_shutdown (or similar depending upon distribution). Previous versions used to have it there, enabled by an if detection of alsa.

** PulseAudio problems
The PulseAudio sound goes through both the ALSA pcm volume control and the ALSA master volume control. At least it does with my current setup, and I do not know what it does in other setups.
If either of these is set low (which they are by default), then PulseAudio volume control must set higher, which leads to that mixer clipping peaks. That is one thing that is making PulseAudio sound so bad.

PulseAudio goes through the ALSA master volume control, so any program that sets volume by changing the ALSA master volume control (like music players) is going to change the PulseAudio volume too, and without it showing on pavucontrol.

If PulseAudio was written to cooperate with the existing ALSA sound system, it would have brought the sound into ALSA somewhere independent of the other ALSA users. When PulseAudio outputs to ALSA, it ought to have its own volume control in the ALSA mixer. The same is likely true of JACK, esound, and other mixers.

If PulseAudio always goes through the ALSA mixer devices, even when it intercepts ALSA directed outputs from other programs, then it is always going to need the ALSA mixer controls set to 100%. I have seen at least one other help that mentioned setting ALSA mixer to 100%, so it is apparently necessary. This is then a failing of the Slackware 14.2 installation when it disabled setting the ALSA mixer controls.

Still need to figure out how to write my program to evade that forced redirection to PulseAudio in the asound.conf file.

I have posted everything I currently know about PulseAudio detection of AC97.

The output of "lspci -v" contains this:

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: Chaintech Computer Co. Ltd VT8233/A/8235/8237 AC97 Audio Controller
Flags: medium devsel, IRQ 22
I/O ports at eb00 [size=256]
Capabilities: [c0] Power Management version 2
Kernel driver in use: snd_via82xx
Kernel modules: snd_via82xx

The output of " /proc/asound/cards" contains this:
0 [V8237 ]: VIA8237 - VIA 8237
VIA 8237 with VIA1617A at 0xeb00, irq 22
1 [UART ]: MPU-401 UART - MPU-401 UART
MPU-401 UART at 0x330, irq 10

dmesg did not have any lines that I could find.
If PulseAudio is limited to what udev detects, then it is not universal, and some users are going to need alternatives. Another case of we can automagically detect all your hardware, that does not detect all the hardware. Program long enough, and you learn that whenever "ALL HARDWARE" appears as a claim, a failure is soon to follow. The ability to select and configure alternatives (without spending 3 weeks researching) is necessary.

Last edited by selfprogrammed; 03-20-2017 at 11:35 AM.
 
7 members found this post helpful.
Old 03-20-2017, 03:12 PM   #48
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 967
Blog Entries: 4

Rep: Reputation: 1239Reputation: 1239Reputation: 1239Reputation: 1239Reputation: 1239Reputation: 1239Reputation: 1239Reputation: 1239Reputation: 1239
Quote:
Originally Posted by selfprogrammed View Post
I have no interest at all in how some other users may have such a limited usage of sound that PulseAudio is perfectly fine for them. Those people should go away right now.
Goodbye! Have a nice life!
 
4 members found this post helpful.
Old 03-22-2017, 07:24 AM   #49
FTIO
Member
 
Registered: Mar 2015
Location: Las Vegas, NV
Distribution: Slackware 14.2_64
Posts: 223

Rep: Reputation: 97
Quote:
Originally Posted by 55020 View Post
Goodbye! Have a nice life!
So you get butt-hurt because the OP has asked that those who don't want to post on-topic and would rather blather on about anything but the topic?

To the OP...go back to 14.1. It's the last Slackware to work properly with sound (ALSA). 14.2 and this pulse-audio abortion that escaped from the garbage can it was thrown in is seriously a bummer, thus I'm glad I kept my old 14.1 on a second hdd. I tried several times in other threads about this pulse thing to get alsa working again, but in the end there were always things screwing up elsewhere eventually and I'd end up re-installing 14.2. I hate to say it, but I fear there won't be a 14.3 (or whatever) on my system if it's got this pulse thing still. Best of luck to you in your endeavors though with this thing. I wish I was schooled in programming and such things to be able to get into the depth you have and try to help out somehow. Good to see you're not a quitter though.
 
1 members found this post helpful.
Old 03-22-2017, 10:21 AM   #50
the3dfxdude
Member
 
Registered: May 2007
Posts: 501

Rep: Reputation: 182Reputation: 182
Quote:
Originally Posted by Richard Cranium View Post
Hell, I get freaking paid professional developers whose initial bug reports are pretty much "I tried to do X and it didn't work." No logs, no detailed description of what they were doing, and no indication of the versions of the code with which they are trying to "do X". Remember, these are people who manage to debug the stuff that they write.

So, yeah, I think in a public forum such as this, where the people asking for help might not have debugged a software problem in their entire life, that @ppr:kut so rarely gets enough detail about the problem without having to pull teeth that he might comment such as he did.

You, OTOH, appear to be letting your dislike of pulseaudio spill into your perception of others and their intentions.
So since your post illustrates the thing I mentioned in other threads, which is why I asked the question here, I'll explain to you. There seems to be a cycle of conflict (I'll refer now as the poettering trap), where people seem to label each other and focus on the labeling. In this case it is whether you are a pulseaudio hater or lover. Today, since pulseaudio is available as part of the distro, there has been growing attacks on people not using it, calling them out as "haters" or "dislikers" as you've done, with flimsy reasoning. I think this is a troubling trend, since many people here are using slackware for its flexibility, and are now getting castigated about for their setup choice. Just so you understand, I'll use whatever solution is the best solution for my application. This is not about hating.

Therefore, the matter is not about classifying professional, the words they chose, or bug report filing. It's about whether we can get to problem solving without labeling each other then focusing on that instead. So I asked for clarity; is it really that everyone else does not research their pulseaudio problem, or have other been solutions presented before now? Exaggeration, or...?

I'd hope that peoples suggestions stop being castigated.

Last edited by the3dfxdude; 03-22-2017 at 10:24 AM.
 
2 members found this post helpful.
Old 03-22-2017, 11:06 AM   #51
the3dfxdude
Member
 
Registered: May 2007
Posts: 501

Rep: Reputation: 182Reputation: 182
Quote:
Originally Posted by ppr:kut View Post
No sarcasm, but just to be more clear, I was talking about pulseaudio problems specifically not general problems. From my memory this was truely the first instance where a user with frustrating pulseaudio problems presented actionable intel on what's going on/wrong. It's perfectly possible that there were others that I didn't read or didn't remember reading. If so, mea culpa.
Hi, just found this message in the thread. Thanks for the response! I understand your view better.
 
Old 03-22-2017, 03:01 PM   #52
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware64, Crux64, NetBSD64
Posts: 1,135

Rep: Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670
Quote:
Originally Posted by the3dfxdude View Post
So since your post illustrates the thing I mentioned in other threads, which is why I asked the question here, I'll explain to you. There seems to be a cycle of conflict (I'll refer now as the poettering trap), where people seem to label each other and focus on the labeling. In this case it is whether you are a pulseaudio hater or lover. Today, since pulseaudio is available as part of the distro, there has been growing attacks on people not using it, calling them out as "haters" or "dislikers" as you've done, with flimsy reasoning. I think this is a troubling trend, since many people here are using slackware for its flexibility, and are now getting castigated about for their setup choice. Just so you understand, I'll use whatever solution is the best solution for my application. This is not about hating.

Therefore, the matter is not about classifying professional, the words they chose, or bug report filing. It's about whether we can get to problem solving without labeling each other then focusing on that instead. So I asked for clarity; is it really that everyone else does not research their pulseaudio problem, or have other been solutions presented before now? Exaggeration, or...?

I'd hope that peoples suggestions stop being castigated.
Some days it feels as though this has become a Red Hat forum, with the way certain members want to impose "official" solutions on others. You can't even ask how to do a minimal install of Slackware these days without these people discouraging you and applying the party whip.
 
1 members found this post helpful.
Old 03-31-2017, 09:16 AM   #53
ninikos
LQ Newbie
 
Registered: Dec 2012
Posts: 22

Rep: Reputation: Disabled
Hi to all and sorry for the length of this post.

First of all, two simple facts from signal theory
  1. resampling and mixing always add distortion noise (any dsp type processing does)
  2. resampling and mixing in real time always add some latency
    latency_in_samples = sum(mix_buffers_size) + sum(resampling_buffers_size)
    (at least as big as the sum of the mixing buffers plus the resampling buffers)

My personal experience which comes from working for some months on a vst plugin using slackware64-14.0 and slackware64-14.1. Pulseaudio on linux for me added then
  1. clicks, pops, cracks that were noticed especially when recording audio that is synthesized real time by various instrument plugins (vst, ladspa, samplers, daw applications). Actually for this I found only jack 1 to be almost perfect, even jack 2 had some drops now and then
  2. some distortion (high frequencies clipping and a bit time stretch) these were noticable on not so expensive monitor headphones
Rationale (Unavoided comment, part 1 of the rants)
Please let others not want pulse they should have the right to do so and developers with the poettering cabal mentality should not be allowed to make such technical decisions on critical and basic system layers. To me, all this crap is plain bad software engineering practices.

To summarize, in my ears audio and linux
  • (a) Linux already had an excellent audio driver system (OSS) in the past, but ... politics ...
  • (b) Linux already has another excellent and universally working audio driver layer (ALSA)
  • (c) Linux already has an excellent audio server (JACK)

But ... the plumber (lol) cabal now has forced on almost every linux user another audio server by not allowing them directly or indirectly and making them run through hoops to be able to use another already working technical choice different from their own true one. This audio server pretends to be a device manager and an audio server and an API and whatever kitchen sink comes with it next. It also tries hard to hide things like the real hardware mixer that is available in the hardware in the first place, because it does not fit in their software abstraction layer about how things should be done, again they impose a proper true way.
These practices are seen in another system component designed by the same person , the not-to-be-named-here pid 1. Now the same cabal mentality wants an IPC bus server in the kernel to be able to be "fast" and "relevant" and "modern" instead of implementing an alsa/jack configuration layer and a sysv compatible process supervision layer like a normal human being. All this is really beyond any logic ...

... but politics and egos ...

so please let others have the right and the option to not want shitty audio servers running on their machines all the time

So, using slackware 14.2 ...

Code:
1. Setup asound.conf if needed
rm asound.conf or use a custom one, as usual before pulse ...
For example here, where the first card reported by the bios is the hmdi one
Get your sound card list with 
$ cat /sys/class/sound/*/id
HDMI
Generic

A simple asound.conf for this would be
-- /etc/asound.conf
defaults.pcm.!card Generic
defaults.ctl.!card Generic
--

2. Edit deamon.conf
-- /etc/pulse/daemon.conf
exit-idle-time = 0
flat-volumes = no
--

3. Replace default.pa with something like this,
I would like to achievie this with minimal editing of the original 
default.pa that comes with slackware, and probably will try it at
some point, but ... so much time
-- /etc/pulse/default.pa
#!/usr/bin/pulseaudio -nF
.fail
    # Set tsched=0 here if you experience glitchy playback. This will
    # revert back to interrupt-based scheduling and should fix it.
    #
    # Replace the device= part if you want pulse to use a specific device
    # such as "dmix" and "dsnoop" so it doesn't lock an hw: device.
    
    # INPUT/RECORD
    load-module module-alsa-source device="default"
    
    # OUTPUT/PLAYBACK
    load-module module-alsa-sink device="default"
    
    # Accept clients -- very important
    load-module module-native-protocol-unix

.nofail
.ifexists module-x11-publish.so
    # Publish to X11 so the clients know how to connect to Pulse. Will
    # clear itself on unload.
    load-module module-x11-publish
.endif
--

4. Enable alsa back
chmod +x /etc/rc.d/rc.alsa
chmod +x /etc/rc.d/rc.alsa-oss

5. Make kmix behave like an alsa mixer
edit ~/.kde/env/kmix_disable_pulse.sh and add the following
KMIX_PULSEAUDIO_DISABLE=1

6. (optional) last step, disable pulseadio if you want.
edit /etc/pulse/client.conf and set 
autospawn = no
Pulseaudio can still be started manually from a console with this method
Otherwise it will spawn when the first program triggers it.

Reboot ... and test with 
aplay -l
aplay -L
alsamixer
pavucontrol sould also work
Some sanity in the audio is back! Gone are audio glitches, pops, clicks and time stretches in the audio streams. Thank you all in this forum as well the slackware team and mr Volkerding for implementing a relative sane default pulse configuration in the first place, even though I would prefer using something like the above. It's less intrusive and can support the use cases of simply putting samples in the card buffer and listening them exactly as they are, as well as applications that the user wants to run them with low audio latencies like audio and video production software and video games.

xmms works as it should, I can listen my mp3's again . For example a file I ripped 15 years ago and converted to mp3 with VBR at 160-256 Kbps sounds once again as it should. Hear another version of the song, encoded by someone else https://www.youtube.com/watch?v=XIrXHUrlvhc. You can listen to it while enjoying the rest of the post.

With the above configuration firefox will still use pulse. KDE also uses pulse. Controlling pulse can then be done (simply?!!) by changing the autospawn value in /etc/pulse/client.conf. With autospawn = yes, any application that wants pulse will trigger it and work properly. With autospawn = no, the user has to start it manually if he wants to. For firefox, if the pulse configuration is ok, firefox will use pulse, otherwise it will fall back to use alsa (firefox ESR on slackware64-14.2).

For example, to compare how firefox sounds with and without pulse, change autospawn = no in /etc/pulse/client.conf. Then, inside KDE multimedia settings you should have the usual regular alsa devices. If you start firefox it uses alsa. Listen to something. Close firefox and start pulseaudio from a console. Start firefox, use pavucontrol to verify sound goes through pulse. Listen and compare. When you close firefox, pulse closes. Or, better, use seamonkey with pulse closed, it will use alsa. Start pulseaudio, then firefox, so you can start the same audio from seamonkey (alsa) at the same time with firefox (pulse). Or, even better start xmms or any alsa player, pause, then start pulseaudio, then start amarok or any pulse aware player. Load the same high quality file in both and compare.

Even with this relatively garbage closed typed headphones I use for testing this I can hear subtle differences with and without pulse even when playing the above link. The basslines and the low freqency drums sound to me a bit mushed up together like they are passed through a compressor and a bit more loud when played back with pulseaudio. The high frequencies have lost some clarity and power when passed through pulseaudio. This can be also observed with sounds like the distinct recorded pickup head noise and hi hats. In some cases I notice high frequency sound details only on alsa. These differences are almost unnoticable in a usual youtube music video, but they are more noticable when the playback source is compressed with higher bitrates. When playing my own mp3 in xmms (alsa) and amarok (pulse), I can more clearly notice them. I suppose with higher quality speakers these will be even more noticable.

Another major thing for me is latency. I like to play video games sometimes and some of them are fast action real time first person shooters and platformers. When playing these type of games I have a more enjoyable experience when the sounds of the game are played back with less latency and glitches. I found that in some games like Borderlands 2, pulse has a very noticable impact, the sound is lagging to the mouse button inputs. Emulators and other games also have the same lagging feeling to them.

Finally, by introducing distortions to the audio output the audio stereo image of sound effects such as positional audio changes and the result is that these effects are not percieved any more, or more summarized: sometimes positional stereo effects just don't work in games when using pulseaudio.

-- (part 2 of the rants)
Also, by personal experience working as a developer, using pulse for high fidelity and/or low latency audio applications is a problem by itself. You don't know if it's the developer's code that glitches, stretches or whatever the code is doing or if it's the pulseaudio that does these. And, no, debugging all these is not fun. In the end, the use case I am talking about is the ability to create audio creation applications and audio content. This also extents to video, gaming, and many other real time applications as well as the content creation aspect of these domains.

Running pulse on a maemo phone for speech applications through crappy bluethooth speakers and headphones is the real problem that pulse solved initially and it's good enough for this use case, but desktops in my mind have had proper technical solutions to the audio stack problem for maybe 20 years now. I can remember DOS midi trackers running with high quality undistorted sound and low latencies without any problems while driving and synchonizing real music instruments via midi just fine. All soundcards still have useful hardware controls that I would like to use.

For my desktop and laptop use cases pulse does not cut it and I don't think it will ever will, but now, I have to deal with it again ...

I can understand that these are subjective observations, but I think low latency and direct undistorted audio reproduction are valid use cases for many users and applications. At least they are for me and the applications I use or develop. Dilemmas like this one; choose between a working bluetooth or a working low latency audio system, are the results of bad attitude combined with bad engineering practices. Pulseaudio should have been engineered in a more compatible and less intrusive way to the rest of the existing system, which is ... surprise, surprise .. ALSA . These are the main problems also with the-not-to-be-named-here pid 1 for me. Moreover, jack should be included in the technical answer for the audio server problem. It is stable and proven because it is designed and implemented by people that care and understand audio problems on the desktop in the first place.

Last edited by ninikos; 03-31-2017 at 07:39 PM. Reason: typos
 
14 members found this post helpful.
Old 04-02-2017, 05:09 PM   #54
askfor
LQ Newbie
 
Registered: Aug 2016
Posts: 22

Rep: Reputation: Disabled
This is a long thread, and I might be missing something. However, you can disable Pulseaudio and use ALSA without removing Pulseaudio package and libraries. If that solves your problem, you can read about it at here:

https://docs.slackware.com/howtos:mu...io_non-default

and

http://kodi.wiki/view/PulseAudio/HOW...%29_for_Ubuntu

Log story short:

1. make rc.pulseaudio non-executable
2. make rc.alsa executable
3. comment all the lines in /etc/asound.conf
4. reboot

Once you've got ALSA running properly, keep in mind that alsamixer settings are not stored by default. If you want alsamixer settings as default after boot, run: alsactl store
 
Old 04-02-2017, 08:49 PM   #55
selfprogrammed
Member
 
Registered: Jan 2010
Location: Minnesota, USA
Distribution: Slackware 13.37
Posts: 306

Original Poster
Rep: Reputation: 63
It has not proved to be simple, and you read too fast. Those are the same things that the this thread has found.

I feel the simple "do this" list approach is not adequate. Some people have different needs, or different hardware. It is as important to detail what each change does and what it fixes so that other users can apply it to their different situations intelligently.

In addition, it was found that PulseAudio was not detecting my AC97 sound device.
This reveals how it highly dependent upon udev device detection.

The major problems with PulseAudio detailed in this thread is how it blocks pre-existing working solutions, and claiming a takeover of the Linux sound.
Exactly how and why is also important to record, as there will be others who have to deal with these problems. As installed in Slackware it does not coexist well, but it can be reconfigured to coexist much better.
 
1 members found this post helpful.
Old 04-02-2017, 10:56 PM   #56
Paulo2
Member
 
Registered: Aug 2012
Distribution: Slackware64-stable (started with 13.37(32))
Posts: 293

Rep: Reputation: 73
I did this to get rid of pulseaudio
http://www.linuxquestions.org/questi...ml#post5584164
hope this helps.
 
1 members found this post helpful.
Old 04-03-2017, 08:16 AM   #57
askfor
LQ Newbie
 
Registered: Aug 2016
Posts: 22

Rep: Reputation: Disabled
I have read somewhere about settings in /etc/pulse/client.conf which might help someone out here. Here they are.

autospawn = no
allow-autospawn-for-root = no
; daemon-binary = /usr/bin/pulseaudio
daemon-binary = //bin/false

I have limited experience with these issues because I am running simple IceWM window manager. Sound related applications which I use most often are smplayer, seamonkey, firefox ESR, chromium and ogg123. All of them work with ALSA. I've heard that firefox is about to dump ALSA support completely in future releases, with all ALSA related code removed, so no compile time switch would help. I am probably going to dump firefox at that point.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Bypass pulseaudio problems and crashes when you don't have pulseaudio. Rinndalir Linux - Software 1 08-31-2016 01:00 PM


All times are GMT -5. The time now is 03:01 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration