Vega Strike Forums

I have sound problems in Ubuntu 9.04 in the most recent svn (12572) as well. Insted of killing pulseaudio, I wrote a script to decrease it's priority (increase its nice) while vegastrike is running. I did not have any problems building the svn from the wiki instructions
EDIT: Replacing with better script

Chuck,
Lots of information here
https://bugs.launchpad.net/ubuntu/+sour ... bug/301755


Some people reported my last suggested change working... others not.

Sorry; I've been on a shader-writing and testing roll, the last couple of days, and I have
a lot of apps open in all my desktops; so I've been procrastinating on rebooting. I did
the changes; just haven't rebooted yet. Maybe tonight.
I also created the nice script that rCX recommended; but it didn't do anything for me;
I see the messages it outputs, changing the nice from 0 to 2 and back to 0; but the
sound is broken anyways. But it's nice having the script, anyhow; I added redirections
for stdout.txt and stderr.txt to it, so I don't have to type them

I figured that was the case, no hurry. I'm busy with the Windows Compile.

Yeah, so, I did reboot, finally, and now there's music about 30% of the time, the rest of the time noise.
That compares to about 2% of the time, before; so, I guess adding that tsched = 0 was an improvement.

It is a timing tweak. The forums had other discussions about it as well. There is some finger pointing at it being an ALSA issue. We can look at that as well.

Cool.
No rush from me; I don't really care for sound, personally; I just fire up the game for shader testing.
What I notice also is, I have a vs.sh script with nothing but ./vegastrike 2>stderr.txt in it; but after
about a dozen shader tests, it begins to act weirdly: I quit the game, but the script doesn't return
the prompt, and I have to Ctrl-Z it. And after another dozen tests, the whole computer starts to
slow down and I have to reboot. Could it be spawning a new sound process each time and never
terminating them? I tried to check with top, but it gives me very little info; I'm sure there's a lot
more processes than it shows; and it changes the ordering so often I can't read, anyways.

ps aux
will show a static and full list of ongoing processes

I'd like to suggest that pulseaudio is just a buggy useless piece of crap for 95% of the users out there. There is no reason for it outside of a niche group of users.

You'll notice no such reports by people who dont use it and have no need of putting an unecessary software layer between your audio driver and your hardware.

safemode wrote:I'd like to suggest that pulseaudio is just a buggy useless piece of crap for 95% of the users out there. There is no reason for it outside of a niche group of users.

Hey, don't bash agasint pulseaudio... it was the first decent audio system I had
Really, nothing worked until pulseaudio, at least in my computer, with crappy onboard sound (ya... I'm using onboard sound - and a crappy one at that).

It only has to be configured properly, and most distros out there don't - or they have an old version of pulseaudio - pulse is really really new, so having an old version of it really kills your experience.

BTW: chuck, Ctrl+Z only stops the process, and leaves it suspended. To kill it, you must then... kill it:

$ ./vegastrike
<blah>
^Z
$ jobs
[1]+ Stopped vegastrike
$ kill %1
$ happiness

pulseaudio only sits on top of your actual audio driver. So i dont see how your audio could not have worked prior to pulseaudio. It behaves as a transparent daemon much like esd only transparently by hijacking your audio device file in /dev and placing it's own file in there that pipes data to it's userspace daemon and then back to the real audio driver (whichever you happen to use, (likely alsa ...but it also supports oss3 for the weirdos)).

safemode wrote:pulseaudio only sits on top of your actual audio driver.

With onboard audio, the audio driver is really really dumb. Pulseaudio makes a very good job at implementing all the missing features - or going around the bugs.

Prior to pulseaudio, if there were more than one user logged in everything was chaotic. Furthermore, if there was more than one process using more than one audio API it was very chaotic, and linux is like that: every app uses the API it wants, no unified anything.

Pulseaudio hijacks the other APIs, so it can unify.

LOL
Thanks for the tips.
BTW, I have on-board sound, for the record. (And no $ to change that, atm.)

I think about 97% of people have onboard sound. The vast majority dont need anything above alsa to have multi-stream perfectly usable audio. What pulseaudio provides is niche features most people dont need nor would they miss if it didn't exist. Most apps you want to hear sound from have their own software volume mixer (it's insanely easy code to splice in to your normal hardware volume controls )and those that dont you probably run without sound anyway. The rare instance i can think of where this isn't the case is web-browser av content. But i dont doubt that eventually pulseaudio wont suck hard and it can replace the plethora of what i consider completely useless sound daemons that sprung from the OSSv3 generation 10 years ago.

btw, who buys sound cards anymore? I haven't bought a sound card since the sound blaster Awe 64 was around and i think that was an ISA card.

safemode wrote:I think about 97% of people have onboard sound. The vast majority dont need anything above alsa to have multi-stream perfectly usable audio.

Alsa handles software mixing with dmix, but it's insanely buggy and picky.

I don't know if it's that both matured over time, but when I updated my distro (and incidently switched from pure-alsa to pulseaudio over alsa), sound just magically worked, and I was "wow... <tears> everything's gonna be fine..."

safemode wrote:btw, who buys sound cards anymore? I haven't bought a sound card since the sound blaster Awe 64 was around and i think that was an ISA card.

Onboard sound is crappy - enough for most applications, but crappy.

I still buy discrete audio cards for my (very old by now) recording rig. In fact I'm trying to get someone to import a decent multitrack but nobody will import the one I like

I've never had to use dmix as pretty much any card built within the last half decade should support hardware playback of simultaneous audio streams.

Even my no-name ac97 run nvidia on-board audio whatever chipset does it just as well as sb live 8 years ago did.

i've had various mobo's since my days with the awe64 and live and that was pretty much the last discrete audio card i ever got. I'm not saying they aren't useful for those in the music industry, but that's a tiny niche compared to the masses. And i've never had a problem with multiple apps playing with audio at the same time.

Though, i also choose hardware suited for linux rather than just at random. I'm not gonna build a system that half the hardware has zero or crap support in linux. But when it comes to onboard audio and such, i can't imagine what kind of chipset doesn't support hardware audio multiplexing so you can have multiple apps output audio at the same time. I've _NEVER_ come across one as I've never needed dmix. Since this kind of feature has been around since the sb64 days, you've gotta be using some minority board to be lucky enough to have such a chipset. I stick to asus and abit mobos. And i stay away from Via chipsets.

safemode wrote:I've never had to use dmix as pretty much any card built within the last half decade should support hardware playback of simultaneous audio streams.

Even my no-name ac97 run nvidia on-board audio whatever chipset does it just as well as sb live 8 years ago did.

You're completely wrong man... many MANY onboard chipsets can only handle one stream, it's the driver the one doing all the mix.

Sometimes (I'm guessing nVidia) the AC97 DC (the digital controller part of the chipset) performs the mixing, but it's certainly not commonplace.

Or maybe you've been blessed with up to date (or modern) distros with properly configured software mixing and whatnot. But it's a necessity of most onboard audio.

safemode wrote:i've had various mobo's since my days with the awe64 and live and that was pretty much the last discrete audio card i ever got. I'm not saying they aren't useful for those in the music industry, but that's a tiny niche compared to the masses. And i've never had a problem with multiple apps playing with audio at the same time.

I bet many others buy discrete audio... I can actually hear (and pretty clearly) the dithering, ripple and god knows how many other signal deficiencies of most onboard audio.

safemode wrote:Though, i also choose hardware suited for linux rather than just at random. I'm not gonna build a system that half the hardware has zero or crap support in linux.

I sometimes fail at that

safemode wrote:But when it comes to onboard audio and such, i can't imagine what kind of chipset doesn't support hardware audio multiplexing so you can have multiple apps output audio at the same time.

Intel HDA, for one.

safemode wrote:I've _NEVER_ come across one as I've never needed dmix. Since this kind of feature has been around since the sb64 days, you've gotta be using some minority board to be lucky enough to have such a chipset. I stick to asus and abit mobos. And i stay away from Via chipsets.

Asus ships a lot of Intel HDA chips...

Thought I'd mention, in case it matters, using now System Monitor I find multiple vegastrike
processes sleeping there, taking up hundreds of megs each. Have to kill them manually.
Obviously when I ESC-Q from VS the screen goes away but the app doesn't terminate; I've
no idea why. Sometimes it does terminate, and System Monitor finds nothing; but most of
the time instances seem to accumulate as I test shaders.

well, isn't audio threaded? so it's possible that something is borking in one of the threads (maybe leading to these problems you are having with the audio or being caused by them) and VS exits GL but has to wait for threads to join in the audio subsystem prior to closing...likely due to us being nice and waiting for the threads to clean up nicely rather than just murdering them.

Does anyone know how to turn OFF pulseaudio on Ubuntu 9.10 temporarily? I can kill the process, but something starts it back up

Found out.

To kill pulse audio, what you have to do (but DON'T do it) is to create a file in the ~/.pulse
folder, name it "client.conf" and inside write "autostart=no".
Then sudo kill -KILL <pulseaudio ID>.
And it's dead.

Problem is, you're dead too.
X locks up.

The real solution is to sudo aptitude remove pulseaudio,
then sudo aptitude install gnome-alsamixer.
No more audio problems with vegastrike

apparently the pulse audio people aren't happy with ubuntu really. They rushed it in and did so prematurely. Consequently, lots of problems have occurred relating to it and it's damaging to pulseaudio's reputation. If you dont have a pos sound chipset, do yourself a favor and remove it like chuck did. prayers go out to those who find themselves with said pos sound chipsets.

If pulseaudio is that screwed up on your system... Try removing it (look-up the proper method first). I did that a few Fedora versions ago. I believe it just meant one application could play sounds system at a time... That might be been OSS

Yes; that's what I did. Pulseaudio is finito, erradicated, destroyed, gone for good. So what if only one application can use sound? Most of the time I don't have 1/64th of an application applying for sound output. With my next rig I'll be sure to get the best sound card money can buy; but right now I'm broke flatter than a piece of plate in Flatland.

I bought the best sound card money can buy once. I regretted it. It was designed to record a band (a group of musicians playing various instruments to produce a song) input at 24bit 192khz, then mix it in real-time. Although it was really neat.. I'm not a musician and it was difficult for gaming. I was hoping to record an analog signal with it. I ended up taking it back and using a middle of the road card.