"I wish the netgods would all settle on jackd and figure out how to solve its power consumption issues, if at all possible."
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)
[Link]
"I do wonder whether with some work it could be used as the basic building block for a universal audio system."
As an example, I use it the base of http://freeeee.org a distro for eee pc.
Thank you
Posted Sep 21, 2008 23:55 UTC (Sun) by mezcalero (subscriber, #45103)
[Link]
Hehe, I like that. Is that a distro optimized for minimal battery lifetime of your Eeepc? Sounds like a great selling point, makes a lot of sense to me ;-)
Lennart
Thank you
Posted Sep 23, 2008 0:46 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
"Is that a distro optimized for minimal battery lifetime of your Eeepc?"
There are two FREEEEE modes[1]: 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.
-Jeff
[1]Second mode yet to be completed :)
Thank you
Posted Sep 21, 2008 23:54 UTC (Sun) by mezcalero (subscriber, #45103)
[Link]
It's not just about using 2s large buffers. If you use large buffers like that you also need to allow rewriting of them (which means "rewinding" of all filters in the system and so on). Because if you couldn't rewrite them pressing stop or start in your media playback would actually only result in what you hear 2s later.
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.