Patrick Shirkey wrote:
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*
Patrick Shirkey wrote:
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*
On Thu, Feb 27, 2003 at 07:03:07 -0500, Paul Davis wrote:
you need to understand that this state of affairs is caused by
misleading advertising and marketing. firewire cards cost $50 and can
Actually, in europe at least firewire cards are $20. The abundance of DV
camcorders has pushed the
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
On Thu, 27 Feb 2003, Patrick Shirkey wrote:
But it would be very nice if I could use my usb quattro to manipulate
the sounds of my bandmates in realtime at lowlatency. I tried with ssm
at 64 bytes and there was noticible lag so we couldn't do anything live.
[...]
The best I can get out of
Paul Davis writes:
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
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
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
[...]
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
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.
Acutally, I'm afraid that you can't do that currently.
Taybin
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.
Well, I disagree. I don't think it is a stupid design.
[...]
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.
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
On Mon, Feb 24, 2003 at 04:54:56PM +0100, Martijn Sipkema wrote:
[...]
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
[...]
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
On Mon, Feb 24, 2003 at 06:03:58 +0100, Martijn Sipkema wrote:
[...]
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
[...]
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
[...]
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
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
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.
For what its worth, the SAOL standard has to deal with this
On Mon, Feb 24, 2003 at 07:49:43 +0100, Martijn Sipkema wrote:
[...]
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
21 matches
Mail list logo
