what is an xrun

[Davy Durham]

Hi List,
What is an xrun exactly, what causes them? Are they serious? Is it
okay to have them occasionally? How can they be prevented (from
programming a jack client perspective), etc.. Is this already
explained somewhere else?

I'm trying to shore up the rough edges of the JACK implementation in
ReZound, and it's been a long while since I implemented it the first time.

Thanks,
Davy


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Tommi Sakari Uimonen]

What is an xrun exactly, what causes them? Are they serious? Is it okay to
have them occasionally? How can they be prevented (from programming a jack
client perspective), etc.. Is this already explained somewhere else?

xrun is common name for either buffer underrun of overrun. Underrun
happens on playback, when soundcard wants new data to buffer but
software is unable to fill the buffer fast enough. Overrun happens on
recording, when soundcard puts new data to buffer but software has not
managed to grab the previous values 'out of the way'

What causes? This is complicated. Basically because the operating system
was not able to keep up the fine buffer-filling/reading job it was doing.
This happens a lot if jackd is not run with realtime priority. Kernel
preemption also helps. There is tons of mails about how to reduce possible
xruns, at least in LAU list and this list.

Starting jackd with biggest buffer available, helps to reduce possible
xruns. (I don't actually know if -p 2048 -n 2 achieves the same as -p 4096
-n 1, both have the same buffer size but structured a bit different, I'd
go for big p)

Serious?

Depending on your work. In normal desktop usage they are ok to have them
occasionally. Serious recording work does not tolerate even one single
xrun. Even for semi-serious recording like
rosegarden-hydrogen-zynaddsubfx-ardour chain like I do, it's pita if xruns
happen, because recording must be started all over again. Fortunately I
have not suffered from xruns so far when doing those recordings.

I'm trying to shore up the rough edges of the JACK implementation in ReZound,

Cool!



Tommi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Lars Luthman]

Even for semi-serious recording like rosegarden-hydrogen-zynaddsubfx-ardour
chain like I do, it's pita if xruns happen, because recording must be
started all over again. Fortunately I have not suffered from xruns so far
when doing those recordings.

Is this really true? I was under the impression that JACKs synchronous
execution of all clients would mean that xruns would only be noticed
outside the JACK graph - the recording program would simply wait until
there was enough data, and the glitch would not be recorded. I suppose
there could be MIDI timing issues, but those could be partially fixed by
synchronising your sequencer to JACK transport.

[Tommi Sakari Uimonen]

Post by Lars Luthman

Even for semi-serious recording like rosegarden-hydrogen-zynaddsubfx-ardour
chain like I do, it's pita if xruns happen, because recording must be
started all over again. Fortunately I have not suffered from xruns so far
when doing those recordings.

Is this really true? I was under the impression that JACKs synchronous
execution of all clients would mean that xruns would only be noticed
outside the JACK graph - the recording program would simply wait until
there was enough data, and the glitch would not be recorded. I suppose
there could be MIDI timing issues, but those could be partially fixed by
synchronising your sequencer to JACK transport.

I think your case is the freewheel mode. I just tested my scenario without
realtime priorities and the recording did have glitches, the song was
"jumpy" at the time where xrun occurred.

I didn't manage to get the freewheel to work. I'm not sure if all
mentioned programs even support the freewheel mode. At least most of them
became unresponsive (even ardour, which - to my knowledge - supports the
freewheeling)

First try was when all programs were already running, I ran
'jack_freewheel y' and most of the programs became unresponsive.

Second try I started jackd, then ran 'jack_freewheel y' and tried to start
the others. Zynaddsubfx started fine, hydrogen and rosegarden did not.
Quitting zynaddsubfx halted it.



For the MIDI syncing, I would love to see that MIDI events would sync to
jack time and thus would give perfect timing (with freewheeling).


Tommi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Paul Davis]

Post by Tommi Sakari Uimonen

Post by Lars Luthman
Is this really true? I was under the impression that JACKs synchronous
execution of all clients would mean that xruns would only be noticed
outside the JACK graph - the recording program would simply wait until
there was enough data, and the glitch would not be recorded. I suppose

this is false.

Post by Tommi Sakari Uimonen

Post by Lars Luthman
there could be MIDI timing issues, but those could be partially fixed by
synchronising your sequencer to JACK transport.

I think your case is the freewheel mode. I just tested my scenario without
realtime priorities and the recording did have glitches, the song was
"jumpy" at the time where xrun occurred.
I didn't manage to get the freewheel to work. I'm not sure if all
mentioned programs even support the freewheel mode. At least most of them
became unresponsive (even ardour, which - to my knowledge - supports the
freewheeling)

there is some misunderstanding of what freewheeling mode is for. it was
designed to allow faster-than-real-time operation of all JACK clients
*EXCEPT* the backend (ALSA, CoreAudio, OSS). JACK decouples its
operations from the backend, and simply runs all clients (having down
graded them to non-RT threads) as fast as is possible. i/o to/from the
backend is not possible while freewheeling.

freewheeling mode is used by ardour for export, which allows an exported
file to include the result of realtime processing by another JACK
client. it is a temporary mode, and ardour switches JACK back to regular
operation once done.

--p






-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Tommi Sakari Uimonen]

Post by Paul Davis
there is some misunderstanding of what freewheeling mode is for. it was
designed to allow faster-than-real-time operation of all JACK clients
*EXCEPT* the backend (ALSA, CoreAudio, OSS). JACK decouples its
operations from the backend, and simply runs all clients (having down
graded them to non-RT threads) as fast as is possible. i/o to/from the
backend is not possible while freewheeling.

Is it also for slower-than-real-time? If the graph is just so big (jamin
and other cpu-consuming included) that processing will be slow. (Of course
this graph cannot be listened realtime, only the resulting "export")

Post by Paul Davis
freewheeling mode is used by ardour for export, which allows an exported
file to include the result of realtime processing by another JACK
client. it is a temporary mode, and ardour switches JACK back to regular
operation once done.

Isn't there a different process() function for freewheeling mode? How
about client that has only process(), what happens to it while
freewheeling?

Tommi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Paul Davis]

Post by Tommi Sakari Uimonen

Post by Paul Davis
there is some misunderstanding of what freewheeling mode is for. it was
designed to allow faster-than-real-time operation of all JACK clients
*EXCEPT* the backend (ALSA, CoreAudio, OSS). JACK decouples its
operations from the backend, and simply runs all clients (having down
graded them to non-RT threads) as fast as is possible. i/o to/from the
backend is not possible while freewheeling.

Is it also for slower-than-real-time? If the graph is just so big (jamin
and other cpu-consuming included) that processing will be slow. (Of course
this graph cannot be listened realtime, only the resulting "export")

given that the graph was running in realtime mode, it is not likely that
it will end up slower-than-real-time. but freewheeling mode doesn't care
about timing at all, so if 1 or more clients slowed down when
freewheeling for some reason, that is OK.

Post by Tommi Sakari Uimonen

Post by Paul Davis
freewheeling mode is used by ardour for export, which allows an exported
file to include the result of realtime processing by another JACK
client. it is a temporary mode, and ardour switches JACK back to regular
operation once done.

Isn't there a different process() function for freewheeling mode? How
about client that has only process(), what happens to it while
freewheeling?

same process() callback, same ports, just no calls to or waiting for the
backend.

--p




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Tommi Sakari Uimonen]

Post by Paul Davis

Post by Tommi Sakari Uimonen
Isn't there a different process() function for freewheeling mode? How
about client that has only process(), what happens to it while
freewheeling?

same process() callback, same ports, just no calls to or waiting for the
backend.

Ok, my bad. Since jack_set_process_callback sets the process() callback, I
assumed that jack_set_freewheel_callback is somewhat the same for
freewheeling (I did read the API doc about the
jack_set_freewheel_callback, but my brains were just messing around with
me again.. )

After jack gets its MIDI capabilities, is it possible that jack is used as
time master for MIDI timing also, and then freewheeling mode would give
sample-accurate softsynth experience(*) without any MIDI timing problems?



(*) for example, rosegarden + hydrogen + zynaddsubfx + other softsynths,
and all would produce their samples right on time, no matter what. This
would allow a perfect "export" from a composition even for a slower
computer that can't handle all the 'softsynthing' in realtime.


Tommi


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

[Lars Luthman]

Post by Tommi Sakari Uimonen
After jack gets its MIDI capabilities, is it possible that jack is used as
time master for MIDI timing also, and then freewheeling mode would give
sample-accurate softsynth experience(*) without any MIDI timing problems?

Sure. If the sequencer is synchronising to JACK transport (which would
be a natural choice for a JACK MIDI sequencer) all MIDI events will be
delivered on exactly the same sample frame in freewheeling mode and
normal mode.