If this hits ffado-in-kernel, it would be a proc or sys interface?
As everyone is aware, the current structure of ffado effectively splits the
management of streaming from that of device control and configuration. This
means we have the ffado-enabled jackd to deal with streaming while
ffado-mixer (via ffado-dbus-server) generally handles device configuration
and any onboard mixers.
Unfortunately, this split architecture causes a difficulty with the RME
devices. While other devices make every device setting available from the
actual device, the Firefaces don't - there are a number of configuration
details which are effectively cached in the software driver. For example,
the question of whether the device is streaming or not falls into this
category. More significantly, a number of details regarding the management
of the sample rate and sync source configuration are similarly affected.
What it boils down to is that there is a need to actively share information
between the control application (ffado-dbus-server) and the ffado component
of jackd, and I am wondering what would be the most acceptable way to do
this. My immediate thought is to utilise shared memory - a shared memory
segment would be created to allow the control application
(ffado-dbus-server) to communicate with the ffado jackd backend as required.
I'm not sure which process should create the shared memory at this point.
It *may* work out easiest (and more consistent) for there to be some form
of RME information host process which simply creates the shared memory and
acts as a central repository for all information which needs to be shared.
It certainly creates an additional device-specific process requirement for
the RME devices, but the alternatives may work out to be a bit messy. For
example, which application gets the job of creating the shared memory - the
control or streaming application - and do we really want to require both
applications to be running all the time?
Apart from shared memory the information could be passed in temporary files
but that isn't all that robust and looks more like a dirty hack to me than
I am interested in what others think about how this issue might be
addressed. Is shared memory the neatest way or is there another solution we
could use? If shared memory is the go, would it be acceptable to implement
a separate RME information server to be utilised by both ffado-dbus-server
and the jackd backend, or would it be preferred to roll that functionality
into one or the other?
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
FFADO-devel mailing list