Page 42 of 50 FirstFirst ... 324041424344 ... LastLast
Results 411 to 420 of 500

Thread: Linux is not ready for Steam

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

    Default

    I don't care where the code is. I only care if it doesn't allow apps and libraries to address ALSA like they expect. And if it reprocesses the audio and buffers the audio, causing extra latency.

  2. #412
    Join Date
    Jun 2010
    Posts
    3

    Cool Sound APIs

    Recap for my own sanity:

    1) So with OSSv4, many functions that are not essential to run in kernel space are included there and it uses some bizarre method of interrupt handling that likely excludes it from kernel inclusion as well.

    2) PulseAudio causes issues with QoS in some circumstances due to how it handles driver interaction and buffering.

    3) We could use ALSA.

    I suppose the point of this argument from the beginning has been that the sound APIs preclude Linux from being a viable platform for Steam to release on because it would be too difficult for Valve and its clients (game manufacturers) to manage all of the differences.

    I think the real issue here is a surplus of choice and not many good ones.

    Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?

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

    Default

    Perfect summary. Thank you.

  4. #414
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by darkphoenix22 View Post
    I don't where the code is. I only care if it doesn't allow apps and libraries to address ALSA like they expect. And if it reprocesses the audio and buffers the audio, causing extra latency.
    But if you're arguing for the complete elimination of a project due to a implementation specific failure then every project that's not perfect needs to be eliminated which doesn't leave us with much code.

    If an ALSA driver has a bug you don't throw all of ALSA out, you fix the driver. If Pulse has a specific issue with a particular piece of middleware then you can patch either the middleware, Pulse or both.

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

    Default

    Quote Originally Posted by p0larity View Post
    Recap for my own sanity:

    1) So with OSSv4, many functions that are not essential to run in kernel space are included there and it uses some bizarre method of interrupt handling that likely excludes it from kernel inclusion as well.

    2) PulseAudio causes issues with QoS in some circumstances due to how it handles driver interaction and buffering.

    3) We could use ALSA.

    I suppose the point of this argument from the beginning has been that the sound APIs preclude Linux from being a viable platform for Steam to release on because it would be too difficult for Valve and its clients (game manufacturers) to manage all of the differences.

    I think the real issue here is a surplus of choice and not many good ones.

    Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
    Unfortunately there's no one perfect one size fits all solution so we can only choose from a pool of imperfect choices.

  6. #416
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Quote Originally Posted by mugginz View Post
    But if you're arguing for the complete elimination of a project due to a implementation specific failure then every project that's not perfect needs to be eliminated which doesn't leave us with much code.

    If an ALSA driver has a bug you don't throw all of ALSA out, you fix the driver. If Pulse has a specific issue with a particular piece of middleware then you can patch either the middleware, Pulse or both.
    It has issues with about 10 kinds of middleware.

    Again the problem with PulseAudio isn't the ideals. It's implementation. It breaks things as it meddles where it doesn't need to meddle.

    There no reason why PulseAudio needs to rebuffer and reprocess the audio. And furthermore, there's no reason why that process can't be bypassed.

  7. #417
    Join Date
    Jun 2010
    Posts
    3

    Default

    Quote Originally Posted by mugginz View Post
    Unfortunately there's no one perfect one size fits all solution so we can only choose from a pool of imperfect choices.
    That sounds like a niche to me.

    </enterprising>

    Too bad being a developer during the day eats up my hours of useful time.

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

    Default

    Quote Originally Posted by darkphoenix22 View Post
    It has issues with about 10 kinds of middleware.

    Again the problem with PulseAudio isn't the ideals. It's implementation. It breaks things as it meddles where it doesn't need to meddle.

    There no reason why PulseAudio needs to rebuffer and reprocess the audio. And furthermore, there's no reason why that process can't be bypassed.
    But there is a need to do this. Especially when you're got no hardware mixing. If Pulse doesn't do it then ALSA must dmix it. Either way, something has to. I personally find Pulses audio mixing sounds better as well.

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

    Default

    Quote Originally Posted by mugginz View Post
    But there is a need to do this. Especially when you're got no hardware mixing. If Pulse doesn't do it then ALSA must dmix it. Either way, something has to. I personally find Pulses audio mixing sounds better as well.
    Well dmix doesn't cause nearly as many problems as PulseAudio. PulseAudio is just too invasive. It does way too much. Probably the best course of action with PulseAudio is to split the project and repartition it out.

  10. #420
    Join Date
    Jul 2008
    Posts
    833

    Default

    Quote Originally Posted by p0larity View Post
    Is there something here that solves the problem of being a reliable, stable API that developers can hook into while also being consistent across distros and complete enough to offer the end-user a good experience?
    A real future oriented game engine, not this bristle-work called Source... <.=.<

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
  •