Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
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
Still don't see why JACK would be much worse than common desktop audio systems in this scenario though.
Realtime group scheduling doesn't know JACK
Posted Jan 6, 2011 18:23 UTC (Thu) by dlang (✭ supporter ✭, #313)
that means that the total latency that can be tolorated is less than for a normal desktop app, so the buffers can't be as large.
Posted Jan 10, 2011 13:58 UTC (Mon) by nye (guest, #51576)
There exists at least one choice of buffer size which is sufficient for at least one possible purpose, with which it is possible to get skip-free audio using other sound systems on a normal kernel, but only on a real-time kernel using JACK.
Posted Jan 10, 2011 14:04 UTC (Mon) by nye (guest, #51576)
Posted Jan 12, 2011 19:33 UTC (Wed) by jrigg (subscriber, #30848)
Posted Jan 9, 2011 13:55 UTC (Sun) by jrigg (subscriber, #30848)
Right now I'm working on a recording with over 30 separate tracks of 48kHz audio, most of which have separate instances of DSP working on them. This is a fairly moderate track count. I don't see normal desktop audio creating this level of system demand very often (if at all), but it's everyday stuff in recording.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds