Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by curaga View Post
    Wait, you judge a sound system based on its GUI mixer?
    I'm a distro maintainer. I have to make sure things are pretty and easy for end-users. I think the Xfce Mixer can be patched to support OSSv4 though.

    Comment


    • #47
      Originally posted by Svartalf View Post
      The other thing you need to concern yourself with would be to get a BeagleBoard and try to make OSS work right for it. Most of the ARM Linux systems are using ALSA and this move should probably also account for them if you're going to work on making it start to happen.
      I'll look into as soon as I get some funding. I'm working on a media center ATM though.

      Comment


      • #48
        Well OEM media center.

        Comment


        • #49
          Originally posted by pingufunkybeat View Post
          Ever since ALSA got a software mixer (dmix) for cards who can't do hardware mixing, I haven't felt a need for a new audio anything.

          I don't see the point behind PulseAudio. I don't see a need for it. Something is fine if it stays out of my way and does what I expect it to. I expect my soundcard to play sounds, mix them, and allow basic volume control. ALSA works.

          To me, PulseAudio is a solution looking for a problem, and creating far more problems along the way. It is surely an interesting piece of engineering, but not a piece of engineering anyone needs as default on their desktop distro. I don't need it, and I don't want headaches, so it's not coming anywhere near my machine. It's aRts and ESD done correctly, at a time when nobody needs aRts and ESD.

          Linux has a decent sound system - ALSA. Linux also has several choices for media decoding - ffmpeg, xinelib and GStreamer. Pick one for your app and go. Even better, use a higher-level interface which will abstract from it, like Phonon or SDL.
          No offence, I have a feel I talk to the wall here.
          I was unable to get DMIX do job done for the reasons mentioned in my post of what ALSA lacks.
          First it does not support true software mixing - it cannot mix streams of different bitrate and frequency, so if one is playing 44kHz and other starts 22kHz only second is played.

          Second DMIX does not prevent any application take over the sound card. This means for example Adobe Flash or Avidemux taking over soundcard, stopping any other music playback instantly. Any new application will exit with error unable to access device or device busy until the hijacker is closed. This never happens in PA.

          This and many more is done by Pulse. But ALSA doing it properly will eliminate need for extra 20Mb of RAM(so much takes PulseAudio, almost nothing). Never the less Pulse is sanely implemented, it can take over and give features. If you dont want it, you can remove it.

          If you dont see the point of Pulse, why dont you visit at least its Wikipedia entry?

          ALSA is not replacing Pulse
          Pulse is not replacing ALSA

          Pulse implements wide array of features, absent in ALSA, such as live audio stream rerouting. This is similar to JACK, however is desktop (and not workstation) optimized. I consider it pretty cool to have individual per-app volume controlls as well as individual recording controls(where you can separate Mic from sound card and Mic from Webcam and adjust the volume live and per app).
          Pulse is not related to Ubuntu.

          --Let me introduce you to the basics of Linux multimedia--

          ---CODECs
          liblame, libh264, libwhatever is a codec - it encodes or decodes the encrypted binary stream. Application can talk to the codec library directly. If stream is not encoded(RAW) it can be send directly to sound card driver.

          Ffmpeg is just a large codec collection(instead of individual libraries). It is all-in-one library, like Mplayer, featuring many MPEGx codec routines.

          Xine is similar to Ffmpeg and Mplayer in terms it is one big all-in-one codec, but it only supports decoding(which is lame) and it also allows linking to external additinal libraries(so its not one massive rock like Mplayer)

          Gstreamer is an interface for multimedia. It makes talking to codecs for purpose of code/decode a fuzz. It makes programming easier. It consists of gstreamer core and gst-plugins. Plugins are just binders to individual codec libraries mentioned before. When you install gst-plugin-ffmpeg you also install libffmpeg. You can understand it as an exoskeleton around codecs, making life much easier for a programmer. It talkes corresponding codec and outputs to correspondent sound system - two hares with one shot. It is not like MPlayer or Xine, or Ffmpeg - it lets system stay flexible. However its only Linux(BSD?).

          Example:
          Libmpeg, Mplayer(having copy of libmpeg it inside), Xine(having it inside as decode only version), Ffmpeg(having its functionality inside) are duplicates in the system. Gstreamer plugin libmpeg and libmpeg are not duplicates.

          ---- Sound Libraries
          This libraries make programmers life easier.
          Instead of talking to decoder and sound card system directly, they just talk to Sound Library.

          SDL - features capable mixer and backend. Developer just write code for SDL to play his sounds/music, and SDL compiled against ALSA, OSS, Pulse, Jack or even windows directsound - talks to them by itself for the output. Should user have any of this four or one installed, SDL will talk to them. For the en/decoding - SDL can access individual codecs automatically(as far as I know), but also has support for Gstreamer. It is crossplaform and part of big toolkit(it also has layers for networking and 3D via OpenGL). The disadvantage is its interface while more universal - is more generic(basic) than talking to this five personally(and releasing five program verions). But its more than enough for gaming.

          OpenAL - same as SDL-audio part, but more 3D audio features. Many apps can output to OpenAL or SDL, whatever you have in your system.

          Allegro - heard its same as SDL, but less featurefull, heard its practically depricated. Also Allegro worked on Pulse.

          ---- Sound Servers
          Pulse can:
          - mix streams from different sources(applications and cards)
          - per-application and per-sound card volume with mouse
          - network stream broadcasting
          - connect OSS and ALSA to one single thing. Application talk to Pulse and pulse sends to ALSA or OSS. Developer only needs to output to pulse.

          What Pulse is not:
          - it is not a codec
          - it is not a hardware manager
          - it cannot connect codecs or connect applications and codecs.
          Its just a network-capable awesome mixer.


          Phonon is DEPRICATED. Use Pulse and Gstreamer instead. Phonon is not part of KDE, but part of Qt. Originally Phonon was meant to automatically detect wherever Qt application is run on Linux(ALSA,OSS), BSD(OSS) or Windows(DSound). However, on all platforms it is unnecessary now because of pulse. Pulse is crossplatform and gives more than Phonon, hence Qt abadoned it.

          JACK is same to Pulse, but shifts on application-to-application links, lower latencies and professional usage. You can connect JACK to Pulse, JACK connects applications together and result goes to Pulse which connects it to multiple sound cards.

          ---- Sound card systems
          Further, ALSA - a hardware management and (to some degree) mixing system vs OSS are end-point audio hardware systems.
          These manage the hardware. They can take that binary stream(only unencrypted) and make a card play it.
          If you have encrypted stream(ogg,mp3,wav,flac whatever) you need to decode it before it can be send to hardware.

          Additionally OSS,compared to ALSA, features more mature mixer, easier API but is known for making crap in the past. A commercial company stands behind it - thats it. Commercial means making money by any case possible. Thats why I consider ALSA better to OSS, I can hardly imagine how OSS can make money not by selling licenses. One day they stop releasing GPL version and Linux is screwed again. Its trilicensed btw, not only GPL.


          -------- Possible playback variations:

          Raw--->ALSA or OSS--->Sound cards
          ::App need to work with ALSA or OSS

          Encrypted--->liblame---->ALSA or OSS---->Sound cards
          ::App need to work with liblame and ALSA or OSS
          Very bad mixing in ALSA.Takeover possible if app written in bad style.

          Encrypted--->Gstreamer(takes out liblame automatically)--->ALSA or OSS(whatever Gstreamer is set to)----->Sound cards
          ::App need to work with Gstreamer only.
          Very bad mixing in ALSA.Takeover not seen, since Gstreamer behaves correctly.

          Encrypted--->Gstreamer(takes out liblame automatically, set to pulse plugin)--->Pulse---->ALSA or OSS(whatever pulse is set to)----->Sound cards
          ::App need to work with Gstreamer only.
          Good mixing, no takover possible, regardless if gstreamer is not only app playing.

          Encrypted--->SDL(calls Gstreamer automatically, as it sees Gstreamer is present)--->Gstreamer(takes out liblame automatically, set to pulse plugin)--->Pulse---->ALSA or OSS(whatever pulse is set to)----->Sound cards
          ::App need to work with SDL only. It is crossplatform.
          Good mixing, no takeover possible, as above.

          Encrypted--->SDL(calls Gstreamer automatically, as it sees Gstreamer is present)--->Gstreamer(takes out liblame automatically, set to alsa or oss)--->ALSA or OSS(whatever pulse is set to)----->Sound cards
          ::App need to work with SDL only. It is crossplatform.
          Very bad mixing in ALSA.Takeover not seen, since Gstreamer behaves correctly.


          I dont see any problem with linux.

          If you program for linux only or require more features - use Gstreamer for sound operations.

          If gstreamer is too generic for you, you will have to 1) talk to codecs 2) talk to sound system of your choice -- all your way, ie manually.

          If you dont want gstreamer, xine offers similar functionality(although codec part is totally differently implemented). But gstreamer and xine can coexist(although there will be duplicated stuff)

          If you programm crossplatform - use SDL or OpenAL.
          Yes, this is not copypaste, comments welcome.

          Comment


          • #50
            Originally posted by crazycheese View Post
            First it does not support true software mixing - it cannot mix streams of different bitrate and frequency, so if one is playing 44kHz and other starts 22kHz only second is played.
            This sounds like a serious bug that needs to be fixed.

            Second DMIX does not prevent any application take over the sound card. This means for example Adobe Flash or Avidemux taking over soundcard, stopping any other music playback instantly. Any new application will exit with error unable to access device or device busy until the hijacker is closed.
            I cannot reproduce this. Adobe Flash does not block the sound card. In fact, nothing does.

            Pulse implements wide array of features, absent in ALSA, such as live audio stream rerouting. This is similar to JACK, however is desktop (and not workstation) optimized.
            So people who need it can use JACK. Or PA. Or anything they want.

            I don't see a need to make this a desktop standard and to have everything depend on it. And making it a default that is almost impossible to turn off and breaking X applications in the process, like Ubuntu did, is simply a terrible idea.

            The fact is, while per-app volume control is kind of neat, most people don't need anything else than volume control and reliable software mixing.

            Then again, mixing belongs on the sound card anyway.

            --Let me introduce you to the basics of Linux multimedia--
            I don't know if you're addressing this to me specifically, but I'm quite aware of all this, thank you.

            Phonon is not part of KDE, but part of Qt.
            You are aware that Phonon is KDE technology which was donated to Qt, right?

            Comment


            • #51
              First it does not support true software mixing - it cannot mix streams of different bitrate and frequency, so if one is playing 44kHz and other starts 22kHz only second is played.
              Can't reproduce. Just generated a 22kHz chirp in Audacity, it played just fine without interrupting my music.

              Comment


              • #52
                the last time I tried OSSv4 it so compeletly fucked up my soundcard that I had to turn off the computer. Thank you very much ossv4.

                Comment


                • #53
                  Originally posted by energyman View Post
                  the last time I tried OSSv4 it so compeletly fucked up my soundcard that I had to turn off the computer. Thank you very much ossv4.
                  Which distro?

                  Comment


                  • #54
                    OSSv4. Last time I read about it, it had no support for suspend/resume. So it's not really an option for me.

                    Comment


                    • #55
                      This fix should be made default before adoption to fix the suspend/resume issue.

                      http://wiki.archlinux.org/index.php/...nd_Hibernation

                      Code:
                      #!/bin/bash
                      
                       if [ [ $EUID -ne 0 ] ]; then
                       ## Checking if you are a root or not
                         echo "This script must be run as root" 1>&2
                         exit 1
                       fi
                      
                       s2ram -f
                      
                       sleep 2
                      
                       /etc/rc.d/oss restart 2>/tmp/oss.txt
                      
                       if [ $? -gt 0 ]; then
                       echo "OSS restart failed check /tmp/oss.txt for advice"
                       fi
                      
                       exit 0

                      Comment


                      • #56
                        That's not a fix, that's a hack. Suspend/resume must be properly supported by OSSv4 and the drivers itself.

                        Comment


                        • #57
                          Originally posted by darkphoenix22 View Post
                          Which distro?
                          gentoo. But this is not a distro issue. Sound worked - until suddenly everything turned into garbage. I tried restarting oss - no help. Removed the modules. Nothing. Rebooted. Still only loud noise. Shut down, did a save reboot, removed OSSv4, used alsa again: perfect sound.

                          Comment


                          • #58
                            Originally posted by energyman View Post
                            gentoo. But this is not a distro issue. Sound worked - until suddenly everything turned into garbage. I tried restarting oss - no help. Removed the modules. Nothing. Rebooted. Still only loud noise. Shut down, did a save reboot, removed OSSv4, used alsa again: perfect sound.
                            Try oss-devel from this overlay. My friend installed it today and he was really impressed. The regular oss package didn't work well for him though.

                            http://gentoo-overlays.zugaina.org/o.../index.html.en

                            These problems would likely be solved if OSSv4 is pushed directly into portage. It needs testing and exposure.

                            Originally posted by monraaf View Post
                            That's not a fix, that's a hack. Suspend/resume must be properly supported by OSSv4 and the drivers itself.
                            I agree. This issue needs to be fixed before it is made default in any distribution.

                            Comment


                            • #59
                              In any case, ALSA is way too complicated to be properly wrapped and extended. This is why PulseAudio was created in the first place.

                              OSSv4 is a much simpler API and would be much easier to extend and maintain. We wouldn't have to resort to high-level abstraction to add the features that users want. In any case, I believe OSSv4 needs a bit of work to add a few features needed by general users, such as the suspend/resume and hardware MIDI.

                              I believe OSSv4, with a bit of work, would be a much more soild foundation for Linux audio. However, until it is ready, it should be a choice not a default.

                              Comment


                              • #60
                                As most games use openal and that supports alsa or some other older games use sdl as abstraction layer why does the api matter? You can compile newer libs or just use the prebuild ones which come with the distro (a bit compilicated on 64 maybe). if the names are different just use a few symlinks. For other games like et there are already alsa wrappers - needed for maverick anyway.

                                http://ubuntuforums.org/showthread.php?t=362231

                                So basically i don't see your huge problem...

                                Comment

                                Working...
                                X