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 Teho View Post
    In that case it's not necessary for drastic changes like merging two sound servers that obviously can't be merged (in sense of code, community, API etc...). A better support for Jack in PulseAudio would be more appropriate. I think that Ubuntu Studio tried something like that but I'm not sure what came out of it.
    yes it will probably (don't know the technicalities behind that) be a heck of a job to merge but at some point it must be done IMO.

    here is Lennarts blog post explaining the situation and possibilities

    http://0pointer.de/blog/projects/whe...-when-not.html

    and while i cant say anything about the technical part of the whole thing i have arguments against his user cases.

    Comment


    • #32
      Originally posted by bwat47 View Post
      There's nothing wrong with pulseaudio, It was only pushed too early into ubuntu and fedora before it was ready. I haven't had problems with it in ages. So sick of the ridiculous hate comments it gets for no reason.
      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.

      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.
        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; 01-17-2012, 07:16 PM.

        Comment


        • #34
          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


          • #35
            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


            • #36
              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; 01-17-2012, 11:07 PM.

              Comment


              • #37
                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


                • #38
                  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.

                  https://forum.openwrt.org/viewtopic.php?pid=150596

                  Comment


                  • #39
                    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


                    • #40
                      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


                      • #41
                        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