Page 41 of 50 FirstFirst ... 313940414243 ... LastLast
Results 401 to 410 of 500

Thread: Linux is not ready for Steam

  1. #401
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Well I do like it. One against one.

  2. #402
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by darkphoenix22 View Post
    Well I do like it. One against one.
    Quote Originally Posted by Måns Rullgård
    Sorry, floating point in the Linux kernel isn't allowed.
    Seems I'm not the only one.

  3. #403
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    I really don't care for politics.

    And again:

    I don't why switching devices requires an API that takes over the driver APIs and re-buffers the audio.

  4. #404
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Edit:

    I don't see why switching devices requires an API that takes over the driver APIs and re-buffers the audio.

  5. #405
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by rqosa
    It's not necessarily "better" to do mixing in the kernel instead of in userspace.

    The maintainers of Linux won't allow any floating-point operations in the kernel, because that would require a save/restore of FPU state on entering a system call and on returning from a system call, which has a performance cost.

    Incidentally, the original developer of of OSS (Hannu Savolainen) seems to have GPLed the current upstream OSS (OSSv4) now, so it's not the license that's keeping it out of Linux upstream anymore. Instead, it seems to be the issue of in-kernel mixing that's the problem (and maybe other problems too). According to Hannu's comment here (search for "OSS does this by" to find the comment), the mixing code runs with interrupts disabled and does its own save/restore of FPU state. That alone is probably sufficient to prevent it from getting merged into Linux upstream.
    Another one

  6. #406
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by darkphoenix22 View Post
    Edit:

    I don't see why switching devices requires an API that takes over the driver APIs and re-buffers the audio.
    Perhaps some reading might be in order.

  7. #407
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Still:

    Why does switching devices requires an API that takes over the driver APIs and re-buffers the audio?

  8. #408
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by darkphoenix22 View Post
    Still:

    Why does switching devices requires an API that takes over the driver APIs and re-buffers the audio?
    The kernel is not an appropriate place for this functionality. It should be done in userspace.

  9. #409
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Again:

    Switching the audio via the Xfce Mixer works well enough. Why can't the mixer be extended without affecting the sound APIs.

  10. #410
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by darkphoenix22 View Post
    Again:

    Switching the audio via the Xfce Mixer works well enough. Why can't the mixer be extended without affecting the sound APIs.
    Again, then the functionality of Pulse is then simply re implemented i the Xfce mixer. Not eliminated, re-implemented. The code doesn't go away.


    You are confusing implementation specific issues with architectural requirements. If the specific implementation of Pulse is sub-standard then that can be fixed but the functionality needs to be implemented somewhere. If not in Pulse, then elsewhere, but definitely no in the driver itself.

    Shifting the code means you've moved it, not eliminated it.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •