28 Feb
2014
28 Feb
'14
7:12 p.m.
On Fri, Feb 28, 2014 at 12:57 PM, Gianfranco Ceccolini <
gianfranco(a)portalmod.com.br> wrote:
creating alsa driver ... hw:0|hw:0|128|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer
little-endian
ALSA: use 2 periods for playback
When starting it on the Beaglebone Black I get:
/usr/bin/jackd --realtime -P80 -dalsa -r48000 -p128 -n2 -Xraw
creating alsa driver ... hw:0|hw:0|128|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 16 periods for capture
ALSA: final selected sample format for playback: 32bit integer
little-endian
ALSA: use 16 periods for playback
- what are those "periods" in the ALSA lines? (2 for the PC and 16 for the
BBB) ?
these are the number of "segments" or "periods" that the h/w buffer
is
divided into. Input latency is determined by period size, playback latency
is determined by buffer size. the device will wake the CPU every time it
has 1 period of date/space available.
- on the ArchWiki page on Jack there is a D-bus call
jack_control eps realtime true
stating that it "Sets JACK to realtime mode in its own internal setup."
What is this internal setup? How do I address this when not using D-Bus?
JACK starts in realtime mode by default. It can be "forced" to do that with
-R or you can turn it off with -r.