Jack buffer requirements

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

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 <[hidden email]> 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
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

Fred Gleason-2
In reply to this post by benravin
On Sep 14, 2017, at 13:10, benravin <[hidden email]> 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                    |
|----------------------------------------------------------------------|

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

benravin
In reply to this post by 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.


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
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

benravin
In reply to this post by Paul Davis
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 <[hidden email]>
Sent: Thursday, September 14, 2017 11:10 PM
To: benravin
Cc: [hidden email]
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 <[hidden email]> 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
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

Paul Davis
In reply to this post by benravin
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 <[hidden email]> 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
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

gordonjcp
In reply to this post by benravin
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
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

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

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





--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

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

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Jack buffer requirements

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
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
-ben