Subject: [linux-audio-dev] a central problem with *any* Port model?
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed May 23 2001 - 18:11:36 EEST
You might have wondered what the "request_monitor_input" and related
parts of my proposed API were for.
Input monitoring is a critical part of most audio systems. It is
accomplished most efficiently by the component closest to the h/w.
Thus, although in theory you could use a "monitor" plugin that feeds
its inputs to its outputs (presumably by tieing the two Ports
together), this is less efficient than doing it in the Driver
currently being used. This allows the driver to monitor input
*without* h/w-format-to-s/w-format-to-h/w-format conversions. In the
"alsadriver" object that I wrote, its accomplished with either memcpy
or a variant that handles interleaving.
So yes, a plugin could do it, but its less efficient. There is also
the problem that if its done by a plugin, objects which desire
input monitoring to be in effect do not know who to ask to make this
happen. An example is Ardour's Route and DiskStream objects, both of
which have methods which cause them to want to request that their
inputs be monitored. In a plugin-based system, how would they know who
to ask?
But wait a minute! Oh my, this is much worse than I thought. Much
worse. There isn't *any* way to monitor the input of a Port in
general! If it happens to be a port on a Driver that is controlling an
audio h/w interface, then its possible. But in the general case, the
notion of monitoring a Port is nonsensical - there is no mechanism to
do it.
Gulp. This seems bad.
How can anyone build a disk recorder that cannot monitor its input
effectively?
--p
This archive was generated by hypermail 2b28 : Wed May 23 2001 - 18:42:24 EEST