28 Feb
2014
28 Feb
'14
6:58 p.m.
Hi LADs
We are working on an ARM based MOD device and while fiddling with JACK some
questions appeared.
I didn't know whether to post on the ALSA os JACK lists, so I decided to
post here :-)
When I start Jack in my PC I get the well know message:
/usr/bin/jackd -P80 -dalsa -r48000 -p128 -n2 -D -Chw:0 -Phw:0
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) ? I read a post by Jeremy Jongepier about the Cubieboard2 stating that
the hardcoded values for the Cubie (Minimum number of periods was 4 and
minimum buffer size was 1024) where unfit for realtime operation. Why is
that so?
- 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?
King regards all
Gianfranco Ceccolini
The MOD Team
PS: We will be at LAC againd this year. I'm very eager to meet most of this
distinguished community members there. We have lots of good new for the MOD
in 2014.
28 Feb
28 Feb
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.
9:01 p.m.
On 02/28/2014 06:57 PM, Gianfranco Ceccolini wrote:
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) ? I read a post by Jeremy Jongepier about the Cubieboard2 stating that
the hardcoded values for the Cubie (Minimum number of periods was 4 and
minimum buffer size was 1024) where unfit for realtime operation. Why is
that so?
Hello Gianfranco,
What kind of audio interface are you using with the BBB? I'm no ALSA
expert but it seems as if the minimum period size of the driver has been
set to 16. If you have access to the source code of the driver you could
experiment with lower default values for .period_bytes_min and .periods_min.
Bye,
Jeremy
10 Mar
10 Mar
2:51 p.m.
Hi Guys
sorry for the delay. carnival time here in Brasil...
Jeremy: I’m using the BB Audio Cape, v1. I’ll take a look at the audio driver, but from
our tests the BBB cpu won’t do the job. We’re heading to the Cubie’s A20 cpu.
Paul. I’m really sorry for my lack of comprehension, but I still don’t get it. Is there a
relation between the ALSA period with JACK’s period?
Kind regards
Gianfranco
The MOD Team
Em 28/02/2014, à(s) 17:01, Jeremy Jongepier <jeremy(a)autostatic.com> escreveu:
On 02/28/2014 06:57 PM, Gianfranco Ceccolini wrote:
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) ? I read a post by Jeremy Jongepier about the Cubieboard2 stating that
the hardcoded values for the Cubie (Minimum number of periods was 4 and
minimum buffer size was 1024) where unfit for realtime operation. Why is
that so?
Hello Gianfranco,
What kind of audio interface are you using with the BBB? I'm no ALSA
expert but it seems as if the minimum period size of the driver has been
set to 16. If you have access to the source code of the driver you could
experiment with lower default values for .period_bytes_min and .periods_min.
Bye,
Jeremy
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3:26 p.m.
On Mon, Mar 10, 2014 at 9:51 AM, Gianfranco Ceccolini <
gianfranco(a)portalmod.com.br> wrote:
Paul. I'm really sorry for my lack of comprehension, but I still don't get
it. Is there a relation between the ALSA period with JACK's period?
they are identical.
note: other audio APIs call this a "buffer". some, like ASIO, force a
double "buffered" model where the total size of the hardware memory area
used for transfers (what ALSA calls the "hardware buffer") is always twice
the "buffer size".
ALSA offers control over *both* the "period" (between interrupts) and the
total hardware buffer size. This is unusual among audio APIs, except that
JACK follows the same convention in its ALSA backend. You can specify the
period size (-p) and the number of "periods" that make up the hardware
buffer.
12 Mar
12 Mar
3:26 a.m.
On Mon, Mar 10, 2014 at 9:51 AM, Gianfranco Ceccolini <gianfranco(a)portalmod.com.br>
wrote:
Paul. I’m really sorry for my lack of comprehension, but I still don’t get it. Is there
a relation between the ALSA period with JACK’s period?
they are identical.
How can that be? JACK says -p 128 samples and ALSA says 2 on
the PC and 16 on the BBB
note: other audio APIs call this a "buffer". some, like ASIO, force a double
"buffered" model where the total size of the hardware memory area used for
transfers (what ALSA calls the "hardware buffer") is always twice the
"buffer size".
ALSA offers control over *both* the "period" (between interrupts) and the total
hardware buffer size. This is unusual among audio APIs, except that JACK follows the same
convention in its ALSA backend. You can specify the period size (-p) and the number of
"periods" that make up the hardware buffer.
So if I use -p128 and -n2 it
means the kernel will buffer 256 samples per interrupt, is it?
3:50 a.m.
On Tue, Mar 11, 2014 at 10:26 PM, Gianfranco Ceccolini <
gianfranco(a)portalmod.com.br> wrote:
On Mon, Mar 10, 2014 at 9:51 AM, Gianfranco Ceccolini <
gianfranco(a)portalmod.com.br> wrote:
How does ALSA "say" anything?
Paul. I'm really sorry for my lack of comprehension, but I still don't
get it. Is there a relation between the ALSA period with JACK's period?
they are identical.
How can that be? JACK says -p 128 samples and ALSA says 2 on the PC and 16
on the BBB
note: other audio APIs call this a "buffer". some, like ASIO, force a
double "buffered" model where the total size of the hardware memory area
used for transfers (what ALSA calls the "hardware buffer") is always twice
the "buffer size".
ALSA offers control over *both* the "period" (between interrupts) and the
total hardware buffer size. This is unusual among audio APIs, except that
JACK follows the same convention in its ALSA backend. You can specify the
period size (-p) and the number of "periods" that make up the hardware
buffer.
So if I use -p128 and -n2 it means the kernel will buffer 256 samples per
interrupt, is it?
No. What it means depends on the precise details of the device. In an ideal
world, those settings mean that the DEVICE will buffer 128 samples before
issuing an interrupt, and that its total buffer size is 256.
However, USB devices etc. do not work this way, so it translates more
generically to "ALSA will wake the client up whenever at least 128 samples
of data (and/or space) are available".
The -n 2 parameter only affects the total amount of hardware buffering, not
the interval ("period") between when the application is woken.
4:21 a.m.
Em 11/03/2014, à(s) 23:50, Paul Davis <paul(a)linuxaudiosystems.com> escreveu:
And where does the 16 (from ALSA: use 16 periods for capture) affects?
if I call jack using -p128 / -n2 and the opening message states that ALSA uses 16 periods
for capture the sound card will buffer a total of 256 samples and ALSA will wake the
client each 16 frames?
If I used -p256 / -n2 instead ALSA would wake the client each 32 frames?
On Tue, Mar 11, 2014 at 10:26 PM, Gianfranco Ceccolini
<gianfranco(a)portalmod.com.br> wrote:
Sorry. I mean, JACK says ALSA uses that period size (ALSA: use 16 periods for capture)
On Mon, Mar 10, 2014 at 9:51 AM, Gianfranco Ceccolini <gianfranco(a)portalmod.com.br>
wrote:
Paul. I’m really sorry for my lack of comprehension, but I still don’t get it. Is there
a relation between the ALSA period with JACK’s period?
they are identical.
How can that be? JACK says -p 128 samples and ALSA says 2 on
the PC and 16 on the BBB
How does ALSA "say" anything?
note: other audio APIs call this a "buffer". some, like ASIO, force a double
"buffered" model where the total size of the hardware memory area used for
transfers (what ALSA calls the "hardware buffer") is always twice the
"buffer size".
ALSA offers control over *both* the "period" (between interrupts) and the total
hardware buffer size. This is unusual among audio APIs, except that JACK follows the same
convention in its ALSA backend. You can specify the period size (-p) and the number of
"periods" that make up the hardware buffer.
So if I use -p128 and -n2 it
means the kernel will buffer 256 samples per interrupt, is it?
No. What it means depends on the precise details of the device. In an ideal world, those
settings mean that the DEVICE will buffer 128 samples before issuing an interrupt, and
that its total buffer size is 256.
However, USB devices etc. do not work this way, so it translates more generically to
"ALSA will wake the client up whenever at least 128 samples of data (and/or space)
are available".
The -n 2 parameter only affects the total amount of hardware buffering, not the interval
("period") between when the application is woken.
12:37 p.m.
On 03/12/2014 04:21 AM, Gianfranco Ceccolini wrote:
And where does the 16 (from ALSA: use 16 periods for capture) affects?
if I call jack using -p128 / -n2 and the opening message states that ALSA uses 16
periods for capture the sound card will buffer a total of 256 samples and ALSA will wake
the client each 16 frames?
Not sure but I think 128*16=2048 frames are buffered in your case.
Em 11/03/2014, à(s) 23:50, Paul Davis <paul(a)linuxaudiosystems.com> escreveu:
Hi Gianfranco,
Seems like you're mixing up number of frames (JACK -p option) and number
of periods (JACK -n option). -p128 means 128 frames per period while the
ALSA message normally refers to the -n setting (so 16 equals to -n16 in
your case).
On Tue, Mar 11, 2014 at 10:26 PM, Gianfranco Ceccolini
<gianfranco(a)portalmod.com.br> wrote:
Sorry. I mean, JACK says ALSA uses that period size (ALSA: use 16 periods for capture)
On Mon, Mar 10, 2014 at 9:51 AM, Gianfranco Ceccolini <gianfranco(a)portalmod.com.br>
wrote:
Paul. I’m really sorry for my lack of comprehension, but I still don’t get it. Is there
a relation between the ALSA period with JACK’s period?
they are identical.
How can that be? JACK says -p 128 samples and ALSA says 2 on
the PC and 16 on the BBB
How does ALSA "say" anything?
note: other audio APIs call this a "buffer". some, like ASIO, force a double
"buffered" model where the total size of the hardware memory area used for
transfers (what ALSA calls the "hardware buffer") is always twice the
"buffer size".
ALSA offers control over *both* the "period" (between interrupts) and the total
hardware buffer size. This is unusual among audio APIs, except that JACK follows the same
convention in its ALSA backend. You can specify the period size (-p) and the number of
"periods" that make up the hardware buffer.
So if I use -p128 and -n2 it
means the kernel will buffer 256 samples per interrupt, is it?
No. What it means depends on the precise details of the device. In an ideal world, those
settings mean that the DEVICE will buffer 128 samples before issuing an interrupt, and
that its total buffer size is 256.
However, USB devices etc. do not work this way, so it translates more generically to
"ALSA will wake the client up whenever at least 128 samples of data (and/or space)
are available".
The -n 2 parameter only affects the total amount of hardware buffering, not the interval
("period") between when the application is woken.
If I used -p256 / -n2 instead ALSA would wake the client each 32 frames?
Probably not because the BBB audio cape driver apparently doesn't do -n2
but switches to -n16.
But I could be wrong and I'll risk some spanking ;)
Bye,
Jeremy
1:12 p.m.
On Tue, Mar 11, 2014 at 11:21 PM, Gianfranco Ceccolini <
gianfranco(a)portalmod.com.br> wrote:
And where does the 16 (from ALSA: use 16 periods for capture) affects?
As Jeremy noted ... JACK asks to use "N periods, or the nearest number of
periods it can". You apparently have a device that can only do 16 periods,
so when JACK asks for 2, it gets 16.
if I call jack using -p128 / -n2 and the opening
message states that ALSA
uses 16 periods for capture the sound card will buffer a total of 256
samples and ALSA will wake the client each 16 frames?
no, not at all. the total buffer size is always ACTUAL periods * period
size. So as Jeremy said, it will buffer 2048 samples. During each traversal
of that buffer, ALSA will wake the client 16 times, every 128 frames.
If I used -p256 / -n2 instead ALSA would wake the client each 32 frames?
I have no idea why you think that. As I tried to explain, the period size
(256) is the interval between when ALSA wakes the client.
10 Mar
10 Mar
3:34 p.m.
(My name is Alex, I just want to chime in real quick. Been following the
convo, have a full-year's worth of Ubuntu LAD bug reports to deliver, not
even sure how to go about it, but it's all 100% - or almost - stuff I
haven't been able to find anywhere, and the reason I wanted to chime in
until now is that this is the exact crux of the matter. I will keep in
touch, no worries about that. Can't wait to deliver the Full Report on the
Problem with LAD. 17 years computer-assisted sound design here, and I'm not
alone in what has become the bane of my existence, which is why I just
switched back to Windows, believe it or not. Don't mind me, just letting
you know I'm here, listening, at the controls, headphones on.) -A.G.
On Mon, Mar 10, 2014 at 9:51 AM, Gianfranco Ceccolini <
gianfranco(a)portalmod.com.br> wrote:
Hi Guys
sorry for the delay. carnival time here in Brasil...
Jeremy: I'm using the BB Audio Cape, v1. I'll take a look at the audio
driver, but from our tests the BBB cpu won't do the job. We're heading to
the Cubie's A20 cpu.
Paul. I'm really sorry for my lack of comprehension, but I still don't get
it. Is there a relation between the ALSA period with JACK's period?
Kind regards
Gianfranco
The MOD Team
Em 28/02/2014, à(s) 17:01, Jeremy Jongepier <jeremy(a)autostatic.com>
escreveu:
.periods_min.
On 02/28/2014 06:57 PM, Gianfranco Ceccolini
wrote:
> 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) ? I read a post by Jeremy Jongepier
about the Cubieboard2 stating
that
the
hardcoded values for the Cubie (Minimum number of periods was 4 and
minimum buffer size was 1024) where unfit for realtime operation. Why is
that so?
Hello Gianfranco,
What kind of audio interface are you using with the BBB? I'm no ALSA
expert but it seems as if the minimum period size of the driver has been
set to 16. If you have access to the source code of the driver you could
experiment with lower default values for .period_bytes_min and
Bye,
Jeremy
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3:50 p.m.
On Mon, Mar 10, 2014 at 10:33 AM, Alex Gagnon <gagnon.alex(a)gmail.com> wrote:
(My name is Alex, I just want to chime in real quick.
Been following the
convo, have a full-year's worth of Ubuntu LAD bug reports to deliver, not
even sure how to go about it, but it's all 100% - or almost - stuff I
haven't been able to find anywhere, and the reason I wanted to chime in
until now is that this is the exact crux of the matter.
what is the "exact crux of the matter" ?
3904
days inactive
3916
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
4 participants
participants (4)
-
Alex Gagnon -
Gianfranco Ceccolini -
Jeremy Jongepier -
Paul Davis