26 Jul
2017
26 Jul
'17
1:58 a.m.
jack_set_buffer_size limits frame size to the powers of 2.
The Opus codec (http://opus-codec.org/) doesn't like such frame sizes.
It defines frame sizes in milliseconds, and allows 5 ms, 10 ms, 20 ms,
25 ms, ... which in case of 48,000 sample rate are never a power of two.
It seems like Jack shouldn't be so strict in limiting frame rates to the
powers of 2.
How to solve this problem?
Yuri
26 Jul
26 Jul
2:35 a.m.
On 26.07.2017 08:58, Yuri wrote:
jack_set_buffer_size limits frame size to the powers
of 2.
The Opus codec (http://opus-codec.org/) doesn't like such frame sizes.
It defines frame sizes in milliseconds, and allows 5 ms, 10 ms, 20 ms,
25 ms, ... which in case of 48,000 sample rate are never a power of two.
It seems like Jack shouldn't be so strict in limiting frame rates to
the powers of 2.
How to solve this problem?
Hi.
Which exact version of jack are you using?
afaik this depends on the driver and soundcard used.
I just tried here with latest jack2 using alsa hdmi output, I can use
1024 buffer size as usual, but also a few non-power-of-2 values as well.
falktx@falkTX-PC:~$ jack_bufsize
buffer size = 1024 sample rate = 48000
falktx@falkTX-PC:~$ jack_bufsize 1000
jack_set_buffer_size(): Unknown error -1
falktx@falkTX-PC:~$ jack_bufsize 800
falktx@falkTX-PC:~$ jack_bufsize 802
jack_set_buffer_size(): Unknown error -1
falktx@falkTX-PC:~$ jack_bufsize 870
jack_set_buffer_size(): Unknown error -1
falktx@falkTX-PC:~$ jack_bufsize 880
So some of those buffer sizes work, some do not.
GUIs usually show only power of 2 values because they're safer to use (I
mean, more likely to actually work).
Also some jack applications sadly were made with the expectation that
power-of-2 buffer sizes will be used...
But for such cases the application can return an error on start and
during the jack-buffersize-callback, to force jack to be under
power-of-2 sizes.
Anyway, at least in latest jack2 this is not a problem.
Not sure about jack1, but I believe the same is true.
2:39 a.m.
On 07/26/2017 00:35, Filipe Coelho wrote:
So some of those buffer sizes work, some do not.
GUIs usually show only power of 2 values because they're safer to use
(I mean, more likely to actually work).
Also some jack applications sadly were made with the expectation that
power-of-2 buffer sizes will be used...
But for such cases the application can return an error on start and
during the jack-buffersize-callback, to force jack to be under
power-of-2 sizes.
Anyway, at least in latest jack2 this is not a problem.
Not sure about jack1, but I believe the same is true.
I use Jack1. power of 2 check is hardcoded in the server.
if (!jack_power_of_two (nframes)) {
jack_error ("buffer size %" PRIu32 " not a power of
2",
nframes);
return EINVAL;
}
Yuri
3 a.m.
On 26.07.2017 09:39, Yuri wrote:
On 07/26/2017 00:35, Filipe Coelho wrote:
This seems like a leftover that nobody cared too much about just yet.
Quickly going through the driver code I see that portaudio and coreaudio
drivers have this restriction when starting up jackd, but alsa has that
part disabled.
See
https://github.com/jackaudio/jack1/blob/cb654ada4ecfd6a95b9fb648ebd33c5af46…
The OSS code does not seem to have this restriction when starting jackd
either.
So I think we can remove this for at least ALSA and OSS drivers,
allowing them to change buffer size.
So some of those buffer sizes work, some do not.
GUIs usually show only power of 2 values because they're safer to use
(I mean, more likely to actually work).
Also some jack applications sadly were made with the expectation that
power-of-2 buffer sizes will be used...
But for such cases the application can return an error on start and
during the jack-buffersize-callback, to force jack to be under
power-of-2 sizes.
Anyway, at least in latest jack2 this is not a problem.
Not sure about jack1, but I believe the same is true.
I use Jack1. power of 2 check is hardcoded in the server.
if (!jack_power_of_two (nframes)) {
jack_error ("buffer size %" PRIu32 " not a power of
2",
nframes);
return EINVAL;
}
Yuri
2:50 a.m.
On Tue, 25 Jul 2017 23:58:25 -0700, Yuri wrote:
It defines frame sizes in milliseconds, and allows 5
ms, 10 ms, 20 ms,
25 ms, ... which in case of 48,000 sample rate are never a power of
two.
The unit "ms" doesn't fit, since "ms" is the unit for the
latency.
Actually you have the unit "Hz" for the sample rate and you have
"frames".
Given that you could calculate.
x frames / y Hz sample rate = n seconds latency
e.g.
128 frames / 44100 Hz = 0.0029 sec
IOW 2.9 ms.
You perhaps calculated this way
0.005 sec * 44800 Hz = 224 frames
but actually we could assume the 5 ms are a rounded value, since
actually "frames" don't have the unit "ms".
1:36 p.m.
On Tue, Jul 25, 2017 at 11:58:25PM -0700, Yuri wrote:
The Opus codec (http://opus-codec.org/) doesn't
like such frame
sizes. It defines frame sizes in milliseconds, and allows 5 ms, 10
ms, 20 ms, 25 ms, ... which in case of 48,000 sample rate are never
a power of two.
It seems like Jack shouldn't be so strict in limiting frame rates to
the powers of 2.
How to solve this problem?
Just put some buffering between the jack callback and the codec.
You will need this anyway, as you can't assume that the codec and
whatever is at the other end of the codec (file, network,...) is
real-time safe. In practice you can be pretty sure it won't be.
Jack is typically used to interconnect a soundcard and any number
of applications. What if two applications have different preferred
frame sizes ? Which one should win and impose its choice on all
the others ? Forcing Jack to use a frame size required by any
app is not a practical solution except in some trivial cases,
e.g. when the app is the only one using Jack.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2466
days inactive
2467
days old
jackaudio@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Filipe Coelho -
Fons Adriaensen -
Ralf Mardorf -
Yuri