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 pr
>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 provid
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*
>con
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 o
>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
> >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.
>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 o
>> 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
[...]
> 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
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
>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 handl
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 bufferin
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
> 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
>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
cons
[...]
> 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 J
> > [...]
> > > > 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
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'
On Monday 24 February 2003 18.03, 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 thin
[...]
> > 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 del
reposting to the list, my email client had some hick-ups..
Paul Davis <[EMAIL PROTECTED]> wrote:
> if you mean at JACK's level, then it prints out information about
> xruns. i think you mean something else, but i'm not sure what.
OK, but jackd is accessing a DMA buffer - where wou
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.
>
>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 "expect
[...]
> 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) peri
>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 differen
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
26 matches
Mail list logo
