On Wed, 2001-12-05 at 19:12, Paul Davis wrote:
> this is somewhat like the kind of behaviour one sees on the
> trident. why are they not synchronized? well, in part because they
> designed the h/w to have *independent* playback and capture streams,
> which reflects typical consumer use. if you force the playback and
> capture streams to be totally synced, then you make the life of the
> programmer more difficult. "the programmer" here means one or both of
> the driver writer and the app programmer. notice how much work is
> necessary to share the hammerfall - there is only one h/w pointer
> which is moving whether the device is open for playback or capture or
> both. this is really nice for full duplex DAW-style operation, but
> really rather unpleasant if you wanted (say) 12 stereo devices that
> appear to be completely independent of each other when they are opened
> for playback or capture. remember: very few device driver APIs specify
> sample sync-ed full duplex. they just say you can move data in both
> directions "at the same time". they don't say "in 100% sample
> sync". thats partly why ASIO drivers don't exist for quite a lot of
> the h/w that is otherwise supported under windows and macos (well, its
> part of the reason, anyway).
>
> just ramblin', whats new ...
>
That makes sense. I'm assuming that it is possible to get manageable
full duplex with the SB Live though (meaning that the buffer pointers
wont overwrap each other). So this should be something that can be
corrected in ALSA. Or maybe there is something still wrong with the full
duplex test program. Anyways. Still dreaming of crisp and clear
low-latency full duplex with my SB Live.
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
