24 Jul
2007
24 Jul
'07
5:01 a.m.
Hi,
(1) I've written a command line MIDI sequencer for lightweight systems and
am successful in making it work using the ALSA queue API. However, one
drawback of the API is its lack of callback functions. I wish to be able
to track events as they are drained by the queue.
(2) I know and have successfully worked on a work around whereby the
application itself subscribes to the output port so as to see events as
they are played.
However, I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Here's the pseudo-code of the relevant MIDI player routine:
for (i = 0; i < number_of_events; i++)
{
usleep(event[i].delta_time_in_microseconds);
output_and_drain_event(event[i]);
}
This routine gives a non-bearable latency on 2.4 kernels but not so much on
2.6 kernels.
How could I get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port? Or, is there a drain or output routine that supports
callbacks? If so, I will be grateful if you could point them out. I seem
not to find any output callback routine under the docs.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
24 Jul
24 Jul
6:05 a.m.
Carlo Florendo wrote:
How could I get the app to <u|nano>sleep() in
the most accurate way in
userspace
clock_nanosleep() - see also
http://linuxaudio.org/pipermail/linux-audio-dev/2007-March/018691.html
robin
6:06 a.m.
On Tuesday 24 July 2007, Carlo Florendo wrote:
Hi,
(1) I've written a command line MIDI sequencer for lightweight systems and
am successful in making it work using the ALSA queue API. However, one
drawback of the API is its lack of callback functions. I wish to be able
to track events as they are drained by the queue.
(2) I know and have successfully worked on a work around whereby the
application itself subscribes to the output port so as to see events as
they are played.
However, I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Here's the pseudo-code of the relevant MIDI player routine:
for (i = 0; i < number_of_events; i++)
{
usleep(event[i].delta_time_in_microseconds);
output_and_drain_event(event[i]);
}
This routine gives a non-bearable latency on 2.4 kernels but not so much on
2.6 kernels.
How could I get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port? Or, is there a drain or output routine that supports
callbacks? If so, I will be grateful if you could point them out. I seem
not to find any output callback routine under the docs.
One way to improve timing is to make sure your process has the highest prio in
the system, so that even in the case that other tasks want to run, too, at
the moment of wakeup, your process gets the CPU.
Try running your process with SCHED_FIFO scheduling and a high prio of e.g.
99.
Also using a kernel patched with ingo molnar's -rt patches might help quite a
bit (additional to running your process SCHED_FIFO).
Also you want to check on every wakeup (after your sleep expired) how long you
really slept, so you can adjust the next sleep time. clock_gettime
(CLOCK_MONOTONIC) might be useful for this..
Another approach, that works very well in my experience, is to not sleep the
total required time until the next event, but rather regularly sleep for very
short amounts of time (< 1ms), wakeup, measure the current time and if any
event time now lies in the past, simply play it back immediately. This way
the sleep time doesn't need to be accurate at all. All that's needed is that
it's small enough to get some decent timing.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
10:17 p.m.
Florian Schmidt wrote:
I've tried that in kernel 2.4 and I get the same latency results. Let me
try tweaking that though by running the system with high priority. The
reason why I'd like to make it work in 2.4 kernels is so that existing
systems with 2.4 kernels could run the app without need for a kernel patch.
Here's the
pseudo-code of the relevant MIDI player routine:
for (i = 0; i < number_of_events; i++)
{
usleep(event[i].delta_time_in_microseconds);
output_and_drain_event(event[i]);
}
This routine gives a non-bearable latency on 2.4 kernels but not so much on
2.6 kernels.
How could I get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port? Or, is there a drain or output routine that supports
callbacks? If so, I will be grateful if you could point them out. I seem
not to find any output callback routine under the docs.
One way to improve timing is to make sure your process has the highest prio in
the system, so that even in the case that other tasks want to run, too, at
the moment of wakeup, your process gets the CPU.
Try running your process with SCHED_FIFO scheduling and a high prio of e.g.
99.
Also using a kernel patched with ingo molnar's -rt patches might help quite a
bit (additional to running your process SCHED_FIFO).
Yes, I've been contemplating on doing that very soon.
Also you want to check on every wakeup (after your
sleep expired) how long you
really slept, so you can adjust the next sleep time. clock_gettime
(CLOCK_MONOTONIC) might be useful for this..
This is new to me. I've never tried it but will try it ASAP.
Another approach, that works very well in my
experience, is to not sleep the
total required time until the next event, but rather regularly sleep for very
short amounts of time (< 1ms), wakeup, measure the current time and if any
event time now lies in the past, simply play it back immediately. This way
the sleep time doesn't need to be accurate at all. All that's needed is that
it's small enough to get some decent timing.
This seems reasonable enough. I'd try this out too.
Regards,
Flo
Your ideas have been most helpful :)
Thank you very much!
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
25 Jul
25 Jul
5:25 a.m.
On Wednesday 25 July 2007, Carlo Florendo wrote:
2.4.x kernels are terribly unsuited to do any serious sort of realtime work,
be it audio or midi.
From my experience this is a classification with increasing suitedness for
realtime work:
1] vanilla 2.4.x
2] patched 2.4.x [lowlatency patches]
3] vanilla 2.6.x
4] patched 2.6.x [ingo molnar's realtime preemption patches]
There really should be like 100 bogus places between 2] and 3] and another 100
between unpatched and patched 2.6.x because 2.6.x really is vastly better
than 2.4.x and -rt patched 2.6.x actually is a realtime system which can be
made to work up to microsecond resolution [not millisecond ;)].
Try running
your process with SCHED_FIFO scheduling and a high prio of
e.g. 99.
I've tried that in kernel 2.4 and I get the same latency results. Let me
try tweaking that though by running the system with high priority. The
reason why I'd like to make it work in 2.4 kernels is so that existing
systems with 2.4 kernels could run the app without need for a kernel patch.
Your ideas have been most helpful :)
No problem. BTW: even when you use ALSA queues, the kernel still plays a big
role. Then it's simply ALSA's responsibility to provide good timing and it
basically uses the same mechanisms as a userspace program would.
So thrash 2.4.x for all realtime purposes..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
26 Jul
26 Jul
12:51 a.m.
Florian Schmidt wrote:
Another approach, that works very well in my
experience, is to not sleep the
total required time until the next event, but rather regularly sleep for very
short amounts of time (< 1ms), wakeup, measure the current time and if any
event time now lies in the past, simply play it back immediately. This way
the sleep time doesn't need to be accurate at all. All that's needed is that
it's small enough to get some decent timing.
I've now finished implementing this approach, sleeping around 10000
microseconds instead of less than 1ms, and it works very well! Thanks!
I'm getting very decent timing even with complicated MIDI files that have
numerous pitch bends at very short times.
I'm about to try your other suggestions later on.
Thank you very much.
Regards,
Flo
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
24 Jul
24 Jul
6:24 a.m.
New subject: [alsa-devel] How to get correct midi timings from ALSA using the library only
Carlo Florendo wrote:
(1) I've written a command line MIDI sequencer for
lightweight systems and
am successful in making it work using the ALSA queue API. However, one
drawback of the API is its lack of callback functions. I wish to be able
to track events as they are drained by the queue.
(2) I know and have successfully worked on a work around whereby the
application itself subscribes to the output port so as to see events as
they are played.
You could also send special user-defined events just to yourself, but
the principle is the same.
However, I wish to be able to make the sequencer or
player work without the
use of the ALSA queue nor the workaround in (2).
Why?
How could I get the app to <u|nano>sleep() in
the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port?
On newer kernels, you could try POSIX interval timers.
Or, is there a drain or output routine that supports
callbacks?
Why can't you simply call the callback when some event has been
received?
Regards,
Clemens
8:54 p.m.
New subject: [alsa-devel] How to get correct midi timings from ALSA using the library only
Clemens Ladisch wrote:
Because the queue output and draining, AFAICS, is implemented in a blocking
manner. When events are being played by the queue in the kernel, the
application blocks, and I have no control on what is being played, except
that I could raise a SIGTERM anytime and end the app.
AFAIK, using the queue is fine for a simple MIDI player, but not for a
sequencer, when you need full control of everything that happens with the
audio output.
What newer kernels? Interval timers, as far as I've tested, result in more
latency than simple sleeps. And yes, I've tried select(), which seems to
be more accurate than usleep().
Received by what? By the extra subscription to the output port? As I've
mentioned in the original post, I know this works but for now, I'd want to
try out simpler sleeps than having an extra output port subscription.
The queue blocks when it plays events. Thus, the supposed callback
function which, as you suggest, should be called after the event is
received, will already be useless since the callback will only be executed
once the queue unblocks.
Thank you very much.
However, I
wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Why? How could I
get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port?
On newer kernels, you could try POSIX interval timers. Or, is there a
drain or output routine that supports callbacks?
Why can't you simply call the callback when some event has been
received?
Regards,
Clemens
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
25 Jul
25 Jul
4:25 a.m.
New subject: [alsa-devel] How to get correct midi timings from ALSA using the library only
Carlo Florendo wrote:
Clemens Ladisch wrote:
Because the queue output and draining, AFAICS, is implemented in a blocking
manner.
When non-blocking mode is set (see snd_seq_nonblock()),
snd_seq_drain_output() does not block but writes only as many events to
the kernel buffer as fit inside (or returns -EAGAIN if the kernel buffer
is completely full).
Regards,
Clemens
However,
I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Why?
4:51 a.m.
New subject: [alsa-devel] How to get correct midi timings from ALSA using the library only
Clemens Ladisch wrote:
Carlo Florendo wrote:
Gee! I haven't read the ALSA lib API docs that much but this sounds and
looks like a solution to the problem :)
Thank you very much for the pointers and for all your patience.
Clemens Ladisch wrote:
Because the queue
output and draining, AFAICS, is implemented in a blocking
manner.
When non-blocking mode is set (see snd_seq_nonblock()),
snd_seq_drain_output() does not block but writes only as many events to
the kernel buffer as fit inside (or returns -EAGAIN if the kernel buffer
is completely full). However,
I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Why?
Regards,
Clemens
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
5:16 a.m.
New subject: [alsa-devel] How to get correct midi timings from ALSA using the library only
Clemens Ladisch wrote:
Carlo Florendo wrote:
Bingo! My recent tests show that snd_seq_nonblock() is indeed a useful
function and enables me to have control of the sequencer every time it
outputs an event :)
Gee, I've read the ALSA lib doc for months and never came across this
function. Up to now, I've not seen the part of the doc that describes
snd_seq_nonblock so I went straight to the source code of alsa-lib under
src/seq/seq.c and grepped for snd_seq_block().
The alsa-lib docs have to be improved :)
Thank you for the pointers!
Clemens Ladisch wrote:
Because the queue
output and draining, AFAICS, is implemented in a blocking
manner.
When non-blocking mode is set (see snd_seq_nonblock()),
snd_seq_drain_output() does not block but writes only as many events to
the kernel buffer as fit inside (or returns -EAGAIN if the kernel buffer
is completely full). However,
I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Why?
Regards,
Clemens
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
6211
days inactive
6213
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Carlo Florendo -
Clemens Ladisch -
Florian Schmidt -
Robin Gareus