FAQ
From FreeBoB
General Stuff
I'm no coder/hacker, but still I want to help
Currently, we are working on a prototype and we don't have anything useful to do aside from coding. Of course, this will not stay that way for ever. Hopefully soon we know what we want and how we want to code the real driver. Then there will be plenty else to do (documentation, testing, ...). So please stay tuned!
What's the meaning of 'FreeBoB'?
All eventually supported devices have a software running on in it called BeBoB. We are trying to free it from the propritary world of operating systems.
What is the status of the driver? Is it useable?
Right now we are working on a prototype driver. It has some basic functionality, but is missing many features.
The current driver status:
- MIDI support through ALSA sequencer - Only 'one device on the bus' case supported
OK, I want to build the prototype driver, how do I do it?
Head over to the downloads page at SourceForge: http://sourceforge.net/project/showfiles.php?group_id=117802
Download the tarball and read the included README file.
Device Support
FreeBoB will work depending on the chipset of the interface. What chipset does it has to have?
FreeBoB is a driver for BeBoB which is the firmware. Currently, there is only one chip in the wild which is running this kind of software, the DM1000. But it is to be expected to find soon other chips (still prefix-labled with DM) which will running BeBoB versions.
What devices are supported?
Please refer to the List of Supported Devices page.
Will the M-Audio 410 / 1814 be supported?
Maybe. The problem is that the M-Audio 410 / 1814 does not support the AV/C commandos for device discovering. Though for transporting the signals the IEC 618863-6 standard is used. So that means that streaming is no problem while controlling the device is.
The M-Audio 410 is BridgeCo's first product and differs heavily from the rest. FW410 tries to collect information about this device.
The state about the M-Audio 1814 is unknown.
Discovery and Configuration Issues
Q: I get this error: "Could not get 1394 handle: Permission denied". What does it mean?
A: Please read the notes on UdevConfiguration.
Streaming an JACK Issues
Xruns or no Xruns
Q: I have some problems with freebob. I can hear and see a lot of dropout not reported by Jack as Xruns.
Jackd was started from qjackctl :
jackd -v -R -P89 -dfreebob -dhw:0 -r44100 -p1024 -n2 -i6 -o10
A: Make sure that you use a -rt patched kernel and configure your system properly. See our System Configuration Hints for more info.
You could try is running with -n3 instead of -n2. Due to some internal issues, e.g. -n3 -p512 runs better than -n2 -p1024 (and also gives slightly less latency).
Another issue to check is wether dynamic cpu speed scaling is turned on or not. FreeBoB and jackd work reliably only when the cpu speed is constant. So make sure that dynamic cpu speed scaling is turned off. If you want to, you can fix the cpu speed to a lower-than-maximum value, but that has to be done before starting jackd. The exact way to disable/control the frequency scaling differs from platform to platform and from distro to distro. Some links:
- http://www.kernel.org/pub/linux/utils/kernel/cpufreq/cpufreq.html
- http://carlthompson.net/Software/CPUSpeed
DRIVER NT: could not start driver
The 1394 bus related resources are not freed correctly. That means after a few restarts of jackd the allocation of new resources will fail and jackd will barf out. The error looks like this:
DRIVER NT: could not start driver cannot start driver
A simple workaround is to reset the bus. This can either be done with gscanbus (http://gscanbus.berlios.de) 'Control->Force Bus Reset' or removing your device and re-attaching it to the bus.
What do the jackd command line arguments do?
The command line arguments present in the current jackd backend allow for extensive tweaking of the backend operation. Some are useless, others are essential, you can find a description of them on the Command Line Arguments page.
Why do I experience different round-trip delays between sessions
> At any rate, on to the main subject -- consistent latency. Personally, > I don't use software monitoring and my actual latency is kind of > irrelevant to me, as long as it's consistent and I can therefore easily > compensate. @ 88.2 khz (on a Presonus Firepod), with a patch cable > between output 1 and input 2, I'm seeing, via jdelay, between 1920 and > 1980 frames. The latency is consistent within a single run (to within > 2/10th of a frame, according to jdelay), but kill it and restart it, the > latency will be slightly different. If I fire up ardour and run all 8 > inputs simultaneously, the latency can get up to 2200 frames, although > still mostly consistent within a run. > > Increasing number of periods of playback latency seemed to reduce the > 'extra' latency (the latency that is over and beyond p*n), but didn't > help with consistency any. Shuffling RT priorities around didn't help > either. > > I can live with being a few frames off each time, but differences of a > few hundred could really start to stack up with several overdubs. Is > this just something I'm going to have do deal with until I can put > together a dual-core machine, or is there possibly a fix? I'm not > exactly on the newest machine here (Thinkpad A31p -- no HPET or for that > matter, an IOAPIC).
The inconsistency of latency between runs is a known issue in freebob 1.0. This is due to the fact that we currently don't use the SYT timestamps (i.e. sample timestamps) as a timing source, but use the 'buffer fill' as a timing source. The reason for this is mostly because processing SYT timestamps is very difficult. Using buffer-fill is good as a 'relative' time source, but suffers from the problems you describe because you don't exactly know how many samples end up in the device's internal buffers between starting the record and playback streams. The timestamps give the opportunity to correct this uncertainty.
The bad new is that freebob-1.0 doesn't support SYT timestamps, and will never do so. There is no way to fix this issue by changing hardware and/or software. It is a freebob-1.0 design problem. I think it is the only major problem with the 1.0 version (only concerning the functionality we targeted). This will be fixed in freebob-2.0.
You may need to manually...
Q: "You may need to manually set the channel on the transmitting node" <-- is this important? where do I set it?
A: You can safely ignore this message. It is a message from libiec61883 and should imho be disabled by default.
dmesg: Iso Xmit 0 Context died
> Trying to figure this out. I've been running the presonus firepod with > freebob and it dies unexpectantly with this error in dmesg: > > ohci1394: fw-host0: Unrecoverable error! > ohci1394: fw-host0: Iso Xmit 0 Context died: ctrl[60649806] cmdptr[f000e2c3]
The DMA for the iso context does not work anymore. We have seen that kind of error with the Ricoh chipset [1 (http://article.gmane.org/gmane.linux.kernel.firewire.devel/7349)] [2 (http://article.gmane.org/gmane.linux.kernel.firewire.user/2174)].
Check with lspci what chipset you have. Unfortunatly, this is a hardware driver problem or a real hardware bug. Please report your problem to linux1394-devel mailing list.
Error creating virtual device
/dev/raw1394 not accessible
JACK compiled with System V SHM support. loading driver .. Freebob using Firewire port 0, node -1 Ieee1394Service::initialize: Could not get 1394 handle: No such file or directory Is ieee1394 and raw1394 driver loaded? Fatal (devicemanager.cpp)[68] initialize: Could not initialize Ieee1349Service object Fatal (freebob.cpp)[69] freebob_new_handle: Could not initialize device manager FreeBoB ERR: FREEBOB: Error creating virtual device cannot load driver module freebob
This error is due to the fact that the /dev/raw1394 node is not present or not accessible.
You can try the following (as root)
$ modprobe raw1394 $ chmod a+rw /dev/raw1394
then try starting jack again (as a normal user)
The better solution is to setup udev to do this automatically.
Apparently you have a working libfreebob + jackd setup, because otherwise these error messages wouldn't be printed.
Device not found
JACK compiled with System V SHM support. loading driver .. Freebob using Firewire port 0, node -1 Root node has no children! Root node has no children! FreeBoB ERR: FREEBOB: Error creating virtual device cannot load driver module freebob Segmentation fault
freebob was unable to detect the device. Here some ideas to what you could do:
- Check if the device is connected to the PC and that it is powered up. BTW, it is better use a power supply and don't rely on bus power. Especially, if you are planning to use it for a live concert.
- Do not startup up the jackd immediately after you have attached the device. The device needs some time to boot itself.
- If you have more then on port on your FireWire interface card to connect to try another one. Alternatively you can tell freebob which port it should use first. By default freebob will look for devices on port 0. So if your device is on port 1 you have to tell freebob to enumerate devices on port 1. So instead of starting jackd like this 'jackd -dfreebob' use 'jackd -dfreebob -dhw:1'
- Check if gscanbus (http://gscanbus.berlios.de/) sees your device.
- Check what test-freebob reports back. You can find this program in the libfreebob/tests directory if you have compiled your own libfreebob version.
