Announcement

Collapse
No announcement yet.

PulseAudio Ported To Android, Compared To AudioFlinger

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

  • #31
    Originally posted by blackshard View Post
    I took a look in PA source code, many of the resamplers are filled with comments about slow performance, and there's no SIMD use at all.
    Android live on mobile device which CPU and battery resource is scarce

    To be competitive, the system need to be low-power, low latency, good sound quality (floating point sound mixing must be used but this is expensive)

    To meet this target, "CPU-efficient" is necessary.
    To be "CPU-efficient", SIMD instruction must be used
    context switch should be avoided as much as possible => sound mixing in kernel mode

    PA simply do not meet this requirement.

    if Android go for resource-hungary application such as HD movie, 3D games in the future.
    Google will need to send hundreds of best programmer to optimize PA (but i doubt if this will succeed)
    Why don't they use right tool at the beginning? OSS4 or add floating point kernel sound mixing to ALSA. It save their time
    Last edited by unknown2; 17 January 2012, 08:16 PM.

    Comment


    • #32
      Originally posted by unknown2 View Post
      Android live on mobile device which CPU and battery resource is scarce

      To be competitive, the system need to be low-power, low latency, good sound quality (floating point sound mixing must be used but this is expensive)

      To meet this target, "CPU-efficient" is necessary.
      To be "CPU-efficient", SIMD instruction must be used
      context switch should be avoided as much as possible => sound mixing in kernel mode

      PA simply do not meet this requirement.

      if Android go for resource-hungary application such as HD movie, 3D games in the future.
      Google will need to send hundreds of best programmer to optimize PA (but i doubt if this will succeed)
      Why don't they use right tool at the beginning? OSS4 or add floating point kernel sound mixing to ALSA. It save their time
      If you read the relevant article you'd see that PA is actually MORE efficient than AF (determined by number of wakeups).
      If OSS4 was any good I'm sure Google would've used it (similarly if PA had been good enough 3+ years ago it would've been used).

      Comment


      • #33
        Originally posted by blackshard View Post
        I took a look in PA source code, many of the resamplers are filled with comments about slow performance, and there's no SIMD use at all.
        They apparently do use simd code, only it's through OIL http://www.freedesktop.org/wiki/Soft...udio/Notes/1.0
        The problem is that they don't use it enough. That is on the list, however.

        Comment


        • #34
          Originally posted by liam View Post
          If you read the relevant article you'd see that PA is actually MORE efficient than AF (determined by number of wakeups).
          If OSS4 was any good I'm sure Google would've used it (similarly if PA had been good enough 3+ years ago it would've been used).
          yup, but i think he need more test on
          1. CPU load and power consumption when pulseaudio is serving "low-latency" client(s).
          2. worst latency encountered and their distribution when serving "low-latency" client(s).
          3. condition 2 + CPU under 100% loading.

          Anyway, the cpu of his tested phone "galaxy nexus" is not slow. Does he need to test on some weak phone instead?
          Last edited by unknown2; 18 January 2012, 12:07 AM.

          Comment


          • #35
            Originally posted by unknown2 View Post
            yup, but i think he need more test on
            1. CPU load and power consumption when pulseaudio is serving "low-latency" client(s).
            2. worst latency encountered and their distribution when serving "low-latency" client(s).
            3. condition 2 + CPU under 100% loading.

            Anyway, the cpu of his tested phone "galaxy nexus" is not slow. Does he need to test on some weak phone instead?
            The latency is soley the provision of the kernel, and android only uses the soft realtime kernel, hence why you can get huge delays on occasion.
            However, PA can make use of some RT features (some kinds of kernel thread preemption, but that is no worse than ios or windows), thus 3 shouldn't be to different from 2 (for the most part).
            Regardless of the CPU load when used in low latency mode, at least it is more able to satisfy those needs than AF ever can, apparently.
            I really want to hear from Google's engineers about this.

            Comment


            • #36
              Originally posted by jackflap View Post
              I would love to see PA on Android.

              It would make a kick-ass Apple Airplay competitor since you could stream high-quality audio directly to a sink on another device. Think Raspberry Pi acting as an Airport Express.
              I already got pulseaudio fully working on WR703N so you can stream audio via wifi. It costs only $22 including delivery plus you can get it now. Way better than rasp_pi.

              Comment


              • #37
                Originally posted by unknown2 View Post
                my experience on pulseaudio was terrible.

                On my PC, it suck up CPU and introduce latency and gitches when i play HD Movie and game. it neither utilize hardware acceleration of my sound card nor the SIMD instruction of the CPU

                On a Nokia N900 phone and i found out that pulseaudio suck around 30% CPU when play music!

                On power-scarce mobile device, I hope introducing PA will not be a disaster. Pulseaudio is not designed to be a cpu-efficient and low-latency sound server after all.

                Actually, i think that Google should try to introduce sound mixing in kernel, like OSS does.
                Try pulseaudio 1.1 and you will be amazed. Also different resampling method will make a big difference. Personally I would recommend ffmpeg which will use about 10% cpu to do the resampling from 44.1K to 48K on my sluggish atom cpu.

                Comment


                • #38
                  Alsa itself will introduce an extra buffer of its dmixer. This will also force to resample to 48K (due to AC97). If you want to improve latency you need to use raw device like hw. Latency can also be fine tuned by default-fragments and default-fragment-size-msec in /etc/pulse/daemon.conf. I have achieved excellent latency with pulseaudio streaming audio over wifi network, i.e. no video/audio out of sync when watching videos.

                  Comment


                  • #39
                    Originally posted by s7mx1 View Post
                    Try pulseaudio 1.1 and you will be amazed. Also different resampling method will make a big difference. Personally I would recommend ffmpeg which will use about 10% cpu to do the resampling from 44.1K to 48K on my sluggish atom cpu.
                    I also use ffmpeg. Good stuff.

                    Comment

                    Working...
                    X