>From a recent thread I learned that my RME DIGI96 only allows period sizes of 2048 or 8192 bytes. No other choices, due to hardware design. So what if the applications asks for 256 bytes? If the applications insists on that, it won't run. If it asks for "near", it'll get not what it expects, but at least something that works.
I tried to run the ardour-package that Takashi Iwai provides on ftp://ftp.suse.com/pub/people/tiwai/alsa9-packages/7.3-src/ but it seems that exactly due to this it won't run. Too bad, ardour look very very promising on the web-pages! It should be possible to run applications with periods of 2048 bytes, shouldn't it? Well, latency would be bad, but for plain recording it should be ok, right? Wolfgang ----- Original Message ----- From: "Paul Davis" <[EMAIL PROTECTED]> To: "Jaroslav Kysela" <[EMAIL PROTECTED]> Cc: "Abramo Bagnara" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, November 28, 2001 6:08 PM Subject: Re: [Alsa-devel] more on that return from poll(2) issue > >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. > > _______________________________________________ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
