[maemo-developers] Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
From: Benno Senoner benno.senoner at googlemail.comDate: Wed Jun 16 12:56:48 EEST 2010
- Previous message: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
- Next message: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 > >
- Previous message: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
- Next message: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]