Greetings,
Now that JACK 0.102.20 and QJackCtl 0.2.21 being released, the FreeBoB
team is proud to present libfreebob 1.0. The FreeBoB project aims to
provide a generic solution for using Firewire (semi-)pro-audio devices
in Linux.
This release provides support for the devices based on the BridgeCo
DM1000 or DM1500 chipset that are running the BeBoB firmware. For a list
of supported devices, consult our website at freebob.sf.net.
FreeBoB currently provides an interface library that allows firewire
audio devices to be used with the JACK audio server, using a dedicated
backend. This backend is included in the official JACK releases, from
this version on (i.e. 0.102.20). The latest version of QJackCtl also
includes support for this FreeBoB backend. MIDI support is provided
through ALSA sequencer.
Feature list:
* Automatic detection & configuration of devices. If there are multiple
devices attached to the same firewire bus, freebob merges them into one
big device. The devices have to be synced externally (wordclock/spdif)
so that they don't drift. Note that this release cannot setup the boxes
to be synced yet, being synced is a precondition at the moment. (I
tested this with 2 phase88's connected with wordclock, and this works
without the need for any special setting because the Phase88
automatically chooses wordclock slave when there is a wordclock signal
present. This can be different for other models).
* Audio I/O on all analog channels at all sample rates supported by the
device. SPDIF/ADAT I/O works in most cases (when presented as analog IO
by the device). AC3 passthrough doesn't work.
* Midi I/O for all midi ports the device implements, using alsa-sequencer
* Round-trip latency figures around 5ms (depends on system
configuration). 10ms is achievable on all well-configured machines
Not supported yet:
* Hardware mixing ("zero latency" mixer)
* Device-specific configuration (input gain switches, sync source
selection, midi control mappings, ...)
* ALSA for audio IO
* Special SPDIF/ADAT stream support
You can download FreeBoB 1.0 at our sourceforge page:
http://sourceforge.net/project/showfiles.php?group_id=117802
more info at freebob.sf.net
What's next?
We are working on the second generation of the FreeBoB codebase. The 1.0
release is the endpoint for the codebase that dates back to the start of
the project. The 2.0 codebase is a complete redesign of the system using
1.0 as a 'golden spec'. While the 1.0 version is BeBoB-only, the 2.0
codebase is designed as a framework to support all firewire based audio
boxes. The current level of functionality is almost the same for both
codebases. The main difference is that 1.0 had one year of testing and
2.0 doesn't, it's still in the alpha stage. Needless to say that 2.0
will outperform 1.0 by far ;).
Of course this redesign isn't for the sake of aesthetic beauty or lack
of things to do... I can announce that we are already working on
broadening the supported device list. Currently there is support for the
Motu Traveller and the Motu 828 (through reverse engineering). There are
also contacts with the DICE-II developers to implement generic support
for devices based upon their chipset. As an extra, support for Metric
Halo devices is also in the pipeline. Once all of these devices are
supported, we will cover a very large part of the Firewire audio device
spectrum. The most important void will be RME Fireface support, and for
the real budget users: Behringer and Hercules devices.
That's all folks!
Pieter Palmers
(on behalf of the FreeBoB team)
Hello list...
I am curious to research further about MIDI timing and here is something
I want to ask...
I wonder, if we missed the (MIDI?) event a bit (perhaps 1 miliseconds?),
what would happen? I guess it will be underrun? Or technically, do we
determine a playback as "choppy" by calculating the time difference
between sending two successive MIDI events? I don't know much about
this issue, so I will gladly receive any thoughts.
On the other hand, last night I observed how timidity++ works by using
strace and I found no *sleep() (nanosleep, msleep and friends). Does it
mean, major MIDI software synthesizers use non system sleep mechanism
for the timing? I also read that not all Linux kernel sound card driver
enable the internal card timer, thus the software must rely on system
timer. Is it correct?
thanks in advance for your help and attention.
regards,
Mulyadi
Me:
> No, it genuinely went from working to broken
And actually, I think my recollection is wrong. I think
it probably broke in 2.6.8-rt, and in mainline in either
2.6.9 or 2.6.10. Before that it worked fine, but we
always used the system timer instead for RG because it
seemed simpler (it was always 1000Hz then) and we
stuck with that as the default and I guess rather
abandoned the RTC option. Sorry for being so lax.
If it does work now, then of course, that's great.
Chris
Lee:
> This is/was a bug or multiple bugs in the kernel's RTC driver. It
> started to appear around 2.6.13 because that was the kernel release
> where they regressed the default timer granularity from 1ms to 2.5ms,
> forcing apps like Rosegarden to switch to RTC based timing.
No, it genuinely went from working to broken - it's
not a case of always being broken but never
previously being necessary. It broke first in RT
kernels, so I'm guessing it broke in mainline with an
RT patch merge.
I'm not aware of anyone these days successfully
using Rosegarden with snd-rtctimer - if anyone out
there is, do say so. Either you get a 1000Hz kernel
or you suffer with crap timing.
Clemens:
> Kernels >= 2.6.15 work.
The most recent such report we had was from a
user of OpenSUSE 10.1 (with 2.6.16 I think?). I
suggested trying an ALSA driver upgrade; apparently it didn't help. The thread should be easily found in
the Rosegarden list archives by searching for rtc
and opensuse.
I don't have a computer here to test it on at all
myself at the moment, I'm afraid. I will do later. Honest.
Chris
Clemens:
> Most sound cards don't have an internal timer that could be used for
> MIDI timing. ALSA uses whatever timer is configured, the default for
> this is the RTC timer.
It is? For ALSA sequencer queues? I thought the
default was system timer. Maybe it just depends on
the modules you have loaded.
My impression from Rosegarden users' reports has
been that trying to use the ALSA sequencer with the
RTC timer (something I've never bothered with myself:
I always use a 1000Hz system timer) is a reliable way
to lock up your system completely, with most kernels
from about 2.6.13 or so onwards.
I've been meaning to investigate with the latest ALSA
source and at least make a decent bug report for
ages, but you know the way it is, there are only
sixty hours in the day. It would be wonderful if some
excellent person had fixed it in the meantime.
Chris
Hello everybody
Perhaps not directly related with audio development, but I will be glad
if someone can help me.
I downloaded a free MIDI file from Internet (drum sample MIDI from
"MIDI" wikipedia entry) and I tried to play it on my FC5. I am using
both aplaymidi and KMid, but no sound comes out. Other than this
silence, everything else seems OK i.e no error such as corrupted file.
I tested the same file with WIndows Media Player and it plays fine.
What was I doing wrong here?
Here is the specification:
Chip : Realtek ALC 650
ALSA: alsa-lib-devel-1.0.11-3.rc2.2,
alsa-utils-1.0.11-3.rc2,
alsa-lib-1.0.11-3.rc2.2
Kernel version: 2.6.16-1.2074_FC5
Desktop environment: KDE 3.5.1
Motherboard and chipset : MSI KT4V using VIA KT 400
Thanks in advance for the help.
regards,
Mulyadi
jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s
hardware counterparts. It has lot of useful features, apart from being
able to mix multiple JACK audio streams.
Homepage with screenshots: http://home.gna.org/jackmixer/
Download: http://download.gna.org/jackmixer/
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>