29 Sep
2005
29 Sep
'05
5:14 p.m.
Yes, the FA-101 works but I can't tell you the
numbers for latency.
The site has a nice table of working setups, but no user emails. I'd ask
them directly.
What do you mean with restristrions on buffers
(=latency?)?
AFAIK, usb cards impose 48kHz (96), 48/3 buffer setup to please
everybody in the chain.
Jackd needs buffers to be power of 2, and usb-audio - multiples of 1ms.
we consider the 192 kHz more as marketing gag :)
That's to compete with Fireface.
Hope that helps.
Thank you.
Dmitry.
29 Sep
29 Sep
7:55 p.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Thu, 2005-09-29 at 23:14 +0400, Dmitry S. Baikov wrote:
Jackd needs buffers to be power of 2, and usb-audio -
multiples of 1ms.
I don't think there is any hard limit in jack for buffer size to be 2^x.
(?)
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
8:02 p.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Thu, 2005-09-29 at 23:14 +0400, Dmitry S. Baikov wrote:
Jackd needs buffers to be power of 2, and usb-audio -
multiples of 1ms.
I just verified jack to work with any buffer size using OSS backend.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
8:34 p.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Fri, Sep 30, 2005 at 01:02:47AM +0300, Jussi Laako wrote:
On Thu, 2005-09-29 at 23:14 +0400, Dmitry S. Baikov
wrote:
Jack normally requires 2^n periods AFAIK. A good way to keep both jack
and USB happy often is to use 3 periods.
--
FA
Jackd needs buffers to be power of 2, and
usb-audio - multiples of 1ms.
I just verified jack to work with any buffer size using OSS backend. 
30 Sep
30 Sep
6:39 a.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Fri, 30 Sep 2005 01:02:47 +0300
Jussi Laako <jussi.laako(a)pp.inet.fi> wrote:
On Thu, 2005-09-29 at 23:14 +0400, Dmitry S. Baikov
wrote:
Hi,
i think the jack API garantees power of 2 size buffers to clients. So
while jack itself might work, some clients that depend on a power of 2
buffersize will fail horribly if something different is used.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Jackd needs buffers to be power of 2, and
usb-audio - multiples of 1ms.
I just verified jack to work with any buffer size using OSS backend.
4:38 p.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Fri, 2005-09-30 at 10:39 +0200, Florian Schmidt wrote:
i think the jack API garantees power of 2 size buffers
to clients. So
while jack itself might work, some clients that depend on a power of 2
buffersize will fail horribly if something different is used.
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.
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.
Converting the buffer size on application side to some specific 2^x is
anyway needed when doing FFT or similar.
There may be applications or hardware passing something other than 2^x
buffers for example because it's some specific length in milliseconds,
etc.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
6:22 p.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Fri, 30 Sep 2005 21:38:17 +0300
Jussi Laako <jussi.laako(a)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.
http://jackit.sourceforge.net/docs/reference/html/types_8h.html#a9
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.
http://jackit.sourceforge.net/docs/reference/html/types_8h.html#a13
I suppose your sample rate conversion stuff is violating the jack API
requirements.
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,
etc.
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.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
8:01 p.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
On Fri, 2005-09-30 at 22:22 +0200, Florian Schmidt wrote:
b] that the buffersize will not change inbetween two
buffersize_callbacks.
http://jackit.sourceforge.net/docs/reference/html/types_8h.html#a13
I suppose your sample rate conversion stuff is violating the jack API
requirements.
Could be, somewhat. Usually buffersize callback is used to allocate
buffers. My implementation guarantees that process callback is not
called with _more_ data between the buffersize callbacks. It can be one
sample less. It's just based on libsamplerate.
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).
My rtEq code for example just does .Put() to filter and .Get() from
filter. All the buffer vs processing size is hidden and non-relevant.
And in case of recursive multi rate filter it can be different on each
recursion anyway.
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.
In case of OSS backend, this can be handled by the driver. For multiple
samplerate case this is more complex.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
9:40 a.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
Dmitry S. Baikov wrote:
Pieter Palmers has done some latency measurements. He might have
some numbers for you.
cheers,
daniel
Yes, the
FA-101 works but I can't tell you the numbers for latency.
The site has a nice table of working setups, but no user emails. I'd
ask them directly.
3 Oct
3 Oct
10:09 a.m.
New subject: [linux-audio-dev] External audio interface (edirol FA/UA-101)
Daniel Wagner wrote:
Dmitry S. Baikov wrote:
Pieter Palmers has done some latency measurements. He might have
some numbers for you.
http://freebob.sourceforge.net/index.php/Some_emails_about_latency
To summarize:
the minimum round-trip latency I achieve with our current code is about
8ms, but there are some bugs that pop up at these low buffer sizes.
the minimal round-trip latency that gives rather reliable operation is
about 14ms.
note that I measure 'round-trip latency' by connecting a cable between
output and input of the soundcard and then look at the time difference
between the played sound and the recorded sound.
I'm working on a better driver structure/code that will allow lower
latencies.
Greets,
Pieter
Yes, the
FA-101 works but I can't tell you the numbers for latency.
The site has a nice table of working setups, but no user emails. I'd
ask them directly.
7050
days inactive
7054
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Daniel Wagner -
Dmitry S. Baikov -
Florian Schmidt -
fons adriaensen -
Jussi Laako -
Pieter Palmers