| |||||||||||||
RealtimeKit and the audio problemRealtimeKit and the audio problemPosted Jul 1, 2009 20:02 UTC (Wed) by ms (subscriber, #41272)In reply to: RealtimeKit and the audio problem by MisterIO Parent article: RealtimeKit and the audio problem
Sorry, but it's actually really common.
Get Jack running with RT priorities to an external USB soundcard (I'm using
(Log in to post comments)
RealtimeKit and the audio problem Posted Jul 1, 2009 20:12 UTC (Wed) by MisterIO (guest, #36192) [Link]
I may be wrong, but I guess in your case much of the problem lies in the fact that it's a usb soud-card. Just don't do an apt-get while listening to music. Yes, that's obviously not a solution, but why would you pretend to have perfect audio with an USB soundcard while doing heavy IO? For example, if you've got to burn a dvd with an external usb dvd+rw, is it a good idea to start doing heavy IO while burning the dvd? I guess not. Why is this any different?
RealtimeKit and the audio problem Posted Jul 1, 2009 20:24 UTC (Wed) by ms (subscriber, #41272) [Link]
If on your car, your windscreen wipers didn't work whilst your headlights
were on, is the solution to only use one or the other?
RealtimeKit and the audio problem Posted Jul 1, 2009 20:33 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
which is more important, getting the data on/off the disk fast (because you are working on something and the audio is just background music) or the audio (because you are playing a live concert and the disk I/O is just background logging)
as another poster mentioned, the definition of 'acceptable' is very poor.
larger buffers can solve most skipping problems (at the cost of added latency)
for audio-only playback, latency of a half second to a second could be acceptable (as long as you can silence the playback immediatly)
for video/audio playback significant latency is also acceptable, as long as you can know how much it is so that the video and audio can be delayed the same amount.
for recording, latency also isn't important
for live manipulation of sound (record sound, modify it, and play it back) latency is critical.
wipers Posted Jul 2, 2009 0:00 UTC (Thu) by xoddam (subscriber, #2322) [Link]
An uncle of mine once had a car whose wipers were powered from the engine's manifold vacuum -- they worked just fine when the car was idling, and would race across the screen when engine-braking downhill, but when powering up the other side in low gear they would just stop. Going uphill in a heavy downpour the driver actually had to lean out the window to see.
wipers Posted Jul 2, 2009 9:26 UTC (Thu) by nix (subscriber, #2304) [Link]
And that's *just* like esound.
Or perhaps arts.
:)
RealtimeKit and the audio problem Posted Jul 1, 2009 20:15 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
Just so that I can sound really naive - why is that? In the wonderful world of theory, disk I/O and audio I/O should be able to run in parallel, as long as the bus is wide enough for them both.
RealtimeKit and the audio problem Posted Jul 1, 2009 22:15 UTC (Wed) by macros (subscriber, #6699) [Link]
That assumes disk bandwidth is a static thing which it most definitely is not. For example, I have one disk array that will easily push 200MB/s for sequential reads, on a purely random workload that drops to 1MB/s.
RealtimeKit and the audio problem Posted Jul 2, 2009 0:05 UTC (Thu) by xoddam (subscriber, #2322) [Link]
It's a scheduler issue. An operating system built with such requirements in mind can do the job very well indeed -- but the CPU scheduler has to be designed with the scheduling constraints of the audio and video IO in mind. This is definitely not the case with Linux or most general-purpose operating systems: worse is better is bad for some workloads ;-)
For an example of an operating system that does it 'right', see http://lwn.net/Articles/270081/.
|
|||||||||||||