Subject: Re: [linux-audio-dev] latest audioengine snapshot (laaga proposal)
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Jun 14 2001 - 00:47:26 EEST
>I've just played with it, seems quite clean, though there seem to be some
>bugs in the way it gives up shm memory, or doesn't rather. Is that related
>to IPC_RMID?
There have been massive changes since last night :)
The shm segment removal thing seems very wierd. I'm wondering where
the problem comes from. I note that even ipcrm(8) will not get rid of
them, despite their attach count being 0. i have 495 segments on my
system right now :) I am still unsure why this is happening. the docs
suggest that a segment with nattch == 0 should be destroyed. but yes,
it could just be IPC_RMID missing. i notice that the "status" column
for all these segments does not say "dest", as it does for
non-AE-generated segments. so i suspect that it is just missing
IPC_RMID.
I will put another snapshot up tonight. The new one is much better
than the old. Ports now work, so I have run 2 clients and had them
share data with no problems. Woohoo!
>> * clean client exit (unclean is detected, however)
>
>Doesn't allways work though, sometimes it seems to kill the server.
This seems be cleaned up a lot. I'm trying to implement "clean client
exit" (audioengine_close()) right now, but have caused myself some
grief with a memory walking bug someplace. ugh.
>> * timebase stuff (clock master API)
>
>I'm still not sure this should be an API, couldn't it be implemented by
>connecting to a timebase output port? Or is there a good reason not to do
>this?
Well, we could, but that then means you need to write "special code"
to read it:
audioengine_port_t *time_port;
time_port = audioengine_port_register ("timeport", "MTC", PortIsInput, ...);
audioengine_port_connect ("timebase:timeport", "me:timeport");
and then in process(), you have to know how to "read" an "MTC" value
from the port.
I therefore prefer:
nframes_t audioengine_get_frame_time ();
as a simplified interface. how its implemented, once again, is up the
particular implementation.
>I sometimes have two different timebases in my setups, midi clock (if
>that counts) and mmc (smpte?*), not neccesarily in sync. eg. a synth and
>step sequncer linked by midi clock, and a sequncer and hdr linked by mmc.
midi clock is never a timebase, its a tempo/rate counter. MIDI Time
Code (MTC), which is just an encapsulation of SMPTE in a specified
MIDI format, is a timebase.
however, neither SMPTE nor MTC would act as a timebase on their
own. you'd need a client that read the MTC or SMPTE data stream, and
generated an audio frame time from them (which is hard, since neither
MTC nor SMPTE have single frame resolution, so you'd have to lie).
likely timebase "master" clients are things like Ardour or Muse, which
have their own definite notion of "time zero", and have to keep track
of the passage of time for their own internal purposes.
but you could have an "external MTC" client that read MTC and
generated audio frame time from it, thus allowing you to sync the
entire system to some external source.
note that apps that respond to the timebase have to be very
careful. if you are in the process() call and you notice nonlinear
motion in the timebase, you cannot respond to it from within that
thread unless you can do so in an RT-compliant way. ardour goes to
great lengths, for example, to run all "transport control" in a
temporary thread created specifically for that purpose. its not
impossible that this could be part of the API one day - you provide a
callback to audioengine_open(), and its executed in a non-audio thread
when nonlinear time is detected. but thats for the future.
--p
This archive was generated by hypermail 2b28 : Thu Jun 14 2001 - 02:19:59 EEST