11 Jun
2004
11 Jun
'04
2:01 a.m.
Hi.
Does anyone out there know what the audio buffer size settings in
Windows and MacOS really mean? If you say "128 samples" does that
translate to 2 buffers of 128 samples --- one buffer playing, one buffer
filling --- or 2 buffers of 64 samples? Is it 256 samples of latency or
128?
I realize this isn't _exactly_ a Linux audio question, but perhaps
someone out there knows something about this. We're trying to get an
apples to apples comparison of our Linux/ALSA based system with a
Windows/MacOS system.
We set the ALSA driver to 2x128 and we get results that jibe more with
the 256 setting in Windows.
But when we hooked a Windows system up to a scope it looked more like
the 128 sample setting was running 2x64 samples. So... we're confused.
Any pearls of wisdom out there? ... mo
===================================
Michael Ost, Software Architect
Muse Research, Inc.
most(a)museresearch.com
12 Jun
12 Jun
6:09 p.m.
Well, no responses, no surprise... since this is a Windows/Mac issue.
But if you are curious, we scoped a win2k machine with a audiophile card
running vstack.
The latencies showed that the 128 sample setting matches an ALSA "semi
buffer". That is, a minimum of 256 samples of latency. This despite the
128-sample-like latency claims in the MAudio driver setup dialog.
Anyway, more info for the curious... mo
On Thu, 2004-06-10 at 20:52, Michael Ost wrote:
Hi.
Does anyone out there know what the audio buffer size settings in
Windows and MacOS really mean? If you say "128 samples" does that
translate to 2 buffers of 128 samples --- one buffer playing, one buffer
filling --- or 2 buffers of 64 samples? Is it 256 samples of latency or
128?
I realize this isn't _exactly_ a Linux audio question, but perhaps
someone out there knows something about this. We're trying to get an
apples to apples comparison of our Linux/ALSA based system with a
Windows/MacOS system.
We set the ALSA driver to 2x128 and we get results that jibe more with
the 256 setting in Windows.
But when we hooked a Windows system up to a scope it looked more like
the 128 sample setting was running 2x64 samples. So... we're confused.
Any pearls of wisdom out there? ... mo
===================================
Michael Ost, Software Architect
Muse Research, Inc.
most(a)museresearch.com
10:03 p.m.
Michael Ost wrote:
Well, no responses, no surprise... since this is a
Windows/Mac issue.
But if you are curious, we scoped a win2k machine with a audiophile card
running vstack.
The latencies showed that the 128 sample setting matches an ALSA "semi
buffer". That is, a minimum of 256 samples of latency. This despite the
128-sample-like latency claims in the MAudio driver setup dialog.
Yeah, these vague latency settings on windows apps/drivers are quite
disturbing and confusing.
Even the german keyboards magazine (whose editors and reviewers are
supposed to be experts in audio)
get it wrong each time.
They happily run their RME cards at 1.5msec latency while in reaility
those cards can go as low
(in 44kHz mode) a 3msec ( 2 x 1.5msec buffers).
But it's a bit fault of RME too which never specifies if the latency is
per fragment or total (it's per buffer).
Same can be said for most audio sequencers on windows/mac, and from what
I understand most of the times
these numbers mean per-fragment latency. (so multiply with 2 or 3 to get
the real midi-to-output (or PCM input-to-output) latency.
As said low latencies are cool so everyone tries to cheat and provide
the per-fragment latencies in their settings/specs.
Btw what did you mean with
"We set the ALSA driver to 2x128 and we get results that jibe more with
the 256 setting in Windows."
english is my 4th language and dictionary.com was not of too much help
----
jibe:
To make taunting, heckling, or jeering remarks.
To deride with taunting remarks.
---
So let me guess: you meant that 2x128 in ALSA provides lower latency
than Windows at 256frames ?
cheers,
Benno
http://www.linuxsampler.org
Anyway, more info for the curious... mo
On Thu, 2004-06-10 at 20:52, Michael Ost wrote:
Hi.
Does anyone out there know what the audio buffer size settings in
Windows and MacOS really mean? If you say "128 samples" does that
translate to 2 buffers of 128 samples --- one buffer playing, one buffer
filling --- or 2 buffers of 64 samples? Is it 256 samples of latency or
128?
I realize this isn't _exactly_ a Linux audio question, but perhaps
someone out there knows something about this. We're trying to get an
apples to apples comparison of our Linux/ALSA based system with a
Windows/MacOS system.
We set the ALSA driver to 2x128 and we get results that jibe more with
the 256 setting in Windows.
But when we hooked a Windows system up to a scope it looked more like
the 128 sample setting was running 2x64 samples. So... we're confused.
Any pearls of wisdom out there? ... mo
===================================
Michael Ost, Software Architect
Muse Research, Inc.
most(a)museresearch.com
11:47 p.m.
On Sat, 2004-06-12 at 17:01, Benno Senoner wrote:
As said low latencies are cool so everyone tries to
cheat and provide
the per-fragment latencies in their settings/specs.
The MAudio driver setup card was downright dishonest. It said "latency:
128 samples", when actually latency was 256... that should have been
labeled "buffer size" to be more honest.
It then said that 128 samples you will get 2 msec latency at 44.1.
That's 2 msec rounded _down_ from 2.9! And real end-to-end latency
couldn't be any less than 5.8 msecs anyway. We were aghast. It's no
wonder everyone is confused!
Given the MAudio settings, and from asking some people at Apple, we are
now confident that a 128 sample buffer size setting in Windows/Mac
matches up with 2 128 sample fragments in ALSA... I think that's the
ALSA terminology; I didn't work on that bit of code so I'm not sure.
Btw what did you mean with
"We set the ALSA driver to 2x128 and we get results that jibe more with
the 256 setting in Windows."
english is my 4th language and dictionary.com was not of too much help
----
jibe:
To make taunting, heckling, or jeering remarks.
To deride with taunting remarks.
---
'Jibe with' can also mean 'in alignment with'. You seem to do pretty
well with English! That's not a usual usage.
So let me guess: you meant that 2x128 in ALSA provides
lower latency
than Windows at 256frames ?
I meant that setting the ALSA driver to two 128 sample fragments matches
the real measured latency for the 256 sample setting in Windows.
- mo
13 Jun
13 Jun
12:10 a.m.
The MAudio driver setup card was downright dishonest.
It said "latency:
128 samples", when actually latency was 256... that should have been
labeled "buffer size" to be more honest.
michael - windows and linux use the term "buffer" in different
ways. on windows, it generally means "the chunk of memory
corresponding to the period between h/w interrupts from the device"
(called a "period" in ALSA and a "fragment" in OSS). in ALSA, a
"buffer" is the entire hardware buffer which is divided into smaller
pieces (called "periods"). windows seems to have no real term for this
chunk of memory.
interestingly, the design of ASIO only allows 2 interrupts per
hardware buffer. ALSA is much more flexible in handling this kind of
thing.
--p
9:28 a.m.
[...]
interestingly, the design of ASIO only allows 2
interrupts per
hardware buffer. ALSA is much more flexible in handling this kind of
thing.
A huge mistake of ASIO IMHO. On the Audiowerk8 for example,
running 3 interrupts per buffer allows using the input DMA interrupt
only; this interrupt will always occur after the output DMA interrupt
because of buffering. When using only two interrupts per buffer
one would have to wait for the input interrupt also, but be finished
before the output interrupt, hurting performance. The complexity of
the driver also goes up. Due to interrupt latency, very small xruns
are impossible to detect with only two interrupts.
So for this kind of hardware (buffer in host memory, small DMA
FIFOs), I'd always use three interrupts per buffer, and thus
ASIO sucks :)
--ms
7408
days inactive
7410
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Benno Senoner -
Martijn Sipkema -
Michael Ost -
Paul Davis