Page 4 of 4 FirstFirst ... 234
Results 31 to 40 of 40

Thread: PulseAudio Ported To Android, Compared To AudioFlinger

  1. #31
    Join Date
    Jan 2009
    Posts
    1,705

    Default

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

  2. #32
    Join Date
    Oct 2009
    Posts
    213

    Default

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

  3. #33
    Join Date
    Dec 2011
    Posts
    38

    Default

    Quote 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 at 07:16 PM.

  4. #34
    Join Date
    Jan 2009
    Posts
    1,435

    Default

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

  5. #35
    Join Date
    Jan 2009
    Posts
    1,435

    Default

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

  6. #36
    Join Date
    Dec 2011
    Posts
    38

    Default

    Quote 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 at 11:07 PM.

  7. #37
    Join Date
    Jan 2009
    Posts
    1,435

    Default

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

  8. #38

    Default

    Quote 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

  9. #39

    Default

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

  10. #40

    Default

    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.

Posting Permissions

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