18 Dec
2010
18 Dec
'10
9:09 p.m.
Hi,
I'm now subscribed to the linux-audio ML, so more people will be
happily spammed directly from my mailbox... some notes below.
On Sat, Dec 18, 2010 at 8:33 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
FYI, here's an example of the kind of app that
needs to have good audio
performance on a handset:
http://www.youtube.com/watch?v=bwqflVX5oNo
http://www.warmplace.ru/soft/sunvox/
( http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-December/074828…
)
Good example, even though I prefer Buzztard ;) . Dunno if the latter
runs on embedded devices though.
I also wrongly wrote we were on the IVI mailing list, while it
actually was the Handset one, where it's more likely to have audio
editing applications.
It has decent performance on maemo and appears to use pulseaudio,
which eats 1/3 of the CPU of the 'sunvox' process. The sunvox
application appears to have a UI thread and a worker thread each
consuming about 1/2 of the 35% CPU load of the app.
another issue with audio servers running on an "embedded" device is
the particular care we need to give to the memory usage: as the
swapper may not have pity when time comes to go and find some system
memory, the latencies introduced by the operation on the real-time
process could suspend it for a while. And if you have plenty of
modules loaded, memory-locking the process is a mere chimera.
The audible effect, as usually the DMA keeps on running from the audio
chip data bus, is that the latter continues transferring what's stored
there as if it was a ringbuffer, with what I love to call the
"Woodland Critters" (woodpecker, squirrel-eating-acorn, etc..) effect.
Here, we could still argue about the necessity of virtual memory on an
"embedded" device, but imho it comes together with the one to give
users an experience equivalent to the one they've on their desktop,
the cost of SDRAMS wrt NAND flashes and the delta in energy
consumption...
Mem: 238432K used, 7108K free, 0K shrd, 3396K buff, 67580K cached
CPU: 52.2% usr 7.8% sys 0.0% nice 39.8% idle 0.0% io 0.0% irq 0.0% softirq
Load average: 0.99 0.45 0.16
PID PPID USER STAT RSS %MEM %CPU COMMAND
1916 1162 user S 6388 2.5 35.1 /usr/bin/sunvox
825 1 pulse R < 3812 1.5 12.1 /usr/bin/pulseaudio --system
--high-priority
897 730 root S < 16524 6.7 9.6 /usr/bin/Xorg -logfile
/tmp/Xorg.0.log -logverbose 1 -nolisten tcp -noreset -s 0 -core
Doing an "ls -lR /" in a remote xterm (over SSH) results in some audio
glitching, but no "desynchronization" where the audio just stops
playing.
The audio glitching may actually come from the effect I exposed above
(from "top", system memory is loaded at more than 50%). The Resource
Policy Framework would help with this (it's not only handling audio
routing, but also the system memory available for processes, forcing
some to swap more often than others) but it can't do miracles ;).
The apparently high CPU load may be due to many causes, like the ones
I wrote about in my previous email. Also, setting a too low latency on
the pulseaudio client tends to increase the CPU usage. In my mind I
explained it as the fact that low latencies require shorter time
windows which, after a Fourier transformation, imply a wider frequency
range to be processed per time unit.
Regards
-- Niels.