14 Sep
2017
14 Sep
'17
7:10 p.m.
I want to know the optimal buffering which i can use for designing my
application.
My use case is as follows, I receive digital radio signals through a tuner
and does the channel and audio decoding in separate threads.
Finally the audio is send to jack callback and played out.
How much of buffering is enough for real time streaming between threads.
I want keep the optimal buffering between these threads.
Please suggest guidelines for using with Jack.
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
14 Sep
14 Sep
7:40 p.m.
JACK has no requirements other than that you can run your process()
callback without blocking, every time.
How much buffering needs to exist to make sure that can happen depends
hugely on what the non-RT part of things is doing. For comparison, when the
non-RT part does disk i/o, you need to be ready for potentially several
seconds of delay in refilling (or emptying) buffers. If the disk i/o
wasn't there, the buffering requirements would be much smaller.
On Thu, Sep 14, 2017 at 1:10 PM, benravin <ben.alex(a)outlook.com> wrote:
I want to know the optimal buffering which i can use for designing my
application.
My use case is as follows, I receive digital radio signals through a tuner
and does the channel and audio decoding in separate threads.
Finally the audio is send to jack callback and played out.
How much of buffering is enough for real time streaming between threads.
I want keep the optimal buffering between these threads.
Please suggest guidelines for using with Jack.
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-
f58952.html
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
7:56 p.m.
> JACK has no requirements other than that you can
run your process()
callback without blocking, every time.
How much buffering needs to exist to make sure that can happen depends
hugely on what the non-RT part of things is doing. For comparison, when the
non-RT part does disk i/o, you need to be ready for potentially several
seconds of delay in refilling (or emptying) buffers. If the disk i/o
wasn't there, the buffering requirements would be much smaller.
I don't have any disk I/O operations, I receive data from a USB dongle at a
constant rate.
If I have 'N' clients running, then the time I can spend on each callback
for processing is
= (audio_buffer_period - ( process_time * N ) )
Is that correct ?
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
8:24 p.m.
JACK's "DSP load" measurement generally cannot go above 80% before issues
happen on almost all systems and platforms.
if the buffer size is 10msec, then the total time for JACK to execute its
own code and all clients needs to be below about 8msec.
On Thu, Sep 14, 2017 at 1:56 PM, benravin <ben.alex(a)outlook.com> wrote:
> JACK has
no requirements other than that you can run your process()
callback without
blocking, every time.
How much buffering needs to exist to make sure that can happen depends
hugely on what the non-RT part of things is doing. For comparison, when the
non-RT part does disk i/o, you need to be ready for potentially several
seconds of delay in refilling (or emptying) buffers. If the disk i/o
wasn't there, the buffering requirements would be much smaller.
I don't have any disk I/O operations, I receive data from a USB dongle at a
constant rate.
If I have 'N' clients running, then the time I can spend on each callback
for processing is
= (audio_buffer_period - ( process_time * N ) )
Is that correct ?
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-
f58952.html
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
15 Sep
15 Sep
12:08 p.m.
On Thu, Sep 14, 2017 at 10:56:14AM -0700, benravin wrote:
I don't have any disk I/O operations, I receive data from a USB dongle at a
constant rate.
Hi! It sounds like you're writing an SDR. You might be interested in
lysdr:
http://gordonjcp.github.io/lysdr/
--
Gordonjcp MM0YEQ
6:37 p.m.
Hi Gordon,
Thanks for the link. In fact I'm developing broadcast receiver for digital
radio standards like DAB, ISDB-T etc. I had a look at your source code. By
using mplayer the IQ output will be fed into jack input port which is the
capture port right ?
DAB frame duration is 24ms which corresponds to 24ms of audio. But the
audio frame size can be max 60ms. Can JACK support different buffer lengths
for each clients ?
-ben
gordonjcp wrote
On Thu, Sep 14, 2017 at 10:56:14AM -0700, benravin
wrote:
I don't have any disk I/O operations, I receive data from a USB dongle at
a
constant rate.
Hi! It sounds like you're writing an SDR. You might be interested in
lysdr:
http://gordonjcp.github.io/lysdr/
--
Gordonjcp MM0YEQ
_______________________________________________
Linux-audio-dev mailing list Linux-audio-dev@.linuxaudio
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
7:02 p.m.
On Fri, Sep 15, 2017 at 09:37:43AM -0700, benravin wrote:
Hi Gordon,
Thanks for the link. In fact I'm developing broadcast receiver for digital
radio standards like DAB, ISDB-T etc. I had a look at your source code. By
using mplayer the IQ output will be fed into jack input port which is the
capture port right ?
That's correct. That allows me to have a prerecorded IQ capture file
that I can play back without an off-air signal.
I wrote lysdr in the first place because converting Quisk to accept
prerecorded files was such a massive pain in the arse, and I wanted to
demo Software-Defined Radio at my local amateur radio club with no
aerial in the distinctly RF-hostile centre of Glasgow :-D
DAB frame duration is 24ms which corresponds to 24ms
of audio. But the
audio frame size can be max 60ms. Can JACK support different buffer lengths
for each clients ?
You'll need to talk me through that a bit. Does that mean that you end
up buffering more input frames than you're playing out? Or do you have
60ms output from a 24ms input that arrives somewhere in a 60ms
timeslice?
--
Gordonjcp MM0YEQ
7:13 p.m.
>You'll need to talk me through that a bit.
Does that mean that you end
>up buffering more input frames than you're playing out? Or do you have
>>60ms output from a 24ms input that arrives somewhere in a 60ms
>timeslice?
--
Gordonjcp MM0YEQ
No, 24ms of transmission frame corresponds to 24ms of audio, so if an audio
frame size of duration 60ms is coded, then after receiving three
transmission frames (24 x 3 = 72ms) only audio decoder can start.
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
14 Sep
14 Sep
8 p.m.
I don't have any disk I/O operations, I receive data from a USB dongle at a
constant rate.
If I have 'N' clients running, then the time I can spend on each callback
for processing is
= (audio_buffer_period - ( process_time * N ) )
Is that correct ?
-ben
________________________________
From: Paul Davis <paul(a)linuxaudiosystems.com>
Sent: Thursday, September 14, 2017 11:10 PM
To: benravin
Cc: linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] Jack buffer requirements
JACK has no requirements other than that you can run your process() callback without
blocking, every time.
How much buffering needs to exist to make sure that can happen depends hugely on what the
non-RT part of things is doing. For comparison, when the non-RT part does disk i/o, you
need to be ready for potentially several seconds of delay in refilling (or emptying)
buffers. If the disk i/o wasn't there, the buffering requirements would be much
smaller.
On Thu, Sep 14, 2017 at 1:10 PM, benravin
<ben.alex@outlook.com<mailto:ben.alex@outlook.com>> wrote:
I want to know the optimal buffering which i can use for designing my
application.
My use case is as follows, I receive digital radio signals through a tuner
and does the channel and audio decoding in separate threads.
Finally the audio is send to jack callback and played out.
How much of buffering is enough for real time streaming between threads.
I want keep the optimal buffering between these threads.
Please suggest guidelines for using with Jack.
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org<mailto:Linux-audio-dev@lists.linuxaudio.org>
https://lists.linuxaudio.org/listinfo/linux-audio-dev
7:54 p.m.
On Sep 14, 2017, at 13:10, benravin <ben.alex(a)outlook.com> wrote:
How much of buffering is enough for real time
streaming between threads.
I want keep the optimal buffering between these threads.
That, as they say, is the $64,000 question! :)
In addition to the advice already offered by Paul, a lot depends on how important latency
is to your specific application. You mentioned that the audio was coming off of a radio
receiver? Modern DAB transmission air chains already typically incur several *seconds* of
latency, so if that’s your use case, then I’d go ahead and buffer up a couple of seconds
more on the receive end. Cheap insurance. OTOH, if minimizing latency is important, then
the answer to your question is “buffer as little as you can get away with without
incurring xruns”. The only way to determine where that sweet spot is located is by
testing your code on its target hardware.
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| -- Cicero |
|----------------------------------------------------------------------|
2408
days inactive
2409
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
5 participants
participants (5)
-
Benny Alexandar -
benravin
-
Fred Gleason -
Gordonjcp -
Paul Davis