Karol Krizka posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 21 Apr 2005 18:27:44 -0700:
> On 4/21/05, Daniel Gryniewicz <[EMAIL PROTECTED]> wrote: >> On Thu, 2005-04-21 at 18:02 -0700, Karol Krizka wrote: >> > When I play movies with totem (gstreamer or xine), mplayer, and gxine >> > the audio lags a bit behind the video. I am not sure what the problem >> > might be. I am using the latest esound server (I tried using >> > /etc/init.d/esound and esd) with the xv video driver. >> > >> I've never been able to get esd to play sound for videos at full speed >> (either x86 or amd64). Try switching totem/gstreamer to alsa, that >> fixed the problem for me. >> > I was thinking of something that would allow me to play several sounds > at once and dmix seems way too much work to set up. You don't seem to understand the way a software digital stream mixing system works. It must buffer the sound somewhat (tho not as much as it does), in ordered to get a coherent sample from both streams with enough data to properly mix them. On top of that is the much larger buffer necessary to guarantee smooth playback on a general purpose, not real-time processing guaranteed, system, when that processing is being done in software. With all the interrupts, locking, i/o latency, and other possible latency sources thrown into the mix, the software isn't guaranteed to get processing time again, to fill the buffer which is emptying at a fixed rate, for perhaps half a second or more (or at least that was the case when these sound daemons were designed). Thus, when the software /does/ get a chance to run, it must fill the buffer with at least a half-second worth of sound data, so that the buffer will never get empty before the software gets another chance to run. That's a half-second of latency! There are two modern ways to avoid the issue. One is to run a low-latency sound system such as JACK, on top of a kernel also designed to be low-latency. Of course, the tradeoffs in making the kernel low-latency also pretty much destroy any possibility of setting any throughput records, because that depends on not interrupting stuff for long enough to actually get some significant work done, which is the exact opposite of low latency -- interrupting stuff frequently, so all apps are guaranteed a certain amount of processing time within a specified period. Again, note the "general purpose" above. Specialized low-latency audio processing systems are NOT "general purpose" by definition, because they balance FAR too far toward the low-latency side which means many throughput intensive apps have a hard time accomplishing /any/ significant headway at all. However, such low-latency setups are available as options if you wish to use them. The other modern solution is hardware multi-stream mixing, as already mentioned. Cheap end is stuff like SoundBlaster Live! soundcards, but there are high end audio mixing cards costing several hundred $$ available as well. The true audio professional will of course be using /both/ solutions, low latency JACK and kernel, combined with professional level multi-stream hardware. For the rest of us, something like the Soundblaster Live! is an economical solution, coupled with direct to hardware-driver no sound daemon involved processing, where necessary. Other times, it won't be necessary, and ESD or ARTS sound daemons, with all their latency, are just fine. The thing is, you must either live with a bit of inconvenience on the one side or the other, or switch between them when necessary, for instance, by switching ESD/ARTS off and outputting directly to hardware sound driver (ALSA) from your video player of choice. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
