Ozonic

Firmware version 5058 is preferable.

Support Status: 
Community Support
Manufacturer: 
M-Audio

Comments

The Ozonic was on the list of "supported devices" for the FreeBoB project. How it got on that list, I'll probably never know. I purchased one last year, expecting it to work with FreeBoB. It didn't. It still doesn't. It doesn't work with FFADO either. Hours and hours of Internet searching have turned up a number of other people who had also purchased the Ozonic based on the incorrect "supported" status listing in the FreeBoB project. None of them could get it to work either. It may work someday, but please don't purchase this device expecting it to be immediately operational under Linux.

I agree with the above poster. I own an Ozonic and despite my vigorous efforts to make it work, it didn't happen.

I am extremely happy to report that my M-Audio Ozonic is working under a fresh Ubuntu Studio 9.10. The missing piece of the puzzle was provided by Harald Postner here: http://sourceforge.net/mailarchive/message.php?msg_id=235381610%40web.de. Briefly, you have to allow the Windows driver to unmute the Ozonic before rebooting into Linux (without losing power or firewire connection), so a dual boot is essential. It seems then that the lack of ffado mixer is the big issue for this device at present.

Further to the above, I have posted my workaround (no dual-boot required) to http://subversion.ffado.org/ticket/341.

Works, on Arch64 install. Use the unmute-ozonic utility provided by ffado to unmute sound. Will also probably need to a2j to get midi to work. The driver itself, however, isn't all that stable, but then I'm using the svn version 2061-1

Hi Chaps,

Just installed AVLinux 6.0.1 which includes ffado 2.1.
The unmute-ozonic utilty is compiled and running and unmutes my ozonic nicely
Midi seems to work OK too but I haven't put it through it's paces

Thanks to the ffado team !
I'm migrating from garage band which is fiddly to connect to various ozonic controllers so I'm look forward to seeing how these will work in ardour

mixer would be nice but I'm guessing low priority (not many ozonic users posting on linux forums) - Does anyone have a recommendation where to brush up on firewire programming - maybe I'll look at it myself

Cheers

P-J

Thanks for the feedback about the Ozonic.

Regarding the mixer, you are right on the money with your suspicion. The ozonic presumedly uses its own proprietary methods to control the mixer so any generic approach doesn't work. These would need to be discovered and the knowledge used to implement code for FFADO. Fairly obviously this requires someone with an ozonic with the patience and coding skills to bring this all together. Or maybe a generic approach *does* work but no one's had a chance to try it yet.

I don't know know of any definitive programming reference for firewire. Your best bet is probably to take a look in some of the existing FFADO drivers to see how they manipulate mixers. In most cases it involves manipulation of particular device registers so it's often just one or two calls to functions which implement register access. While some devices do their own thing (RME, MOTU), others (such as the Saffires) base their device interface on an existing standard such as AV/C and FCP. I'm not sure what the Ozonic might do, but it seems to be based on BeBoB, so you might get a feel for it by looking at the drivers and mixer code for some of the other BeBoB-based devices (eg: Saffire Pro, Edirol FA-66/FA-101, Mackie Onyx and so on). Check the "configuration" file in the ffado source tree where you'll be able to identify the full list fairly readily.

Hi Chaps,

Just installed AVLinux 6.0.1 which includes ffado 2.1.
The unmute-ozonic utilty is compiled and running and unmutes my ozonic nicely
Midi seems to work OK too but I haven't put it through it's paces

Thanks to the ffado team !
I'm migrating from garage band where most of the midi controllers on the keyboard are not really very usable.

mixer would be nice but I'm guessing low priority (not many ozonic users posting on linux forums)
Cheers

P-J

i'm running M-Audio Ozonic on Linux (Kubuntu 12.04) and work very well with ffado 2.1.
driver is rock solid even at very low latency. i'm very happy about it. thank so much ;)

but even if unmute-ozonic work very well on OUT 1-2 (bus A), it seems not working on OUT 3-4 (bus B)
i can see line out from bus B on jack and i can connect something but no sound.
i double checked every hardware control for bus B, there's a volume for rear out and a source balance for headphone. no results.

i think is the only real issue with this keyboard-soundcard cause even for direct monitoring we have hardware controls, so no mixer isn't a real problem.
anyone with the same issue?

all the best
Andrea.

Yep,

Same here - I get output from 1 and 2 (balanced line out) but not 3 and 4 (unbalanced) . . output is connected to an unbalanced input so would prefer to use 3&4 (not sure if it would make much difference.
Otherwise this system is great - unmute-ozonic occasionally reports an error requiring a reboot before it will play.

records stuff brilliantly most of the time (4 audio channels and 2 midi concurrently) but periodically system starts giving XRuns - not quite sure what is running in the background that is upsetting it. Currently using the default Ubuntu studio 13 low latency kernel and wondering whether a realtime kernal might fix this.

Cool work FFADO team !

P-J

Thanks for your feedback. I'm glad that FFADO is useful to you.

Regarding the xruns, it's hard to say whether an RT kernel will help. Normally a low latency kernel is sufficient, but there are situations where things can go wrong. If you're running with a particularly low audio latency figure (very low buffer size like 32 or 64) then this can start requiring an RT kernel. The way to test this would be to temporarily use a buffer size of 512 (for example) and see if the xruns stop happening. Curiously enough, using too large a buffer size (1024 or above) can also sometimes give trouble. I had a situation the other day where a 512 sample buffer was fine but 1024 gave regular xruns every few seconds (in fairness this was while also streaming video through the same firewire port - without the video 1024 works fine).

Other potential issues are binary graphics card drivers and having the firewire interrupt shared with other devices on the system. There's certainly nothing to loose by trying an RT kernel, but it will only help in certain situations.

Apologies for last couple of posts -not yet on the board so maybe you can scrap them. Below is modified unmute-ozonic.cpp which does properly activate both audio output channels - not sure how to share this - would you guys be able to advise . . .

Cheers

P-J

/*
* Copyright (C) 2005-2008 by Daniel Wagner
*
* This file is part of FFADO
* FFADO = Free Firewire (pro-)audio drivers for linux
*
* FFADO is based upon FreeBoB.
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 2 of the License, or
* (at your option) version 3 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see .
*
*/

/*
* "unmute-ozonic" by Mark Brand (orania), based on "test-enhanced-mixer" by Daniel Wagner
* This is a knee-jerk reaction to the pathetic situation of requiring a dual-boot setup
* for the sole and only purpose of unmuting the outputs of my M-Audio Ozonic. Seriously!? ;)
*
* This utility requires patches to avc_function_block.cpp and bebob_function_block.cpp
* which might be problematic for other devices? I've included my patch to tests/SConscript.
*
* Also had a preliminary go at the mixer, which seems to work... but is incomplete.
* All were originally based on revision 1957, though everything works for me under 1985.
*/

#include "libavc/audiosubunit/avc_function_block.h"
#include "libutil/cmd_serialize.h"

#include "libieee1394/ieee1394service.h"
#include
#include

using namespace AVC;

bool
doApp( Ieee1394Service& ieee1394service, int node_id, int fb_id,int plugNumber, int inputChannel, int outputChannel, int value )
{
cout<<"pinging channel "<analog 1&2,0x02=>analog 3&4)
FunctionBlockCmd::eCA_Current); //eCA_Current = 0x10
fbCmd.setNodeId( node_id );
fbCmd.setSubunitId( 0x00 );
fbCmd.setCommandType( AVCCommand::eCT_Control );

// Daniel says: "Ok, this enhanced mixer setting here is just a hack, we need
// a sane way to set processing features (read pointer management)"
delete fbCmd.m_pFBProcessing->m_pMixer;
fbCmd.m_pFBProcessing->m_pMixer = 0;
AVC::FunctionBlockProcessingEnhancedMixer em;
fbCmd.m_pFBProcessing->m_pEnhancedMixer = em.clone();

fbCmd.m_pFBProcessing->m_fbInputPlugNumber=plugNumber; //selects appropriate source to send to sink
// Software Channels:
// 0x00 => channel 1&2 streams from host
// 0x01 => channel 3&4 streams from host
// Presumably can route audio inputs directly for monitoring:
// 0x02 => inputs 1&2
// 0x03 => inputs 3&4

fbCmd.m_pFBProcessing->m_inputAudioChannelNumber = inputChannel;
fbCmd.m_pFBProcessing->m_outputAudioChannelNumber = outputChannel;
fbCmd.m_pFBProcessing->m_pEnhancedMixer->m_statusSelector = FunctionBlockProcessingEnhancedMixer::eSS_Level;

fbCmd.m_pFBProcessing->m_pEnhancedMixer->m_LevelData.clear();
fbCmd.m_pFBProcessing->m_pEnhancedMixer->m_LevelData.push_back((mixer_level_t) value);

if ( !fbCmd.fire() ) {
printf( "cmd failed\n" );
return false;
}

return true;
}

///////////////////////////
// main
//////////////////////////
int
main(int argc, char **argv)
{
Ieee1394Service ieee1394service;
if ( !ieee1394service.initialize( 0 ) ) {
fprintf( stderr, "could not set port on ieee1394service\n" );
return -1;
}

/* MB: various values work below, these chosen *almost* arbitrarily */
doApp( ieee1394service, 0, 1, 0, 1, 1, 0 ); //unmutes channels 1&2
doApp( ieee1394service, 0, 2, 1, 2, 2, 0 ); //unmutes channels 3&4
return 0;
}

As far as I can recall, the mixer applet (well, actually everything) for the Ozonic was done extremely hastily. I only bothered with output on 1-2 because that's all that I desperately needed at the time. I do have every reason to believe that full functionality would only require some patient tinkering in the file ozonic.py. I, for one, would welcome someone else beating me to that!
EDIT: and blissfully... someone has! Thank you Takashi Sakamoto. see http://subversion.ffado.org/wiki/MaudioBebob#WorkingSampleforffado-mixer

Yep, installed 2.2.1 and the new mixer(maudio_bebob.py) works like a charm - all channels unmuted and routing and mixing as per the mac and windows interfaces - really very good if you still get the basic ozonic mixer, go find and remove the ozonic.py and ozonic.ui files.

Using star tech firewire interface 4Gb AMD three core 2.1Ghz system ubuntu studio 13.10. Still get random xruns. Sometimes a whole session recording the band(using Ardour 3.5) at 96kHz and no problems. next day I'll get continuous xruns and the next intermittent ones every few seconds. Makes it hard to guess which settings on Jackd work best.

I have worked through most of the recommendations at: http://wiki.linuxaudio.org/wiki/system_configuration but will look at delving about switching off services and possibly building a realtime kernel.

Any suggestions very welcome

Thanks to the ffado team - frustrating it is hard to make this work fully but I guess if I didn't want to tinker I'd have bought logic studio !

In addition to switching off services it may be worth looking at disabling certain devices if you're not using them. Some device drivers can cause issues with systems like FFADO which require reasonably low latency. In the past we've seen some card readers and wifi adapters create xrun trouble for example. Another source of these troubles can be the proprietary binary video card drivers, although obviously for some people removing these and using the open source equivalents is not an option. Even so, temporarily switching to the open source drivers can be useful to test whether the binary video drivers are the source of the xruns.

The intermittant nature of your xrun problems is interesting; the typical problems noted above are usually more predictable in the effects compared to what you are observing. That's interesting.