>IMHO the hardware should dictate the blocksize. For most audio >interfaces this will be constant. For some it is not.
the claim is that designs in which it is not constant are at least less than optimal and at worst, just stupid. >> Anyway, if you have several HW interfaces >> each using their own blocksize or interrupt frequency then this is the >> only sane option. > >This is another issue. JACK doesn't not support more than one device >nor should it. If an application wants to use more than one device the >extra buffering and possibly synchronisation is up the the application. actually, this is not the model at all. the model is that JACK doesn't interact with hardware, but with more abstract devices, such as those represented by ALSA PCM devices. if such a device maps to multiple audio interfaces, JACK doesn't care, but its up to alsa-lib to make this work, not JACK and not JACK clients. the same is true of any other app using the ALSA API: you do not need any extra code to deal with the specifics of what kind of "thing" an ALSA PCM device is: it could be a connection to a JACK server, to a network connection, to just the s/pdif ports of a multichannel interface, to 4 cards ganged together and clocked via word clock. the app just doesn't have to care. >> If this means an extra buffering layer, then so be it. That's the >> price you pay for sloppy HW design. > >I really don't think that hardware that doesn't provide a constant >number of samples per interrupt is sloppy HW design and I think the number of samples per second is constant (except for when changing rates or doing something truly wierd like word-clock driven varispeed). to keep CPU load even, one wants a constant number of interrupts per second. ergo, the number of samples per interrupt should be constant. look, the point is just this: USB was never designed to handle audio, let alone multichannel audio. its been stitched together, patched up and made to work, but it doesn't work very well. the CPU wants to process samples in chunks of the same size to equalize the load, otherwise you have a situation that is impossible to rely on (e.g. you are running close the CPU's available cycles at a given blocksize. suddenly you get a run of "small" blocks. boom!) now, obviously, if the variation is small (e.g. 1-4 samples) it may not matter so much, but its not clear that a design that allows variations of 1-4 samples can exclude the 1024-4096 case either. yes, you can move audio over USB. the question is not whether you can, but whether you should, and my feeling is that professional or semi-professional users should avoid it completely, regardless of what Yamaha, Tascam, Edirol and others who want to provide *cheap* connectivity to home studio users say in the advertisements. --p
