24 Feb
2003
24 Feb
'03
10:45 a.m.
Hi all!
First post to this list for me..
I have observed a strange thing with my jackd + BruteFIR setup, it looks something like
this:
HW: Emagic 2|6 USB thing (hw0), directly connected to a USB port, no hubs.. This runs with
both inputs and outputs in analog mode for now to rule out any kind of sample rate/clock
rate mismatches digital mode can introduce.
Kernel 2.4.19-1LL (running Planet CCRMA software here with lowlatency enabled in the
kernel) - have tried this on both a RedHat 7.3 and RedHat 8.0 system.
jackd -R -d alsa -d hw:0 -r 44100 -p 2048
BruteFIR running at 44100Hz with a filter size of 2048,8
This gives me a faint crackling noise in the output (sounds like latency issues, but
nothing gets logged anywhere).. The symptom is the same for 48kHz, and to make sure
that's it not really anything directly hardware related I can start jack up and
instead of connecting BruteFIR I can connect AlsaPlayer and play MP3's or whatever
just fine (!)...
That's not the most interesting part though - the crackling disappears if I choose a
filter size of 4096,4 (or 8) instead, with the same period size for jack - that really
shouldn't make any difference, should it??
Anyone else that have seen/heard this problem, or is it just me? :)
It seems that my 2|6 likes period sizes of 44100/1000 or 48000/1000 much better than the
BruteFIR-enforced 2^something sizes though - I can't reliably play anything using a
period size of 1024, but one of 820 is fine @ 44100Hz rate (?)
What other information would be relevant here?
/WernerJ
24 Feb
24 Feb
11:28 a.m.
It seems that my 2|6 likes period sizes of 44100/1000
or 48000/1000 much bette
r than the BruteFIR-enforced 2^something sizes though - I can't reliably play
anything using a period size of 1024, but one of 820 is fine @ 44100Hz rate (?
many USB audio interfaces work in a fundamentally different way than
other audio interfaces. rather than sending an "interrupt" to the host
after processing 2^N frames, they send an interrupt every N
msecs.
choosing period sizes for JACK (or for any application, for that
matter) is important here, because otherwise you have a wierd
buffering system, where JACK processes part of the available data on
one "cycle" and then the remainder, plus some of the following, on the
next. although it was written with the intention of handling this
correctly, it may not, and the best advice for now is to pick a period
size that reflects a multiple of a 1msec interrupt rate. for example,
at 48kHz, 1 msec = 48 frames, so a nice number would by 480 frames, or
960 frames, etc.
fernando and others will correct what i've got wrong here.
in closing, let me say that the fact that there are lots of USB audio
interfaces appearing shouldn't fool anyone into thinking that these
are suitable for professional audio work. the basic design of USB is
terrible for this stuff, and i would personally avoid USB audio
interfaces like the plague. the old joke "eat shit - 600 billion
flies can't be wrong" seems very to much to apply here, IMHO.
--p
12:02 p.m.
[...]
many USB audio interfaces work in a fundamentally
different way than
other audio interfaces. rather than sending an "interrupt" to the host
after processing 2^N frames, they send an interrupt every N
msecs.
And JACK doesn't support this because it needs a constant size
(frames) period. IMHO the audio interface should dictate the period
size and it need not be constant.
Perhaps you would reconsider having JACK use constant (frames)
callbacks?
[...]
in closing, let me say that the fact that there are
lots of USB audio
interfaces appearing shouldn't fool anyone into thinking that these
are suitable for professional audio work. the basic design of USB is
terrible for this stuff, and i would personally avoid USB audio
interfaces like the plague.
For good performance the period should be constant, but it doesn't
really matter if it is contant frames of constant time with a possible
very small difference in frames. USB may have more problems, I
don't know really, but the period size is not really a big problem, or
at least it shouldn't be.
the old joke "eat shit - 600 billion
flies can't be wrong" seems very to much to apply here, IMHO.
You are probably right. This is also the case, or perhaps even more
so with (the standard) USB over MIDI.
--ms
12:11 p.m.
Perhaps you would reconsider having JACK use constant
(frames)
callbacks?
we debated the concept of non-constant callback sizes on jackit-dev,
and there seemed to be strong support for using a constant value.
this doesn't necessarily preclude process() being called with *less*
than the "expected" size, but the current API docs/notes say that its
always constant size.
i don't know what people's thoughts are on "constant or less than the
constant" for the callback. i imagine it will push complexity out into
any clients that do FFT and other similar transforms.
--p
12:27 p.m.
On Mon, Feb 24, 2003 at 04:54:56PM +0100, Martijn Sipkema wrote:
[...]
I think a better solution might be to buffer up enough samples so that
jackd can provide a constant number of frames.
- Steve
many USB audio interfaces work in a fundamentally
different way than
other audio interfaces. rather than sending an "interrupt" to the host
after processing 2^N frames, they send an interrupt every N
msecs.
And JACK doesn't support this because it needs a constant size
(frames) period. IMHO the audio interface should dictate the period
size and it need not be constant.
Perhaps you would reconsider having JACK use constant (frames)
callbacks?
1:11 p.m.
[...]
I don't think that is a better solution. JACK should be close to the
hardware and deliver what the hardware is capable of. If a client needs
constant (frames) period, it can do the buffering itself.
The buffering adds latency and complexity. I thought the idea of the
callback based API was that the client has to process the data
available when it is available. For some hardware this might be
constant and for other it is not. As long as the time to process is
roughly the same as the time the callback represents high cpu load
should be possible.
I'm not convinced that because of easier block processing in the
clients support for common hardware should suffer.
--ms
Perhaps you
would reconsider having JACK use constant (frames)
callbacks?
I think a better solution might be to buffer up enough samples so that
jackd can provide a constant number of frames. 
1:33 p.m.
On Monday 24 February 2003 18.03, Martijn Sipkema wrote:
[...]
I don't think that is a better solution. JACK should be close to the
hardware and deliver what the hardware is capable of. If a client
needs constant (frames) period, it can do the buffering itself.
The buffering adds latency and complexity. I thought the idea of the
callback based API was that the client has to process the data
available when it is available. For some hardware this might be
constant and for other it is not. As long as the time to process is
roughly the same as the time the callback represents high cpu load
should be possible.
I'm not convinced that because of easier block processing in the
clients support for common hardware should suffer.
Either you hide complexity in the API (that is JACK) or you give it to
the applications. I think it is unwise to make it harder for the
applications. There will be lots of reimplementation in all
applications to handle the same set of problems you get when the period
size can change. Any many will not care to implement to handle the
special cases, and thus not work properly on all JACK compatible
hardware.
Instead I would suggest a built in poll mode in JACK for audio hardware
with strange period sizes. Although not the most beautiful solution, it
will work reliably and will only be needed for the type of hardware
that cannot provide interrupt rates which is a power of two.
/Anders Torger
Perhaps
you would reconsider having JACK use constant (frames)
callbacks?
I think a better solution might be to buffer up enough samples so
that jackd can provide a constant number of frames.
3:21 p.m.
[...]
Instead I would suggest a built in poll mode in JACK
for audio hardware
with strange period sizes. Although not the most beautiful solution, it
will work reliably and will only be needed for the type of hardware
that cannot provide interrupt rates which is a power of two.
I'm not a JACK developer so my opinion may not really count here, but
I really think it would be a bad decision to criplle support for all
hardware
that is not able to provide constant size power of two (frames) periods.
And it surely wouldn't be bad for clients not to rely a a particular size
callback. I don't know how CoreAudio handles this. I'm sure EASI did
not have constant size callbacks and VST does not either IIRC. (ASIO
probably does, but ASIO also forces double buffering (I think)...).
--ms
3:40 p.m.
I'm not a JACK developer so my opinion may not
really count here, but
I really think it would be a bad decision to criplle support for all
hardware that is not able to provide constant size power of two
(frames) periods.
we don't care about non-power-of-two periods, i think. however, i do
consider periods defined in units of times and not frames to be broken
hardware design. it forces inefficiencies into the software that are
totally unnecessary.
And it surely wouldn't be bad for clients not to
rely a a particular size
callback. I don't know how CoreAudio handles this. I'm sure EASI did
not have constant size callbacks and VST does not either IIRC. (ASIO
probably does, but ASIO also forces double buffering (I think)...).
until recently, JACK provided support for variable numbers of frames
in the process() callback. it was removed because no developer was in
support of it, and because JACK itself had no use for it.
i am quite open to re-examining the issue. however, i don't want
inefficient software designs to be forced on us by the stupid use of
USB to handle audio. i've had enough of bad hardware designs messing
up software, and it won't happen here. if it can be done sensibly, we
can do it.
--p
25 Feb
25 Feb
11:15 a.m.
Paul Davis writes:
I'm a newbie to LAD, but I have some years of experience of developing
and using a system similar to JACK for routing blocks of samples to
DSP modules of a digital satellite control receiver and transmitter
system running on Solaris (we are talking about some megasamples per
second here).
IMHO, the only sensible way for a system like JACK to operate is by
using a constant blocksize. Anyway, if you have several HW interfaces
each using their own blocksize or interrupt frequency then this is the
only sane option.
If this means an extra buffering layer, then so be it. That's the
price you pay for sloppy HW design.
Just my 0.02 EUR.
BTW, can JACK handle several HW interface using different blocksizes
at a time (assuming sample frequencies are coherent) ?
--
Fons Adriaensen
ALCATEL SPACE
And it surely
wouldn't be bad for clients not to rely a a particular size
callback. I don't know how CoreAudio handles this. I'm sure EASI did
not have constant size callbacks and VST does not either IIRC. (ASIO
probably does, but ASIO also forces double buffering (I think)...).
until recently, JACK provided support for variable numbers of frames
in the process() callback. it was removed because no developer was in
support of it, and because JACK itself had no use for it.
i am quite open to re-examining the issue. however, i don't want
inefficient software designs to be forced on us by the stupid use of
USB to handle audio. i've had enough of bad hardware designs messing
up software, and it won't happen here. if it can be done sensibly, we
can do it.
11:47 a.m.
BTW, can JACK handle several HW interface using
different blocksizes
at a time (assuming sample frequencies are coherent) ?
multiple devices: we leave that to ALSA. we just open one ALSA PCM
device, which may or may not correspond to a hardware
audio interface. ALSA can handle a variety of these
situations, but AFAIK, it does not handle sample clock
drift and related issues.
different blocksizes: hard to even define, really, but pretty much
beside the point given that multiple devices are handled
by ALSA.
--p
11:58 a.m.
On Tue, Feb 25, 2003 at 04:07:33 +0100, Fons Adriaensen wrote:
BTW, can JACK handle several HW interface using
different blocksizes
at a time (assuming sample frequencies are coherent) ?
Not directly, but I believe that ALSA can. To work it would require that
the cards were in sample sync (is this what you mean by 'coherent'?), eg.
using a word clock connection.
- Steve
12:18 p.m.
[...]
I'm a newbie to LAD, but I have some years of
experience of developing
and using a system similar to JACK for routing blocks of samples to
DSP modules of a digital satellite control receiver and transmitter
system running on Solaris (we are talking about some megasamples per
second here).
IMHO, the only sensible way for a system like JACK to operate is by
using a constant blocksize.
IMHO the hardware should dictate the blocksize. For most audio
interfaces this will be constant. For some it is not.
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.
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 audio framework and applications should handle this without
adding unnecessary buffering.
BTW, can JACK handle several HW interface using
different blocksizes
at a time (assuming sample frequencies are coherent) ?
No, but you could run several instances of JACK.
--ms
1:38 p.m.
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. 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
4:02 p.m.
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. 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 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.
I'm not advocating USB audio. (I'd rather see Firewire being used for
audio more.) And you are correct in saying that the variation in frames
per callback needs to be small. But there are audio interfaces that
do exactly that: they provide nearly constant frames per callback.
And I don't see any reason why JACK should not properly support
such hardware.
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.
And thus JACK will not support USB audio devices properly? And
perhaps other hardware that is 'broken'? I think this is a mistake.
And also, I think it would be good algorithm design to make it
independent of the number of frames per callback/process.
--ms
24 Feb
24 Feb
2:31 p.m.
On Mon, Feb 24, 2003 at 06:03:58 +0100, Martijn Sipkema wrote:
[...]
I don't think that is a better solution. JACK should be close to the
hardware and deliver what the hardware is capable of. If a client needs
constant (frames) period, it can do the buffering itself.
Not without making the cpu load unpredictable.
I think its a bad idea to life hard for (some) clients because of a few
bad hardware designs.
- Steve
Perhaps
you would reconsider having JACK use constant (frames)
callbacks?
I think a better solution might be to buffer up enough samples so that
jackd can provide a constant number of frames.
2:57 p.m.
[...]
I don't think that is a better solution. JACK should be close to the
hardware and deliver what the hardware is capable of. If a client needs
constant (frames) period, it can do the buffering itself.
Not without making the cpu load unpredictable. Perhaps
you would reconsider having JACK use constant (frames)
callbacks?
I think a better solution might be to buffer up enough samples so that
jackd can provide a constant number of frames. I think its a bad idea to life hard for (some) clients
because of a few
bad hardware designs.
Hardly a few. And not even necessarily bad.
--ms
6:47 p.m.
On Mon, Feb 24, 2003 at 07:49:43 +0100, Martijn Sipkema wrote:
Is that so? And why is it that JACK can and a client cannot?
Because the client can segment correctly give power-of-two buffers.
It is a slightly crazy design. Just doesn't fit well with the way PCs work.
- Steve
[...]
Not without making the cpu load unpredictable. > Perhaps you would reconsider having JACK use
constant (frames)
> callbacks?
I think a better solution might be to buffer up enough samples so that
jackd can provide a constant number of frames.
I don't think that is a better solution. JACK should be close to the
hardware and deliver what the hardware is capable of. If a client needs
constant (frames) period, it can do the buffering itself. I think its a
bad idea to life hard for (some) clients because of a few
bad hardware designs.
Hardly a few. And not even necessarily bad.
7934
days inactive
7935
days old
linux-audio-dev@lists.linuxaudio.org
17 comments
6 participants
participants (6)
-
Anders Torger -
Fons Adriaensen -
Martijn Sipkema -
Paul Davis -
Steve Harris -
Werner Johansson