Re: [linux-audio-dev] introduction & ideas

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] introduction & ideas
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Feb 25 2002 - 14:10:35 EET


>You are correct in saying that UST/MSC can't provide sample accurate
>audio sync, and I don't think it is ment for that. This has to be done at
>the hardware level.

it has to be done on 2 levels:

   * participating hardware outputs need to be able to ensure that
       their rate of data consumption/generation match that of a
       defined standard.

   * participating objects in the system have to be
       producing/consuming data at the same time, so that all data fed
       to hardware outputs at time N reflects the state of the entire
       system at time N-M (where M might be zero). if one object has
       precomputed all its data, then in the general case, it is not
       in sync with everyone else. obviously, if it has no connections
       to anyone else and no real-time modifiable parameters, this
       isn't an issue, but this is rare (gain control alone is almost
       universal).

>a video tape, then there is no sample clock. You could still provide fairly
>accurate synchronisation if you have a soundcard with 'pitch' (or do sample
>rate conversion yourself), so here this synchronisation would be of help.
>But then again, I think it is great for syncing MIDI, GUI, video/display
>with
>(a) audio streams that are sample synced in hardware.

yes, but you don't need UST for that, not in the sense of a 64 bit
nanosecond accurate, hardware independent clock. SMPTE has a
resolution of (about) 1/30 second, and works well enough for most
people doing multimedia temporal synchronization. Moreover, UST isn't
a way to define temporal synchronization. The whole point of UST is to
provide a monotonic clock that moves independently of the internals of
the overall media system. Temporal sync between different media
streams requires the use of a media-defined timebase (such as SMPTE)
that is "tied" to one of the streams. Think about what happens when
you stop the transport, rewind and start again. UST time keeps rolling
forward, SMPTE time has gone backwards at this point. Yet its the
SMPTE time that has to be used for temporal sync.

The envisioned used for UST in dmSDK/OpenML seems to be merely as a
way to correct drift, but this could be a rather bad idea if the
source of UST isn't synchronized with the hardware driving the
reference output stream. For example, the natural source of UST on an
Intel system would be the cycle counter, but there is no evidence that
the cycle counter has less jitter or is more accurate than the sample
clock in a decent audio interface. If you use the cycle counter, the
chances are that you will often be correcting for drift, and this
seems wrong when it appears likely that the audio interface has a more
accurate clock than the cycle counter (though of lower resolution).

>> >A synchronous execution model also isn't really needed for a
>> >non-realtime application that might not be able to run with
>> >SCHED_FIFO and could as well just have a large buffer that it fills
>> >from time to time.
>>
>> on SCHED_FIFO: most people who use media players like the fact that
>> when you adjust the volume, the volume changes "in real time". you
>> don't need to go down to 1.3msec interrupt intervals for this, but you
>> definitely need to do better than 187msec.
>
>Then maybe we do all need SCHED_FIFO for these applications. It just
>complicates security though. Is there a way to have an application use
>SCHED_FIFO for its audio part and not be a SUID root?

yes and no. The kernel has full support for capabilities. If you have
CAP_RESOURCE, you can use SCHED_FIFO and mlockall(2) and mess with the
RTC. The problem is that no default kernel I know of (even one built
with the source default config options) that has capabilities
enabled. MusE has been using them for a while, but only if they built
into the kernel. If you have a kernel without capabilities enabled,
you're stuck requiring root access.

BTW, I don't believe that any media apps should be suid-root. This
creates a different security hole than requiring them to be run as
root, since it allows non-root crackers to get root access. A program
that can be used to cause problems (as any SCHED_FIFO program can),
but can only be run by root, requires crackers to get root access some
other way. Once they've done that, a media app that runs SCHED_FIFO is
the least of your problems :)

>That's what I thought. Too bad. We could do with a standard media API.
>It would be nice if jack could use the UST/MSC. Does it have something
>similar?

JACK has an interrupt-cycle-resolution UST source (at least when used
the existing ALSA PCM driver). It could easily add the cycle counter,
but that doesn't make any sense given the clock skew that I alluded to
above.

>A jack isn't symetric though, i mean the receiving end of an output
>jack does not behave like an input jack. So there is a difference
>between a 'device' and an 'application'. Does jack have this
>difference? I don't think it is

Well, within a JACK client, you can't write to its input ports and you
can't read from its output ports. Other than that, all ports, whether
owned by drivers or regular clients, are equivalent. Data can move in
any direction between any appropriately connected set of ports.

>There is a difference in that ALSA is used only aw an endpoint, and
>OpenML could be used for application interconnection possibly.

actually, this is a widespread misconception. alsa-lib is perfectly
capable of allowing user-space/application defined PCM devices, and
thus can allow applications to become endpoints themselves, to
interconnect with each other, and to share data. the reason JACK
exists is that some of us felt that the ALSA API wasn't the right
model for doing this.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Feb 25 2002 - 14:02:49 EET