Reply With QuoteI 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.Originally Posted by bwat47
Senior Member
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.
Senior Member
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.
Junior Member
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 06:16 PM.
Senior Member
If you read the relevant article you'd see that PA is actually MORE efficient than AF (determined by number of wakeups).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 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).
Senior Member
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.
Junior Member
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 10:07 PM.
Senior Member
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.
Junior Member
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
Junior Member
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.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.
Junior Member
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
