27 Oct
2006
27 Oct
'06
4:30 a.m.
Pieter Palmers wrote:
Richard Taylor wrote:
Unfortunately, I'm not familiar with the Saffire. I can't tell if the
box remembers the settings through out. Each BeBoB device seems to be a
bit different in respect to those things. Well, I guess this is called
customization :)
We face two main problems. First, we want to support mixer settings.
This can be achieved with a generic approach. The AV/C function block
which represents the mixer is most likely a bridgeco extension. So we
can write a generic piece of code for that.
Second, the additional switches and knobs etc which are [bridgeco's]
customers extensions. Normally, they are controlled over proprietary
AV/C extension or over the so called hispeed control interface, IRC. We
need some support from the manufactures to tell us how to control those
features and then we have to come up with some (generic?) control panel.
We have talked about the first problem and have agreed on some initial
steps to achieve it. I will implement the AV/C stuff but that is the
simple part. We (or better I) are still not sure how to abstract the
generic interface. I remember some discussion here but can't remember
the findings. Of course we need a GUI. We also got some inputs from lad
where this problem of a generic mixer was also a topic. It seems that a
form of a generic mixer is interesting for other projects besides freebob.
I haven't started to work on the mixer code since I'm still trying to
figure out how to support the m-audio fw410. I reckon there are many
users of fw410 around. The bad news is that it is rather broken device
and it is difficult to get it working. There are some notes [1] about my
undertaking but I don't know if this is worth spending more time on it.
Anyway the next thing I will work on caching the AV/C models in order to
speed up the device discovering. That means the mixer has to wait for a
while if I'm doing this.
Apropos zero latency: There is no such thing as zero latency for a BeBoB
device. You will always have a delay from the input to the output even
though it is routed entirely through the device. I don't have the
numbers and I can't tell if this is a problem or not but I just wanted
to point that out before too many are really disappointed about that fact.
cheers,
daniel
[1] http://freebob.sourceforge.net/index.php/FW410
Good news and bad news. Good news, recording does
work.
Bad news, zero latency monitoring comes on by default and routes
itself to all the analog outputs so it's a bit useless really.
Maybe there's a setting somewhere i've missed - definately nothing
connected in jack tho.
There might be a chance that the device remembers the last
mixer setting
on startup. So you what you can try is setting the mixer on a windows
machine (if you have one available) and see if it's settings are
retained on power cycles. The other option is to wait until we finish
the mixer control. I know that the current code already contains most of
the infrastructure to support this, but it's not finished. The
difficulty (and opportunity) is that the interface is the same for all
bebob devices, requiring it to be very flexible and hence pretty
complicated. Daniel is the expert on this, maybe he can shed a light
here. Maybe it's not very complicated to have a temporary tool that
kills all zero-latency monitoring paths.