[linux-audio-dev] External audio interface (edirol FA/UA-101)
mista.tapas at gmx.net
Fri Sep 30 16:22:04 EDT 2005
On Fri, 30 Sep 2005 21:38:17 +0300
Jussi Laako <jussi.laako at pp.inet.fi> wrote:
> Hmmh, at least the documentation didn't state anything like that a while
> back (if I remember correctly). And at least my applications won't
> expect anything about the buffer size.
well, for an app that can handle any buffersize, this doesn't really
matter, as it, well, can handle any buffer size :)
> In fact when using sample rate converted ports (some of my experimental
> stuff) it may not be even same size for all callbacks. But hey, that's
> why there's period size argument passed to the callback, IMO.
Well, the nframes argument is really there for apps that don't need to
update any significant state upon buffer size changes and thus don't
have a buffersize_callback registered. They simply use what they get
from the nframes argument.
Nowadays the jack API garantees to clients that
a] the buffersize is a power of two
b] that the buffersize will not change inbetween two buffersize_callbacks.
I suppose your sample rate conversion stuff is violating the jack API
> Converting the buffer size on application side to some specific 2^x is
> anyway needed when doing FFT or similar.
Well, my jack_convolve simply uses what jack is providing (chopping up
the response in buffersized chunks so each block can be directly
processed without extra delay). jack_convolve relies on both a] and b]
from above (well it really ignores the possibilities of the buffer size
changing, so it really is broken, too, in a sense).
> There may be applications or hardware passing something other than 2^x
> buffers for example because it's some specific length in milliseconds,
Which really is a problem i think. I don't use any USB hw for example,
so i don't really know how this is solved in these cases.
More information about the linux-audio-dev