[LAD] Jack buffer requirements

[benravin]

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

[Paul Davis]

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 <***@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-***@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>

[benravin]

>> 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

[Paul Davis]

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 <***@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-***@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>

[Gordonjcp]

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

[benravin]

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-***@.linuxaudio

> https://lists.linuxaudio.org/listinfo/linux-audio-dev





--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html

[Gordonjcp]

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

[benravin]

>>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

[Benny Alexandar]

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 <***@linuxaudiosystems.com>
Sent: Thursday, September 14, 2017 11:10 PM
To: benravin
Cc: linux-audio-***@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 <***@outlook.com<mailto:***@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

[Fred Gleason]

On Sep 14, 2017, at 13:10, benravin <***@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 |
|----------------------------------------------------------------------|