20 Mar
2011
20 Mar
'11
6:26 p.m.
Hi,
I am thinking about a possible design for the second version of the
position sensing drum pad I have been working on, and I have a question
about latency. I am working around the assumption that 10ms latency is
about the worst it can get before people start to notice it in practice,
so I am thinking of building the pad in a way where the normal latency
is about 1ms, but it degrades to between 10-15 ms in the very worst case
(many simultaneous strikes and pressure variations across the pad).
Allowing this level of degradation would make it possible (I think) to
use an arduino rather than a faster processor, which would be nice.
So the question is, where does this 10ms figure come from, and is it a
reasonable working value? I have picked it up somewhere but I'm not
exactly sure where.
Thanks for any replies.
andy
20 Mar
20 Mar
6:42 p.m.
On Sunday, March 20, 2011 12:25:52 pm andy baxter wrote:
So the question is, where does this 10ms figure come
from, and is it a reasonable working value? I have
picked it up somewhere but I'm not exactly sure where.
In preparing a session proposal for the upcoming MeeGo
conference, I found this:
http://www.jboley.com/research/AES_Latency.pdf
There may be better research papers out there... but it
seems to match up with reality.
-gabriel
6:55 p.m.
On Sun, Mar 20, 2011 at 1:25 PM, andy baxter
<andy(a)earthsong.free-online.co.uk> wrote:
Hi,
I am thinking about a possible design for the second version of the position
sensing drum pad I have been working on, and I have a question about
latency. I am working around the assumption that 10ms latency is about the
worst it can get before people start to notice it in practice, so I am
thinking of building the pad in a way where the normal latency is about 1ms,
but it degrades to between 10-15 ms in the very worst case (many
simultaneous strikes and pressure variations across the pad). Allowing this
level of degradation would make it possible (I think) to use an arduino
rather than a faster processor, which would be nice.
So the question is, where does this 10ms figure come from, and is it a
reasonable working value? I have picked it up somewhere but I'm not exactly
sure where.
what you're discussing is not only about latency. i respectfully ask
that you read this blog post and then follow the links to the original
paper:
http://createdigitalmusic.com/2008/12/intimate-control-multi-touch-new-mode…
if your pad is only a trigger, its not so relevant, but if its
providing more than just a trigger then randy's ideas are really
important, i think.
7:52 p.m.
On 20/03/11 17:55, Paul Davis wrote:
what you're discussing is not only about latency.
i respectfully ask
that you read this blog post and then follow the links to the original
paper:
http://createdigitalmusic.com/2008/12/intimate-control-multi-touch-new-mode…
if your pad is only a trigger, its not so relevant, but if its
providing more than just a trigger then randy's ideas are really
important, i think.
Yes, I agree. The design I'm thinking of is heavily based on his ideas.
I've looked at his design, and it looks way ahead of what I managed to
do with my first drum pad prototype.
The only thing I found problematic in his design wasn't to do with
usability but the expense (and also physical bulk) of having to use a
high end audio interface as part of the electronics. This put me off
building one myself, so I am thinking of having a go at a very similar
design but using a resistive rather than capacitive pressure sensing
technique. I.e. basically the same design but using a sheet of carbon or
metal loaded conductive rubber and measuring the resistance changes when
you scan through the matrix. If this works, it will hopefully produce
similar results but with much simpler electronics and firmware.
andy
8:11 p.m.
On Sun, 20 Mar 2011 18:52:24 +0000
andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
<snip>
The only thing I found problematic in his design
wasn't to do with
usability but the expense (and also physical bulk) of having to use a
high end audio interface as part of the electronics. This put me off
building one myself, so I am thinking of having a go at a very similar
design but using a resistive rather than capacitive pressure sensing
technique. I.e. basically the same design but using a sheet of carbon or
metal loaded conductive rubber and measuring the resistance changes when
you scan through the matrix. If this works, it will hopefully produce
similar results but with much simpler electronics and firmware.
andy
This is vastly overcomplicated. Once you understand the concept itself (which
really is good), a set of dedicated oscillators and detectors (tuned
amplifiers+A/D converters) would by much simpler, smaller and reliable. I would
then be inclined to try to embed the electronics in the device itself, and bump
up the operating frequency as much a possible to improve the response time of
the detectors.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
8:33 p.m.
On Sun, 20 Mar 2011 19:11:07 +0000
Folderol <folderol(a)ukfsn.org> wrote:
On Sun, 20 Mar 2011 18:52:24 +0000
andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
<snip>
Answering my own post...
I mean the original concept using the audio interface is overcomplicated. The
resistive idea has the merit of dramatic simplification but I wonder at the
consistency of the resistive elements and whether you would get a (reasonably)
linear output of if it would tend to behave more like a low quality switch.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
The only thing I found problematic in his design
wasn't to do with
usability but the expense (and also physical bulk) of having to use a
high end audio interface as part of the electronics. This put me off
building one myself, so I am thinking of having a go at a very similar
design but using a resistive rather than capacitive pressure sensing
technique. I.e. basically the same design but using a sheet of carbon or
metal loaded conductive rubber and measuring the resistance changes when
you scan through the matrix. If this works, it will hopefully produce
similar results but with much simpler electronics and firmware.
andy
This is vastly overcomplicated. Once you understand the concept itself (which
really is good), a set of dedicated oscillators and detectors (tuned
amplifiers+A/D converters) would by much simpler, smaller and reliable. I would
then be inclined to try to embed the electronics in the device itself, and bump
up the operating frequency as much a possible to improve the response time of
the detectors.
8:47 p.m.
On 20/03/11 19:33, Folderol wrote:
Answering my own post...
I mean the original concept using the audio interface is overcomplicated. The
resistive idea has the merit of dramatic simplification but I wonder at the
consistency of the resistive elements and whether you would get a (reasonably)
linear output of if it would tend to behave more like a low quality switch.
OK, I misunderstood at first, as I guess you thought I might have done.
Yes I'm thinking that could be a problem, but it's worth finding out.
Most of the conductive rubber that is sold is intended for electrostatic
shielding, so linearity and consistency probably aren't a priority in
manufacturing. I'm currently sending emails to manufacturers to see if
they can send me some samples.
andy
9:04 p.m.
On 20/03/11 19:47, andy baxter wrote:
On 20/03/11 19:33, Folderol wrote:
I.e.
thanks for explaining what you meant.
Answering my own post...
I mean the original concept using the audio interface is
overcomplicated. The
resistive idea has the merit of dramatic simplification but I wonder
at the
consistency of the resistive elements and whether you would get a
(reasonably)
linear output of if it would tend to behave more like a low quality
switch.
OK, I misunderstood at first, as I guess you thought I might have done. 
7:38 p.m.
On 03/20/2011 06:25 PM, andy baxter wrote:
Hi,
I am thinking about a possible design for the second version of the
position sensing drum pad I have been working on, and I have a question
about latency. I am working around the assumption that 10ms latency is
about the worst it can get before people start to notice it in practice,
so I am thinking of building the pad in a way where the normal latency
is about 1ms, but it degrades to between 10-15 ms in the very worst case
(many simultaneous strikes and pressure variations across the pad).
Allowing this level of degradation would make it possible (I think) to
use an arduino rather than a faster processor, which would be nice.
a drummer will get very grumpy indeed over latencies in the 10ms range.
(i understand your use of the term to mean "time it takes for the sound
to come out after the drummer has hit the pad").
you should aim for 2ms or less, which takes considerable effort and a
very good sound card.
but if you can't do that, then by all means keep the latency constant.
shifting latency will make the the drummer eat his sticks, or worse yet,
direct random acts of violence against other people, possibly even you.
just imagine you are playing a constant 16th note pattern at 120 bpm.
one beat will be 0.125 seconds.
say your second beat is delayed by 10ms ue to jittery time, and the next
one is dead on again. the groove will appear to "swing" in weird ways.
real swing would mean 0.167s, then 0.083s, so that's considerably more,
but to keep a groove going, the drummer has to keep such times very
accurately, and 10ms is a major earthquake to a flowing groove,
especially since the drummer's physical feel and the acoustic result do
not match when your software jitters.
even when the following beats are all delayed by 10ms because your
application scheduler has now entered its high-load steady state, the
drummer will hear a drag, try to speed up to compensate, and oscillate
around the correct time for a number of beats. this ruins the feel and i
could imagine it could even cause physical harm due to dysfunctional use
of muscles.
but even when the latency is constant, drummers are used to get very
sharp and distinct physical feedback when the stick rebounds from the
drum head, and they are very close to the instrument. so they will
usually be a lot less tolerant than electric guitarists (who are used to
operate at 3 or 4 m distance from their amps or monitor speakers) or
(extreme example) church organists, who can learn to deal with tens or
even hundreds of milliseconds of latency (plus a dragging congregation
choir on top) :-D
7:52 p.m.
On Sunday, March 20, 2011 01:38:08 pm Jörn Nettingsmeier
wrote:
you should aim for 2ms or less, which takes
considerable
effort and a very good sound card.
FWIW, in an acoustic setup... 2 ms is about the amount of
time for the sound waves to travel from the drum to the
drummer's ears.
-gabriel
7:56 p.m.
On 20/03/11 18:38, Jörn Nettingsmeier wrote:
On 03/20/2011 06:25 PM, andy baxter wrote:
Yes that's what I meant.
Hi,
I am thinking about a possible design for the second version of the
position sensing drum pad I have been working on, and I have a question
about latency. I am working around the assumption that 10ms latency is
about the worst it can get before people start to notice it in practice,
so I am thinking of building the pad in a way where the normal latency
is about 1ms, but it degrades to between 10-15 ms in the very worst case
(many simultaneous strikes and pressure variations across the pad).
Allowing this level of degradation would make it possible (I think) to
use an arduino rather than a faster processor, which would be nice.
a drummer will get very grumpy indeed over latencies in the 10ms
range. (i understand your use of the term to mean "time it takes for
the sound to come out after the drummer has hit the pad").
you should aim for 2ms or less, which takes
considerable effort and a
very good sound card.
but if you can't do that, then by all means keep the latency constant.
shifting latency will make the the drummer eat his sticks, or worse
yet, direct random acts of violence against other people, possibly
even you.
just imagine you are playing a constant 16th note pattern at 120 bpm.
one beat will be 0.125 seconds.
say your second beat is delayed by 10ms ue to jittery time, and the
next one is dead on again. the groove will appear to "swing" in weird
ways. real swing would mean 0.167s, then 0.083s, so that's
considerably more, but to keep a groove going, the drummer has to keep
such times very accurately, and 10ms is a major earthquake to a
flowing groove, especially since the drummer's physical feel and the
acoustic result do not match when your software jitters.
even when the following beats are all delayed by 10ms because your
application scheduler has now entered its high-load steady state, the
drummer will hear a drag, try to speed up to compensate, and oscillate
around the correct time for a number of beats. this ruins the feel and
i could imagine it could even cause physical harm due to dysfunctional
use of muscles.
but even when the latency is constant, drummers are used to get very
sharp and distinct physical feedback when the stick rebounds from the
drum head, and they are very close to the instrument. so they will
usually be a lot less tolerant than electric guitarists (who are used
to operate at 3 or 4 m distance from their amps or monitor speakers)
or (extreme example) church organists, who can learn to deal with tens
or even hundreds of milliseconds of latency (plus a dragging
congregation choir on top) :-D
OK - thanks for pointing this out.
9:26 p.m.
On 20/03/11 18:38, Jörn Nettingsmeier wrote:
a drummer will get very grumpy indeed over latencies in the 10ms
range. (i understand your use of the term to mean "time it takes for
the sound to come out after the drummer has hit the pad").
you should aim for 2ms or less, which takes considerable effort and a
very good sound card.
P.S. I have just found out that I can use higher than standard data
rates on the arduino's hardware serial to get the data off the board,
which is where i thought the bottleneck was going to be, so I should
hopefully be able to get something like 1ms latency in this part of the
system.
( http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235580746 )
11:49 p.m.
On Sun, Mar 20, 2011 at 07:38:08PM +0100, J?rn Nettingsmeier wrote:
[...]
but even when the latency is constant, drummers are
used to get very
sharp and distinct physical feedback when the stick rebounds from
the drum head, and they are very close to the instrument. so they
will usually be a lot less tolerant than electric guitarists (who
are used to operate at 3 or 4 m distance from their amps or monitor
speakers) or (extreme example) church organists, who can learn to
deal with tens or even hundreds of milliseconds of latency (plus a
dragging congregation choir on top) :-D
Not really in line with this topic, but
this observation raised the
question in my mind based on personal experience. Latencies that seemed
fine to me through speakers have often become noticeable when using
headphones. Likewise being closer to speakers/monitors, one is often
more likely to notice latency issues. This makes me wonder whether our
brain hasn't got built-in compensation for room accoustics peculiarity.
Does any one know of theory/research supporting this idea?
Cheers,
S.M.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
23 Mar
23 Mar
8:06 a.m.
Hi,
I am thinking about a possible design for the second version of the
position sensing drum pad I have been working on, and I have a
question about latency. I am working around the assumption that 10ms
latency is about the worst it can get before people start to notice it
in practice, so I am thinking of building the pad in a way where the
normal latency is about 1ms, but it degrades to between 10-15 ms in
the very worst case (many simultaneous strikes and pressure variations
across the pad). Allowing this level of degradation would make it
possible (I think) to use an arduino rather than a faster processor,
which would be nice.
So the question is, where does this 10ms figure come from, and is it a
reasonable working value? I have picked it up somewhere but I'm not
exactly sure where.
Another question on this topic - once a synth is triggered (e.g. in
supercollider which I'm using at the moment) is the latency from that
point just the jack latency, or is there an additional latency that
comes with the synth?
Also, could anyone give me a rough idea of what level of latency and
jitter to expect when using alsa midi ports to send data between two
applications?
I'm having another look at my first version of the pad, and I'm trying
to get the latency as low as possible before I present it at LAC in May.
andy
1:43 p.m.
1) it depends on the synth
2) with JACK MIDI, there is zero latency and zero jitter between two
applications. with ALSA MIDI, latency can be up to a few msecs, but is
generally on the order of tens of usecs. with ALSA, you don't have
deterministic scheduling of the apps (in general) and that is the main
source of the latency and jitter. in addition, the MIDI data arrives
(via ALSA) in the wrong thread, so there is some delay involved in
getting it injected into the synthesis (process()) thread without
locks. with JACK, the MIDI data arrives in the right thread, with
sample accurate timestamps.
On 3/23/11, andy baxter <andy(a)earthsong.free-online.co.uk> wrote:
Hi,
I am thinking about a possible design for the second version of the
position sensing drum pad I have been working on, and I have a
question about latency. I am working around the assumption that 10ms
latency is about the worst it can get before people start to notice it
in practice, so I am thinking of building the pad in a way where the
normal latency is about 1ms, but it degrades to between 10-15 ms in
the very worst case (many simultaneous strikes and pressure variations
across the pad). Allowing this level of degradation would make it
possible (I think) to use an arduino rather than a faster processor,
which would be nice.
So the question is, where does this 10ms figure come from, and is it a
reasonable working value? I have picked it up somewhere but I'm not
exactly sure where.
Another question on this topic - once a synth is triggered (e.g. in
supercollider which I'm using at the moment) is the latency from that
point just the jack latency, or is there an additional latency that
comes with the synth?
Also, could anyone give me a rough idea of what level of latency and
jitter to expect when using alsa midi ports to send data between two
applications?
I'm having another look at my first version of the pad, and I'm trying
to get the latency as low as possible before I present it at LAC in May.
andy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
4:43 p.m.
1) it depends on the synth
Do you know what the case is with supercollider? E.g. if I were to
forget about midi and just trigger sc synths directly from python using
this wrapper: http://trac2.assembla.com/pkaudio/wiki/SuperCollider
2) with JACK MIDI, there is zero latency and zero
jitter between two
applications. with ALSA MIDI, latency can be up to a few msecs, but is
generally on the order of tens of usecs. with ALSA, you don't have
deterministic scheduling of the apps (in general) and that is the main
source of the latency and jitter. in addition, the MIDI data arrives
(via ALSA) in the wrong thread, so there is some delay involved in
getting it injected into the synthesis (process()) thread without
locks. with JACK, the MIDI data arrives in the right thread, with
sample accurate timestamps.
Thanks - that's worth knowing.
Cheers.
andy :)
4997
days inactive
5000
days old
linux-audio-user@lists.linuxaudio.org
15 comments
6 participants
participants (6)
-
andy baxter -
Folderol -
Gabriel M. Beddingfield -
Jörn Nettingsmeier -
Paul Davis -
S. Massy