discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)
Date: Sun, 6 Nov 2016 19:32:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

Hi Fons,

luckily, you wouldn't have to worry about SWIG and python at all – the
current audio sinks are pure C++, and the wrapping is done behind the
scenes. If you happen to figure out what goes wrong in the jack_sink,
I'm positive you'll get all the help you need to make things work!

> Is there any way to create an audio sink out-of-tree and 
> use it with a binary install ?
That's of course also possible, since a sink is really just like any
other block.
However, fixing an audio sink should, in my opinion, be rewarded by
upstreaming the fix.
> Why would a sink (which doesn't output anything to another
> gr module) ever use the 'noutput_items' argument to work() ?
So, to clarify: noutput_items is the *maximum* number of output items a
call to work might produce at a time. For a normal block, this is the
amount of space in the output buffer. For a sync block, where the number
of items produced on the output is the same as the number of items
consumed on the input, it's min(input items available, output item space
available).
under the hood, sinks are sync_blocks. Now, a sink has zero output
ports, so "producing" let's say 13 items just means consuming that many.
The same applies to sources (where there's no input streams, so
producing N items on the output stream and consuming on "all" zero input
streams is equivalent).

So, for a sink, noutput_items actually is nothing but the number of
available input items. You can consume those or less than those, and the
actual amount of items you consumed is signaled back to the scheduler by
returning that number.

Ciao,
Marcus

On 06.11.2016 18:29, Fons Adriaensen wrote:
> On Sun, Nov 06, 2016 at 03:58:43PM +0100, Marcus Müller wrote:
>
>> Well, obviously, there's interest, but I'd say we all agree that we'd
>> need someone to fix the Jack interface first – we simply don't have that
>> person at our disposal. At this point, it seems you're the one most
>> prolific with Jack on the mailing list... :/
> And probably the least prolific with gr.
>
> Which is one reason why I'm a bit reluctant to work on this.
> Another one is the way gr is written. I'm used to C++, python,
> and writing C/C++ extensions for Python. But I usually stay
> well clear from things like boost and swig (and python2).
>
> Is there any way to create an audio sink out-of-tree and 
> use it with a binary install ?
>
> Looking at jack_sink.cc I find in work():
>
>     work_size = noutput_items * sizeof(sample_t);
>     while (work_size > 0)
>     {
>         // write some data to a queue
>         work_size -= write_size;
>     }
>
> Why would a sink (which doesn't output anything to another
> gr module) ever use the 'noutput_items' argument to work() ?
>
> Ciao,
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]