Re: [linux-audio-dev] questions to be resolved

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

Subject: Re: [linux-audio-dev] questions to be resolved
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Tue May 22 2001 - 20:36:38 EEST


On Tue, 22 May 2001, Abramo Bagnara wrote:

> Paul Davis wrote:
> >
> > >These threads are becoming very chaotic... are you sure to have read my
> > >answer? Why do you talk about "atomic pointer swap"? graph is changed by
> > >engine, no concurrency exists.
> >
> > The engine's audio thread cannot change the graph, since its a
> > non-deterministic operation that may interfere with low-latency
> > real-time operation. Therefore, there are at least two threads
>
> "may" is a bit weak... you're assuming that audio thread does not have
> enough free time to change the graph. This is not sure.
>

But the amount of time needed to change the graph cannot be determined
ahead of time. An application that request an additional port may have to
make considerable internal changes that cannot be accounted for by the
graph.

There are basically two situations:

A) The user changes the connections in the graph
B) The user adds or deletes a plugin for the graph or one or more plugins
   is changed in some fundamental way (this may include the addition or
   removal of ports).

In the case of A chances are fairly good (but not cerain) that the graph
can be changed using free time in the audio thread. In the second case,
chances are slim that audio can continue without interuption. In this
case it is probably better to stop or silence the audio until the graph is
rebuilt.

> > operating on the graph: the audio thread and whichever thread is
> > changing the graph.
>
> But, also if it have not enough free time, simply the audio thread would
> change a part of graph this cycle, another part the next cycle and so
> on.
>

How is the amount of time needed determined? Also, most of the time graph
sorting is done as a one shot operation - the entire graph most be
examined to determine the proper execution order.

Karl

> I don't see why you want to enforce concurrency when it's not strictly
> needed and when this means to ask for troubles.
>
> --
> Abramo Bagnara mailto:abramo_AT_alsa-project.org
>
> Opera Unica Phone: +39.546.656023
> Via Emilia Interna, 140
> 48014 Castel Bolognese (RA) - Italy
>
> ALSA project http://www.alsa-project.org
> It sounds good!
>

_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| mambo.peabody.jhu.edu/~karlmac |
-----------------------------------------------------


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

This archive was generated by hypermail 2b28 : Tue May 22 2001 - 21:17:34 EEST