DevNotes:12.2007-01.2008 - Building a Test System

From Resound-wiki

Jump to: navigation, search
  • system is working on Toshiba Portege running server and GUI, using Saffire Pro 24IO interface with FreeBoB driver.

Objective: working test system on single laptop with MIDI control and audio playback from laptop.

  1. Test system with live audio input from CD player and MIDI control. Run as SU to avoid xruns. Find best buffer settings for jack and freebob driver. done
  2. Get playback working with a media player. done using ReZound (see below). Might also want to try a lighter weight option (VLC) and/or a more flexible one (Ardour).
  3. Build clean system (on different laptop) with dual-boot Gutsy and WinXP (for adjusting Focusrite & Bitstream patches). Install linux rt kernel to avoid running as su. Install all resound components and the same media player used previously... done

Contents

[edit]

Notes

Tested system for xruns while running Jack (etc) as super-user. The following configuration was used:

  • resound_server and resound_gui both running on the same laptop.
  • Focusrite Saffire Pro 26 IO audio interface with FreeBoB driver, configured via qjackctl.
  • 1 live input to audio interface, 8 live outputs (only two of which actually driving loudspeakers).
  • jackd and freebob driver settings as follows. jackd -R -t4999 -dfreebob -r44100 -p64 -n2 -i1 -o8. -R runs JACK with real-time scheduling: this is vital to avoid audio dropouts (xruns) and, unless a realtime kernel is installed, can only be done by a super user. -t sets the client timeout; to run in realtime this must be under 5000ms, hence 4999. -dfreebob chooses the freebob firewire driver. -p sets the number of frames (samples?) per period and -n sets the number of periods per buffer, so 64 x 2 equals a buffer size of 128 frames (samples?) in this case. -i and -o set the number of inputs and outputs, respectively. With these settings, no xruns occurred during testing. Reducing the period size to 32, however, caused significant problems.

Tested playback with a media player.

  • ReZound 0.12.3beta was used to generate a sine tone routed directly to resound_server via JACK.
    • Note that at the time of writing this was not the version of ReZound available as a package. I had to download and compile the source code (http://rezound.sourceforge.net/) and ./configure using the --enable-jack option (see this documentation.
  • ReZound has two output channels by default. This can be changed by modifying the file ~/.rezound/registry.dat. Find the line that reads DesiredOutputChannelCount=2 and modify it accordingly.
  • Once installed with Jack support and configured for the right number of outputs, run rezound using Jack as follows: 
sudo rezound --audio-method=jack
  • Noticed slight zipper noise when using a pure tone test signal. The zipper noise was present when using MIDI control and when moving the faders on-screen with mouse. Perhaps interpolation needs to be improved.
  • The number of xruns increased (using the same Jack settings as before) but perhaps this is to be expected when running everything on a single laptop, including a web browser.
[edit]

Startup Sequence

  • Use the following sequence to startup. It may be useful to use a different workspace / console for each discrete step. For 'as super-user' read also 'with the real-time kernel installed.'
  1. Run qjackctl as super-user. Use it to configure JACK accordingly (see above for example).
  2. Run resound_server as super-user, with the corresponding number of inputs and outputs.
  3. Run resound_gui as super-user, again with the same number of i/o.
  4. Using qjackctl, route MIDI from the hardware device to resound_gui.
  5. Run any Jack enabled media player as super user if direct playback from computer is required.
  6. Also using qjackctl, route audio appropriately between resound_server, the audio interface and any software media player(s) in use.
  7. Route audio in resound_gui according to requirements.
[edit]

Shutdown Sequence

  • Two permutations were attempted, the first being:
  1. Close resound_gui application
  2. Stop resound_server application (using CTRL+C)
  3. Stop jack via qjackctl
  • The second sequence attempted was the reverse:
  1. Stop jack via qjackctl
  2. Stop resound_server application (using CTRL+C)
  3. Close resound_gui application
  • Both methods occasionally caused the firewire driver to crash. The solution is to power-cycle the audio interface. This is less than ideal but not an insurmountable problem...
[edit]

Testing the System

The demo system is now complete, and is being tested. The system comprises:

With the above setup, the following points were observed:

  • Even with real-time enabled, frequent xruns occurred with a buffer size of 2 x 128 frames. This could be because Jack is running with the (default) number of I/O even though these aren't all in use. For some reason it is no longer possible to adjust the number of inputs and outputs in the Setup dialog of qjackctl. Previously these had been limited to only the channels in use... Now attempting larger buffer sizes.
  • 3 x 4096 caused no xruns, but unacceptably high latency.
  • 3 x 2048 caused no xruns, but unacceptably high latency.
  • 3 x 1024 caused no xruns, but unacceptably high latency. (ReZound crashed when I opened a menu without first stopping audio playback but this didn't cause an xrun).
  • 3 x 512 began to cause xruns, and ReZound began behaving a little erratically. The control latency is still too sluggish at this buffer size => suspect a lighter weight media player is required for this setup.
  • Will test exactly the same system, but with external audio input from CD (i.e. cutting out ReZound).

With the above setup, minus ReZound, the following points were observed:

  • 3 x 1024 caused no xruns, but unacceptably high latency. Crackling was present in the signal as observed previously. Perhaps this could be remedied by increasing the input latency?
  • 3 x 512 caused no xruns, but unacceptably high latency. The crackling observed with a larger buffer size seemed to be less severe, strangely, although not gone entirely. This concurs with what was observed previously.
  • 3 x 256 caused no xruns during normal playback. A single xrun occurred when closing resound_server to end the test. This may have actually been caused by switching between desktop workspaces. Control felt very sluggish, especially on fades to nothing, but might just about be considered acceptable in an emergency. The crackling observed previously, if present at all, was not obvious.
  • 3 x 128 caused no xruns, except one when closing the resound_server (see previous bullet). Control felt slightly sluggish but would more or less be an acceptable threshhold. Crackling was, again, present in the audio. Despite the crackling no xruns were reported, but this could be because the dropouts weren't long enough to be detected.
  • 3 x 64 caused five xruns (at which point crackles were introduced that persisted for a while), but there was a web browser open with typing going on. One of the xruns happened when the resound_server was closed, as previously. Control responsiveness was pretty good but could have been better...
  • 3 x 32 (=96) caused significant numbers of xruns (18 within around 30 seconds). Responsiveness was good.
[edit]

Summary

  • A buffer size of 3 x 128 (=384) is the largest acceptable in terms of control responsiveness. It would be good to reliably attain 3 x 32 (=96) or equivalent.
  • Playback with ReZound fails to be reliable with buffer sizes smaller than about 3 x 1024 (=3070) and is therefore not appropriate for performance on this system.
  • Playback with input from an external source remains reliable with buffer sizes down to about 3 x 128 (=384), which is just acceptable for control, and is almost reliable at 3 x 64 (=192).
[edit]

Potential Optimisations

  • Compile with release compiler settings as opposed to debug.
  • Could the interpolation in software be made faster? How slow is the ramping algorithm?
    • This is almost certainly possible - the ramping algorithm lags because it is logarithmic and does not compensate for buffer size. This could be replaced with a linear or cubic algorithm that would be more accurate and responsive at higher buffer sizes --Drm004e 03:40, 7 January 2008 (PST)
  • Use a lighter weight media player, e.g. VLC?
  • Disable unnecessary desktop functions e.g. flashy graphics etc.
  • Play around with Jack settings further (= tedious).
  • Try setting 'nice' and priority levels differently. Need to research this.
[edit]

Compilation as Release

  • Edited all 3 CMakeFiles.txt by commenting out all instances of the -g flag in CMAKE_CXX_FLAGS then compiled thus: 
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release .
make
sudo make install
  • I don't know if this is correct or not but now I'm doing further testing without ReZound:
  • 3 x 128 caused 1 xrun when closing resound_server
  • 3 x 64 (=192) caused 1 xrun when closing resound_server
  • 3 x 32 (=96) caused immediate xruns
  • 2 x 64 (=128) caused xruns but not as seriously as 3 x 32
  • 4 x 32 (=128) caused xruns
  • 3 x 64 seems to be the best option. On further testing this caused no xruns in 10 minutes (except once when resound_server was closed).
  • Now return to testing with ReZound for playback...
  • 3 x 1024 caused no xruns, including when resound_server was stopped
  • 3 x 512 ReZound crashed the first time around, but without causing any xruns. On a second attempt it appeared relatively stable, although a single xrun did occur while typing into a web browser...
  • 3 x 256 Again, ReZound crashed the first time around (zombified) but without causing xruns. The second attempt was better and again, typing into a web browser caused an xrun. One further xrun occurred in normal operation (during a 2-3 minute period). So, not stable, but almost...
  • At this point the web browser was closed down -- this did yield a significant improvement in performance.
  • 3 x 128 ReZound performed well for about a minute, then crashed. No xruns, though.
  • 3 x 64 (=192) ReZound ran very grudgingly, with xruns and other problems
  • 2 x 128 (=256) Again, crashed first time. Second time ran, problematically. Although not as bad as 3 x 64 still not usable.
[edit]

Summary

  • Compiling as release (see above) seemed to make a significant difference.
  • Operation with external audio input works reliably down to buffer size of around 192 samples (3 x 64).
  • This could be further improved by closing the superfluous web browser.
  • ReZound, although it did perform better after release compilation, is not reliable enough.
[edit]

VLC

  • Built and installed VLC svn trunk (version 0.9.0svn). See here for further details.
  • Started jackd with dummy driver and VLC appears as expected.
  • At a glance it seems to support multichannel wav playback and will also be good for video.
  • Note: it creates it's Jack ports when media starts playing, and removes them when it stops. So, to maintain connections it will be necessary to use the Jack active scanning patch bay.
[edit]

To Do

  • Test VLC more thoroughly.
  • Verify that compilation as release was done correctly. Could it be further optimised?
  • Look into memory allocation a bit further. E.g. when running Jack in RT mode, do we also need to allocated memory / priority etc. to Resound and/or any other media players? Could performance be improved this way?
  • Look into other (simple) system optimisations e.g. turning off fancy graphics etc.
  • See also points in the Summaries above for further To-Dos...
Retrieved from "http://resound.sourceforge.net/wiki/index.php/DevNotes:12.2007-01.2008_-_Building_a_Test_System"
Personal tools