Re: [linux-audio-dev] a port/buffer proposal

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

Subject: Re: [linux-audio-dev] a port/buffer proposal
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 22 2001 - 17:10:58 EEST


>Reading the on-line archives of lad, I think I need to tell
>something about the GLAME way of doing buffer management.

Thanks for the info. I have had a look at GLAME, and its buffer
management, but this makes things more clear. I'd like to spend a
little time thinking about this model. My instinct tells me that it
doesn't solve some of the problems we face in connecting entire
applications, but I've nothing in particular to point at.

>Note that I dont think things like automatic mixing are actually
>useful to support in the "backend" - those are really user interface
>issues (dont clobber networks with lots of mixes / splits - in GLAME
>we have a mix plugin and a one2n plugin).

One2N is simple and dealt with without mixing. The problem is
ManyToOne, and that requires mixing or banning such arrangements. If
you allow it only via a mixer plugin then that plugin needs an
arbitrary and totally variable number of inputs which should
dynamically expand (and probably decrease) as the number of
connections to it increases and decreases. This would make for a
problematic and rather pointless UI, I think.

If you ban ManyToOne, then apps that want to do submixes need to
provide their own mechanism for this, which seems redundant. Ardour in
particular will often need to bounce down a set of signals to a new
diskstream, and i'd rather use a generic mechanism inherent in the
overall system than some Ardour-specific hack to do that.

--p


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

This archive was generated by hypermail 2b28 : Thu May 24 2001 - 05:29:35 EEST