Em 15-06-2011 11:35, Hans de Goede escreveu: >>> This is a combination of the assumption there is a shared period size between >>> the input device and the output device + the broken error handling. >> >> The code is doing a negotiation, in order to find a period that are acceptable >> by both. Ok, there are other ways of doing it, but sharing the same period >> probably means less overhead. >> > > This is what we call a premature optimization, there is not all that much > overhead here, and demanding that both sizes will support a share period size > may not always fly, and may likely lead to unnecessary large period sizes > and thus too much latency in some cases. I didn't write that part of the code, although I fixed it to work with a device that provides audio at 32kHZ to play back on my audio card at 44.1kHz, using software interpolation for the frame rate. It came from Devin's tree, that, in turn, came from an alsa example (alsa-driver test tool latency.c, according with the source code) but, IMHO, the code should do: 1) try to find a common buffer size that are acceptable by both drivers, as using the same buffer size helps to avoid memcpy's, especially if mmap mode is enabled; 2) If the buffer size means that the latency will be more than a reasonable time interval [1], then fall back to use different periods; 3) inform the latency introduced by the audio driver, in order to allow xawtv to sync audio and video. (3) is not simple, because alsa doesn't provide a reliable timestamp, but it shouldn't be that hard to implement some logic that will at least compensate for the additional delay introduced by the buffer size. [1] Not sure what would be a reasonable delay. The original code were using a buffer of 600 bytes, meaning a delay of 600/4800 (12,5 ms). Maybe twice this value would still be reasonable. If we don't want to create a complicated sync processing for (3), the maximum upper limit is the video streaming DQBUF rate (about 166 ms, for an interlaced video at 30 fps). Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
