Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Collabora Keeps Pushing PulseAudio For Android

  1. #1
    Join Date
    Jan 2007
    Posts
    14,770

    Default 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

  2. #2
    Join Date
    Jan 2009
    Posts
    1,676

    Default

    and this begs a question (or two).

    are we heading to a unified stack for both android and the distros??

    i mean the kernel unification is being worked, Pulse also and then Wayland.

    and is google intrested on that or its just collabora having fun hacking stuff??

  3. #3
    Join Date
    Sep 2009
    Posts
    59

    Default Yay!

    I for one as a user & programmer celebrate unification. This stops obsoleting awesome Linux software (yes there's a very long list), and stops obsoleting developer skills.
    If Microsoft keeps marching with EFI to lock out Linux, we may just lose easy x86 installations. Lets go with Android-on-anything to run free software.

    Google,
    Here's where you should commit to embrace this.

  4. #4
    Join Date
    Apr 2012
    Posts
    117

    Default

    Please, Google, jump in and help with this!

  5. #5
    Join Date
    Jul 2009
    Posts
    351

    Default Free Software!

    Quote Originally Posted by 89c51 View Post
    and is google intrested on that
    With free software, public demand and developer effort, the only acceptable answer is IT DOESN'T MATTER

    The best technology will come forward and get integrated regardless of whether google wants it or not

    This is why we have app stores and independent developers.

    Honestly if google wants to get interested in the kinds of network connections made from your Android device, or how you can stream content into or out of it, you should tell them to sod off. It is your device.

    REALLY think about it! If google said "we don't want pulseaudio running on android" WHAT DO YOU THINK WOULD HAPPEN? A bunch of middle fingers would fly up and we would still have pulseaudio on android. That is Free Software.

    Remember the Microsoft slogan is really "where do you want to be taken today?" as opposed to "where do you want to go". With open systems you can do it your way instead of how the vendor wants you to do it.

    This question is really no different than asking "what does oracle care about android" The jury is literally out at the moment, but again the proper answer is "it doesn't matter what oracle thinks"
    Last edited by frantaylor; 04-30-2012 at 05:06 PM.

  6. #6
    Join Date
    Jan 2009
    Posts
    1,676

    Default

    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.

  7. #7
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  8. #8
    Join Date
    Apr 2011
    Posts
    12

    Default

    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.

  9. #9
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote 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).

  10. #10
    Join Date
    Jan 2009
    Posts
    1,401

    Default

    Quote 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.

Posting Permissions

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