I see that the votes stand at 1:1 right now. Anyhow, I didn't even think about uninstalling the relevant rpm (if I can find which one it is) just to see my whole computer getting uninstalled.

Upgrading is not my cup of tea either. As for the things I want to do, I'll take that question as a car mechanic asking me where I want to drive to. The answer is everywhere reasonable for that kind of car.


In my case, I want any possible application involving sound to work. In the past, I've even written small command line applications that opened /dev/dsp directly. I wonder if that's possible today without a B.Sc. from Red Hat University.


The bottom line is that everything works if I kill pulseaudio before starting a given application. And hey, that's slightly better than fixing things by rebooting the computer, which I suppose is soon to be the best advice Linux people will get for solving their problems. Does that remind some other OS?


And the solutions offered are to do things without understanding why they work, if they work. Does that remind some other OS?


Since it seems like I won't understand how pulseaudio works, and it happens to work so-so, I think the best thing is to kill it without that little Frankenstein waking up again. Even just to see what happens. Isn't that the good old way to check things?


The irony is that I have no idea how to do it. And if applications really depend on it in the practical sense.


(I googled "get rid pulseaudio fedora" as suggested. That was a good lead. Maybe I'll find something interesting there)


  Eli


Maxim Kovgan wrote:

hi.

On Wed, Jan 5, 2011 at 1:40 AM, Eli Billauer <[email protected] <mailto:[email protected]>> wrote:

    Hello all,


    I've been doing some sound editing lately on my FC12, just to
    discover that there is a new annoyance in town, namely Pulseaudio.


    http://en.wikipedia.org/wiki/PulseAudio

     I discovered it when Audacity failed to play back files or made
    choppy noises. Other applications also seem to get messed up with
    this piece of I-don't-know-what.


    My first instinct is to kick it out of my system, but since Fedora
    is a system for experts (are they going to open a Red Hat
    University soon?) I don't really know how to do that and what
    consequences I may face. I mean, it's not so easy to just shut
    down. Killing the server makes it restart (as a matter of fact,
    killall -9 pulseaudio has become my catch-all solution for audio
    problems lately). And I haven't even figured out how to disable
    this restart mechanism.


don't kick it. many packages depend on it.
gnome, kde...


    And unfortunately, with all those fancy graphs and fluffy talk
    about generalized everything, I haven't gotten to grasp how the
    machinery ticks. Are there any special files? Domain sockets? What?

forget it :)

please explain what do you do with audio,
maybe it makes sense to make sure you have the right version of audacity (or additional packages for its pulseaudio support installed)


    Does anyone have insights about this? Is there any reason why this
    audio server could be really useful, except for all the fine words
    said about it? Weren't things OK as they were in the good old
    times, when audio was just /dev/dsp?

there were many problems back then. it was old oss interface with no parallel device access, and many other problems. you may try using oss v4, but I doubt fedore included a pulse audio package with support to oss v.4

    But most important of all: Should I give this thing a mighty kick
    in the bottom? And if so, how?


don't do that. see the 1st remark.

please specify your work tasks.




    Thanks,

     Eli

-- Web: http://www.billauer.co.il

    _______________________________________________
    Haifux mailing list
    [email protected] <mailto:[email protected]>
    http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux




--
Maxim Kovgan


--
Web: http://www.billauer.co.il

_______________________________________________
Haifux mailing list
[email protected]
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux

Reply via email to