Announcement

Collapse
No announcement yet.

Collabora Keeps Pushing PulseAudio For Android

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

  • phoronix
    started a topic Collabora Keeps Pushing PulseAudio For Android

    Collabora Keeps Pushing PulseAudio For Android

    Phoronix: Collabora Keeps Pushing PulseAudio For Android

    Arun Raghavan while working for Collabora has made additional progress in his porting of the PulseAudio stack to Android. He has made progress in replacing Google's AudioFlinger audio subsystem with the once-controversial PulseAudio...

    http://www.phoronix.com/vr.php?view=MTA5NDM

  • Lynxeye
    replied
    PulseAudio can achieve very low latencies. The only thing is: your apps need to communicate their latency needs to the Pulse server, otherwise it tries to save energy and work with a higher latency and only adjusts to your apps need after there has been drop outs.

    So when app writers finally accept Pulse as the feature-rich audio system of the future and build their apps nativly on top of Pulse and not some ALSA-Pulse plugin, I will be easy going for them to meet their latency needs.

    Leave a comment:


  • curaga
    replied
    Originally posted by liam View Post
    and by not using Jack unless you actually need REALLY low latency, you still get PA's many advantages including simd ops.
    Look ma, my infinite loop is SSE4 optimized!!111

    Leave a comment:


  • liam
    replied
    Originally posted by raindog469 View Post
    Good thing we don't need zero latency, then. There's a pretty huge gap between zero latency and the 50-100ms range of a typical PulseAudio setup. I'm happy with 5ms, and if Pulse can do that on the Android hardware that's out there, well, great.
    Arun demonstrated that you can easily get 20ms with PA on Android. Now considering even the iphone ends up with around 50ms or so latency, the extra 15ms that PA currently adds doesn't seem like much. When he finishes the port, we might be able to expect even less latency.



    Even with a "realtime" kernel, Linux is not hard realtime and neither is JACK. On my system, a dropout means the "xruns" count in qjackctl increments and I mutter obscenities and remember the timestamp so I can go back and check for clicks when I'm done. No server death unless you want it.
    The problem isn't that Linux can't do hard rt or not but rather the particulars of the system. RTOS' are typically made with very particular constraints in mind and a desktop is pretty much at the opposite end of simple controllers you seem them on.
    An interesting place to see read about various systems latencies is OSDAL. They'll run their systems for a year at a time and chart the latencies. Even under load, the jitter is surprisingly low on these general purpose machines.

    Leave a comment:


  • raindog469
    replied
    Originally posted by allquixotic View Post
    And what are you going to do with JACK support on an Android mobile device?
    Record music while listening to what's already been recorded, do live effects ... actually, that's all I want, those two things. On my tablet, not my phone.

    Originally posted by allquixotic View Post
    As was once boldly and plainly declared to me by one of the JACK maintainers on IRC, "it is utterly impossible to do 3d graphics and zero latency audio on the same system at the same time, so if you are trying to do that, you should give up now."
    Good thing we don't need zero latency, then. There's a pretty huge gap between zero latency and the 50-100ms range of a typical PulseAudio setup. I'm happy with 5ms, and if Pulse can do that on the Android hardware that's out there, well, great.

    Originally posted by allquixotic View Post
    you pretty much can't mix most drivers with an appreciable real-time system like JACK, where a dropout means "game over" (the sound server literally dies if it drops out at all).
    Even with a "realtime" kernel, Linux is not hard realtime and neither is JACK. On my system, a dropout means the "xruns" count in qjackctl increments and I mutter obscenities and remember the timestamp so I can go back and check for clicks when I'm done. No server death unless you want it.

    Leave a comment:


  • liam
    replied
    Originally posted by allquixotic View Post
    And what are you going to do with JACK support on an Android mobile device?

    As was once boldly and plainly declared to me by one of the JACK maintainers on IRC, "it is utterly impossible to do 3d graphics and zero latency audio on the same system at the same time, so if you are trying to do that, you should give up now."

    I think he was alluding to the fact that the latencies introduced into the kernel by 3d drivers cause such an unpredictable mess that you pretty much can't mix most drivers with an appreciable real-time system like JACK, where a dropout means "game over" (the sound server literally dies if it drops out at all).

    What's more important on an Android system to most users: graphics performance or audio that can't drop out by design? Apparently you can't have both.

    But you can have an audio server design that assumes there WILL be dropouts, and algorithmically optimizes itself to minimize their frequency and duration and tries to prevent them in the future. And I think that's exactly the kind of leniency we need on a platform where you won't lose $1,000,000 because of a single click in the audio feed (whereas such losses are quite likely if you're recording the performance of a highly-paid symphony orchestra that bills by the hour).
    While I don't doubt the dev said this, Apple and Microsoft have clearly shown you can do both low latency and 3d.
    Now, what we could have is both Jack and PA. This is being looked at for the Fedora audio spin. PA handles most things, but the rest are past through to Jack. This should be possible on Android, and by not using Jack unless you actually need REALLY low latency, you still get PA's many advantages including simd ops. What I'm not sure about is how able PA is able to deal with the dsps on the average Android device.
    As Arun has shown even simply using PA reduces latency by a surprisingly large amount (probably enough for music creators since the hardware itself is so damns laggy (I'm including iDevices as well)), so I really hope Google will take advantage of the very well tested PA.

    Leave a comment:


  • allquixotic
    replied
    Originally posted by raindog469 View Post
    I'd be more excited if it were JACK support, but that really is something Google would have to have a hand in, unless you'd like your JACK-dependent app to be useful only to those with custom ROMs.
    And what are you going to do with JACK support on an Android mobile device?

    As was once boldly and plainly declared to me by one of the JACK maintainers on IRC, "it is utterly impossible to do 3d graphics and zero latency audio on the same system at the same time, so if you are trying to do that, you should give up now."

    I think he was alluding to the fact that the latencies introduced into the kernel by 3d drivers cause such an unpredictable mess that you pretty much can't mix most drivers with an appreciable real-time system like JACK, where a dropout means "game over" (the sound server literally dies if it drops out at all).

    What's more important on an Android system to most users: graphics performance or audio that can't drop out by design? Apparently you can't have both.

    But you can have an audio server design that assumes there WILL be dropouts, and algorithmically optimizes itself to minimize their frequency and duration and tries to prevent them in the future. And I think that's exactly the kind of leniency we need on a platform where you won't lose $1,000,000 because of a single click in the audio feed (whereas such losses are quite likely if you're recording the performance of a highly-paid symphony orchestra that bills by the hour).

    Leave a comment:


  • raindog469
    replied
    I'd be more excited if it were JACK support, but that really is something Google would have to have a hand in, unless you'd like your JACK-dependent app to be useful only to those with custom ROMs.

    Leave a comment:


  • allquixotic
    replied
    This would be awesome. I see huge latencies (and cracks and pops) on my Android phone. Android phone DSPs really need top notch ALSA drivers, and then PulseAudio is the obvious choice.

    Leave a comment:


  • 89c51
    replied
    of course you can do anything you want with open source but having google's deeeeeeeeeeeeeeep pockets to support this would benefit everything

    hence my question about if google is interested.

    Leave a comment:

Working...
X