[maemo-developers] Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future

From: Benno Senoner benno.senoner at googlemail.com
Date: Wed Jun 16 12:56:48 EEST 2010
Hi,
Can you back up your claims that pulseaudio uses less CPU than JACK ?
pulseaudio cannot do wonders, if mixing is required the code must sum
up the inputs, jack does this
already in the most efficient manner and one can easily add ARM vector
code to speed it up.
I mean if battery is a concern then suspending the mixing of certain
channels is not a problem and you save CPU.
For example skype does not support jack but it supports ALSA.
There is an alsa to jack module which provides a virtual ALSA device
which is routed into jack.
If I use skype with it, a jack input port (source) is created while
the virtual ALSA device is open.
Skype always closes the audio device so if you are not in a call and
are only using the chat,
then only while the chat beep sound is emitted the ALSA device (and
thus the jack input port) is open.
If you run qjackctl to visualize the connection graph, you see that
the input port quickly appears and disappears
after the sound has been played.
And if the port is not present, JACK does not need to route and mix
the audio to the physical outs, thus saving CPU.

Since jack has not been deployed on battery powered devices yet, it's
normal that it does not contain CPU saving power management
functions. But adding those is much easier than adapting pulseaudio
which was not designed with real time and multi processing in mind.

Soon we will see multicore ARM CPUs on phones, pdas and tablets since
it is cheaper and more power efficient than increasing the
frequency of a single core. JACK can utilize all those cores giving
providing smooth audio even under very high load and while many
applications are started.
If the manufacturers puts a fast CPU into a device, I guess the goal
is to give the user a way to utilize it and exploit all its features.

The big problem of digital audio is that it is a complex subject and
getting things right is very hard and any initial design error will
hurt you at a later stage.
Finding a developer which fully understands all aspects of real time
audio is hard, because you need knowledge in many fields, real time
programming, priorities, multi threading,
 RT safe memory allocation, synchronization promitives, lock free
FIFOs, DSP algorithms, etc etc.
This is why I think companies don't try hard enough, they hire some
random guy whose CV looks good on paper but then produces badly
designed, inefficient stuff which
later will plague the platform for the entire lifecycle and often it's
to complex or expensive to fix the system later, so users do have to
live with the flaws of the system.

Millions of future users and developers don't want the same fate for
Meego, so Nokia please listen and fix those issues.

Of couse I'm not expecting that the N900 on Maemo should run JACK.
Maemo will be supplanted with Meego and it makes no sense to push for
changes on a platform
which has reached it's end of line.

I don't understand why big corporations like Nokia don't work in a
more clean way, is benchmarking and running unit tests a foreign word
?

Adopting pulseaudio which has no good track record of providing low
latency as a key part of a mobile computing platform which is aimed to
become the best that the market can offer
is a quite irresponsible move.

pulseaudio was just forced down to Linux desktop user's throats
because it was adopted by Fedora and Ubuntu because it's packagers
thought that it works well. But unfortunately only
on paper. And Nokia blindly adopted it too (because it must be good
since it was adopted by a few distros), causing lots of problems to
users with it.

I'm the first to admit errors or flaws or mistakes if someone points
them out, but people must come up with numbers and proofs.
JACK has already proven that it is the most efficient and versatile
audio routing platform in existence and has been deployed in
commercial products.

If Nokia can show us that pulse audio is able to achieve
stable,dropout-free 10-20 msec audio latencies in any audio app
requiring it and working perfectly
when using QAudioInput/QAudioOutput classes then I'll shut up and take
my words back, but at the moment the situation does not seem so, and I
fear that
those "features" will be inherited by Meego.

regards,
Benno
The LinuxSampler Project
http://www.linuxsampler.org










2010/6/16 Xavier Bestel <xavier.bestel at free.fr>:
> On Wed, 2010-06-16 at 01:27 +0200, Benno Senoner wrote:
>> So my advice to Nokia, while still in time, cosider switching to JACK
>> as an audio server for future versions of Meego,
>
> The N900 already sucks batteries like mad. JACK is a no-compromise
> low-latency pro audio server, and does it at the expense of some
> processor time. You don't want it on an N900, otherwise the poor battery
> life would be even worse.
>
>        Xav
>
>
More information about the maemo-developers mailing list