>> true, except that we enforce this requirement at a different >> level. you can't get a synchronous engine to run correctly if the >> capture and playback streams are not usable in the same basic way. >> >> or can you? > >Yes, you can find the nearest transfer count for both streams.
Sure, that would work but its not of much interest to me right now. Thats really just telling a user "you asked for N frames per cycle, but we can only do 3*N, just to let you know". That may be completely wrong. The model in a synchronous system is that you specify the number of frames per cycle, and that number is honored. choosing a value thats not supported by both streams is obviously a mistake. if a user asks for N, but one of the streams can't support it, its arguably better to tell what will work, and let them try again. >> a similar issue arises with devices like the sbawe, which also >> cannot be used because the code requires that both streams be >> configurable with the same data format (the sbawe can't do this) > >But the alsa-lib can. well, JACK could too. it would be a small detail to add this to the code, probably no more than half and hour. its just not of much interest to anyone involved in it right now. its a hack to support broken h/w, and you all know how i feel about that :) --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
