Re: [Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

On 7 September 2015 at 15:32, Kevin Reid  wrote:

> On Sep 7, 2015, at 5:42, Murray Thomson 
> wrote:
>
> >> 1. Using some method to force the wav source and audio source to match
> sample rates. Specifically, you could use a “Multiply by Matrix” block to
> replace the function of the Selector entirely: give it a matrix value of
> either ((1, 0),) or ((0, 1),) to select just one input.
> >
> > Can I make a multiply to matrix block have several inputs and one only
> output? If not, I was thinking on multiplying one of them by a constant
> block zero and then adding both outputs. Would this be a valid workaround?
>
> The number of inputs and outputs are determined by the dimensions of the
> matrix value entered. If you put in ((0, 1,),) with the comma (actually, I
> just remembered you can write [[0, 1]] as well and you don't have to worry
> about the extra comma (blame Python for that)) then it will have 2 inputs
> and 1 output. And, for example, if you wrote [[0], [1]], then it would have
> 1 input and 2 outputs.
>
> By the way, you can of course enter any numeric values to scale the inputs
> as you like, so for example you could use [[0, 0]] as a “mute” mode, or
> enter an arbitrary number as a gain control, if you wanted one.
>
> (If you did have an extra output that you couldn't get rid of, a null sink
> would be simplest there.)
>
> That's great help Kevin. Explains and solves my issue. Thanks!

> --
> Kevin Reid  
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Kevin Reid]

On Sep 7, 2015, at 5:42, Murray Thomson  wrote:

>> 1. Using some method to force the wav source and audio source to match 
>> sample rates. Specifically, you could use a “Multiply by Matrix” block to 
>> replace the function of the Selector entirely: give it a matrix value of 
>> either ((1, 0),) or ((0, 1),) to select just one input.
>  
> Can I make a multiply to matrix block have several inputs and one only 
> output? If not, I was thinking on multiplying one of them by a constant block 
> zero and then adding both outputs. Would this be a valid workaround?

The number of inputs and outputs are determined by the dimensions of the matrix 
value entered. If you put in ((0, 1,),) with the comma (actually, I just 
remembered you can write [[0, 1]] as well and you don't have to worry about the 
extra comma (blame Python for that)) then it will have 2 inputs and 1 output. 
And, for example, if you wrote [[0], [1]], then it would have 1 input and 2 
outputs.

By the way, you can of course enter any numeric values to scale the inputs as 
you like, so for example you could use [[0, 0]] as a “mute” mode, or enter an 
arbitrary number as a gain control, if you wanted one.

(If you did have an extra output that you couldn't get rid of, a null sink 
would be simplest there.)

-- 
Kevin Reid  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

On 3 September 2015 at 17:04, Murray Thomson 
wrote:

>
> On 3 September 2015 at 16:43, Kevin Reid  wrote:
>
>> On Sep 3, 2015, at 8:24, Murray Thomson 
>> wrote:
>>
>> > Even selecting source and sink from the audio card, if I have a wav
>> file playing in another input of the selector without a throttle, the CPU
>> goes to 100%. To avoid it I put the wav file, then the throttle and the the
>> selector. I've read that is bad practice but I couldn't reduce the CPU
>> usage in any other way.
>>
>> (Please make sure to CC the mailing list in your replies.)
>>
>
> Sorry, it was a mistake. For the list, just clarify that
> I have an audio sink using the same audio card @ 96 KHz with the settings
> set to OK to block YES.
>
>
>> Ah. I just looked at the implementation of the selector block, and found
>> that its documentation lies. It does not leave its unused inputs
>> “disconnected” (which is actually good, because that would cause errors in
>> some cases), but connects them to null sinks (which consume all the input
>> they're given).
>>
>> So, using a throttle is a workaround for this. (The cost is that since
>> the throttle's timing is based on the CPU clock, not the audio card clock,
>> you'll occasionally get either underrun or overrun.)
>>
>> Here are some better solutions, from simplest to best:
>>
>> 1. Using some method to force the wav source and audio source to match
>> sample rates. Specifically, you could use a “Multiply by Matrix” block to
>> replace the function of the Selector entirely: give it a matrix value of
>> either ((1, 0),) or ((0, 1),) to select just one input.
>>
>
Can I make a multiply to matrix block have several inputs and one only
output? If not, I was thinking on multiplying one of them by a constant
block zero and then adding both outputs. Would this be a valid workaround?


>
>> 2. Modifying, or creating a replacement for, the selector block which
>> does not connect to a null sink but rather to a block of some sort which
>> never accepts any data and so stops that branch of the flowgraph. (I don't
>> think such a block actually exists, but it could, and there might be
>> something else that acts like it.)
>>
>> 3. Actually remove from the flowgraph whichever of the wav source and
>> audio source are not currently in use. This is the most general, efficient,
>> and straightforward solution, but unfortunately it cannot be built within
>> GNU Radio Companion -- you must write some C++ or Python code. If you don't
>> want to stop using GRC entirely, you could isolate that part by putting the
>> connection changing logic inside a hierarchical block; this would be
>> similar to the selector block itself, but it would be a source, which has
>> the wav and audio sources "built into" it. Alternatively, you could write
>> your main()/top block as a Python program and put the _rest_ of your logic
>> (the demodulator and sink) into a GRC block which is used by the Python
>> program. Either way works.
>>
>> Thanks, I'll try these solutions tomorrow. I assume that they also apply
> to add a constant block into a selector block.
>
>
>> --
>> Kevin Reid  
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Kevin Reid]

On Sep 3, 2015, at 8:24, Murray Thomson  wrote:

> Even selecting source and sink from the audio card, if I have a wav file 
> playing in another input of the selector without a throttle, the CPU goes to 
> 100%. To avoid it I put the wav file, then the throttle and the the selector. 
> I've read that is bad practice but I couldn't reduce the CPU usage in any 
> other way.

(Please make sure to CC the mailing list in your replies.)

Ah. I just looked at the implementation of the selector block, and found that 
its documentation lies. It does not leave its unused inputs “disconnected” 
(which is actually good, because that would cause errors in some cases), but 
connects them to null sinks (which consume all the input they're given).

So, using a throttle is a workaround for this. (The cost is that since the 
throttle's timing is based on the CPU clock, not the audio card clock, you'll 
occasionally get either underrun or overrun.)

Here are some better solutions, from simplest to best:

1. Using some method to force the wav source and audio source to match sample 
rates. Specifically, you could use a “Multiply by Matrix” block to replace the 
function of the Selector entirely: give it a matrix value of either ((1, 0),) 
or ((0, 1),) to select just one input.

2. Modifying, or creating a replacement for, the selector block which does not 
connect to a null sink but rather to a block of some sort which never accepts 
any data and so stops that branch of the flowgraph. (I don't think such a block 
actually exists, but it could, and there might be something else that acts like 
it.)

3. Actually remove from the flowgraph whichever of the wav source and audio 
source are not currently in use. This is the most general, efficient, and 
straightforward solution, but unfortunately it cannot be built within GNU Radio 
Companion -- you must write some C++ or Python code. If you don't want to stop 
using GRC entirely, you could isolate that part by putting the connection 
changing logic inside a hierarchical block; this would be similar to the 
selector block itself, but it would be a source, which has the wav and audio 
sources "built into" it. Alternatively, you could write your main()/top block 
as a Python program and put the _rest_ of your logic (the demodulator and sink) 
into a GRC block which is used by the Python program. Either way works.

-- 
Kevin Reid  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

On 3 September 2015 at 16:43, Kevin Reid  wrote:

> On Sep 3, 2015, at 8:24, Murray Thomson 
> wrote:
>
> > Even selecting source and sink from the audio card, if I have a wav file
> playing in another input of the selector without a throttle, the CPU goes
> to 100%. To avoid it I put the wav file, then the throttle and the the
> selector. I've read that is bad practice but I couldn't reduce the CPU
> usage in any other way.
>
> (Please make sure to CC the mailing list in your replies.)
>

Sorry, it was a mistake. For the list, just clarify that
I have an audio sink using the same audio card @ 96 KHz with the settings
set to OK to block YES.


> Ah. I just looked at the implementation of the selector block, and found
> that its documentation lies. It does not leave its unused inputs
> “disconnected” (which is actually good, because that would cause errors in
> some cases), but connects them to null sinks (which consume all the input
> they're given).
>
> So, using a throttle is a workaround for this. (The cost is that since the
> throttle's timing is based on the CPU clock, not the audio card clock,
> you'll occasionally get either underrun or overrun.)
>
> Here are some better solutions, from simplest to best:
>
> 1. Using some method to force the wav source and audio source to match
> sample rates. Specifically, you could use a “Multiply by Matrix” block to
> replace the function of the Selector entirely: give it a matrix value of
> either ((1, 0),) or ((0, 1),) to select just one input.
>
> 2. Modifying, or creating a replacement for, the selector block which does
> not connect to a null sink but rather to a block of some sort which never
> accepts any data and so stops that branch of the flowgraph. (I don't think
> such a block actually exists, but it could, and there might be something
> else that acts like it.)
>
> 3. Actually remove from the flowgraph whichever of the wav source and
> audio source are not currently in use. This is the most general, efficient,
> and straightforward solution, but unfortunately it cannot be built within
> GNU Radio Companion -- you must write some C++ or Python code. If you don't
> want to stop using GRC entirely, you could isolate that part by putting the
> connection changing logic inside a hierarchical block; this would be
> similar to the selector block itself, but it would be a source, which has
> the wav and audio sources "built into" it. Alternatively, you could write
> your main()/top block as a Python program and put the _rest_ of your logic
> (the demodulator and sink) into a GRC block which is used by the Python
> program. Either way works.
>
> Thanks, I'll try these solutions tomorrow. I assume that they also apply
to add a constant block into a selector block.


> --
> Kevin Reid  
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Jeff Long]

You can't have a throttle block inline with an audio source. Did you try 
putting the throttle between the file source and the selector?


(I haven't actually tried this)

- Jeff

On 09/03/2015 10:22 AM, Murray Thomson wrote:

Hi,

I'm using a flow graph with no GUI to demodulate a signal. I have a
selector block that allows me to select the source of the signal between
the audio card and a wav file. I can change the source using an xmlrpc
server/client.

If I don't use a throttle block with the wav file, the flow graph takes
all the CPU and the server/client is very slow.
If I put a throttle, I get audio underruns when using the audio card.
Same problem for a constant source.

Can anyone please recommend a better way to do this?

Cheers,
Murray


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Kevin Reid]

On Sep 3, 2015, at 7:22, Murray Thomson  wrote:

> I'm using a flow graph with no GUI to demodulate a signal. I have a selector 
> block that allows me to select the source of the signal between the audio 
> card and a wav file. I can change the source using an xmlrpc server/client.
> 
> If I don't use a throttle block with the wav file, the flow graph takes all 
> the CPU and the server/client is very slow.
> If I put a throttle, I get audio underruns when using the audio card. Same 
> problem for a constant source.

You can't get audio underruns from an audio _source_, so I assume you have an 
audio _sink_ that you didn't mention in your description that you're using in 
both modes for the output of the demodulator.

It sounds like you have the audio _sink_ set not to block. In its properties, 
enable the “OK to Block” checkbox. Do not use a throttle.

This will allow the audio sink to limit the data rate from the wav source (by 
backpressure). When an audio source is being used, if the source and sink are 
from the same sound card and have the same sample rate requested then they 
should be happy too.

-- 
Kevin Reid  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Throttle block form wav files

[Jeon]

Dear Murray Thomson,

Which value did you set as a throttle.
Typically 48 kHz or something... But I asked this just in case.

Or this thread might help (
https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00517.html )

Regards,
Jeon.

2015-09-03 23:22 GMT+09:00 Murray Thomson :

> Hi,
>
> I'm using a flow graph with no GUI to demodulate a signal. I have a
> selector block that allows me to select the source of the signal between
> the audio card and a wav file. I can change the source using an xmlrpc
> server/client.
>
> If I don't use a throttle block with the wav file, the flow graph takes
> all the CPU and the server/client is very slow.
> If I put a throttle, I get audio underruns when using the audio card. Same
> problem for a constant source.
>
> Can anyone please recommend a better way to do this?
>
> Cheers,
> Murray
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Throttle block form wav files

[Murray Thomson]

Hi,

I'm using a flow graph with no GUI to demodulate a signal. I have a
selector block that allows me to select the source of the signal between
the audio card and a wav file. I can change the source using an xmlrpc
server/client.

If I don't use a throttle block with the wav file, the flow graph takes all
the CPU and the server/client is very slow.
If I put a throttle, I get audio underruns when using the audio card. Same
problem for a constant source.

Can anyone please recommend a better way to do this?

Cheers,
Murray
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio