| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Dec 22, 2010 20:09 UTC (Wed) by jrigg (subscriber, #30848)In reply to: Realtime group scheduling doesn't know JACK by jimparis Parent article: Realtime group scheduling doesn't know JACK
>I'm trying to understand exactly what the audio use cases are that make processing 48 KHz data so difficult.
If you're processing a lot of tracks simultaneously the throughput can be quite high. In film soundtrack work it's not uncommon to be working with a hundred or more tracks at once.
(Log in to post comments)
Realtime group scheduling doesn't know JACK Posted Jan 6, 2011 19:38 UTC (Thu) by xorbe (subscriber, #3165) [Link]
Dude. Let's run the numbers on something crazy, like an 8 channel audio with insane bitrate and huge number of streams.
192000 samples/second * 8 movie channels * 4 bytes/sample * 128 streams / 1048576
That's a whole 750MB/s ... my desktop computer has 30GB/s dram bandwidth. For the highly more common 48K * 2 ch * 2 b/sample * 32 streams, the bandwidth is a pathetically small 6MB/s.
The fact that the Linux kernel can't natively handle mixing a few audio streams for the average desktop user without trotting out the anti-DoS argument is silly.
|
|||||||||||||