Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Thanks for the corrections -- does netjack have a low enough latency to work for recording?
Posted Sep 19, 2008 21:43 UTC (Fri) by jebba (✭ supporter ✭, #4439)
Yes. You can also do things like have a remote machine just do the LADSPA filtering to distribute the load, for example. It works and is solid. I've done similar things with pulseaudio and it felt like I had just duct taped a boat together. Jack rules.
Also, netjack2 is under development with the next generation of jack, which is based on jackdmp.
I wish the netgods would all settle on jackd and figure out how to solve its power consumption issues, if at all possible. Use the best! If some of the features are overkill for the desktop, just don't expose them in the simpler GUIs...
Posted Sep 20, 2008 7:24 UTC (Sat) by jwoithe (subscriber, #10521)
Although completely untested, I wonder if simply specifying a very large period size for JACK would go some way to addressing this. At least some of the reason for the high resource usage of JACK is that currently most of its users require low latency and so run with very small buffers. Desktop users don't require low latency, so running large buffers wouldn't matter there. Larger buffers mean fewer wakeups and thus lower power consumption.
JACK is certainly not a replacement for anything else at present, but I do wonder whether with some work it could be used as the basic building block for a universal audio system.
The other thing worth reiterating here is that JACK does much more than just provide access to audio hardware. It is also a signal router allowing audio to be routed arbitarily between applications as well as to/from a physical soundcard. This, along with its low latency performance, is what makes it extremely useful to pro audio and music production users.
Posted Sep 20, 2008 7:52 UTC (Sat) by jebba (✭ supporter ✭, #4439)
As an example, I use it the base of http://freeeee.org a distro for eee pc.
Posted Sep 21, 2008 23:55 UTC (Sun) by mezcalero (subscriber, #45103)
Posted Sep 23, 2008 0:46 UTC (Tue) by jebba (✭ supporter ✭, #4439)
There are two FREEEEE modes: full-on media and low power ebook.
With jack, multiple mplayers, freej, firefox, chat, xournal, an offline copy of wikipedia, an image viewer, wifi, camera, etc all running it runs hot, yes. :) But it also runs all that fine without dropouts or crashing. jack performs reliably *now* and is never the weak link. Occasionally I have used pulseaudio as a jack client, which is convenient, but it is no where near as reliable as jack.
jack is clean, "feels" like a nice unix utility (it does its "one thing" extremely well), and has a committed upstream community.
Second mode yet to be completed :)
Posted Sep 21, 2008 23:54 UTC (Sun) by mezcalero (subscriber, #45103)
Allowing rewrite of audio buffers is what JACK doesn't do. And adding this makes things very complicated. I did it for PA, but I simply see no reason for JACK to do it as well. Also, since JACK allows much more complex routing than PA, the rewriting buffer issue becomes equally more complex. i.e. every part that becomes part of a JACK pipeline would need to be able to "rewind" its state. That means every JACK client application would have to be patched non-trivially.
Posted Sep 21, 2008 23:48 UTC (Sun) by mezcalero (subscriber, #45103)
JACK is optimized for lowest latencies, CPU load comes second, and dynamic interruption-free changing of these parameters is not required. For PA however, we want dynamic latencies, generally low CPU load and the parameters need to be flexible.
But even if you would add "glitch-free" to JACK (which makes no real sense), it still is not designed for desktop use. PA carefully makes sure not to convert (or not even touch) audio data if not necessary. OTOH JACK only knows FLOAT samples, and thus audio type conversion is necessary usually at output and often enough on input too. That makes a lot sense for them. It's a very good choice, but it's not the right choice for the desktop.
The requirements of desktop/embedded use, and pro audio use are different. This results in different products. Trying to marry them is a great idea, but also very difficult to achieve. Of course, we should be trying to do this, but we have much bigger problems to fix before we start with that.
Posted Sep 22, 2008 7:24 UTC (Mon) by alankila (subscriber, #47141)
The buffers passed between applications were still void * pointers and the only clue for their contents was a simple string describing what kind of format you had requested from JACK, a #define which expanded to a string such as "32-bit pcm floating point audio"...
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds