The buffer warnings are expected and nothing you should have to worry
about. It stems from the (admittedly unlucky) design choice to use vectors
instead of single samples. I didn't see that error before, though. Are you
on a machine with very limited memory?

This thread [1] describes a similar behavior, maybe you can try the advised
steps and report back if it helped.

[1]
http://www.marshut.com/ihktyk/invalid-argument-failed-to-allocate-buffer.html





2014-03-31 21:29 GMT+02:00 Jordan Johnson <[email protected]>:

> ....and now a problem with the buffer apparently.
>
> Using Volk machine: sse4_2_64_orc
> gr::buffer::allocate_buffer: warning: tried to allocate
>    104 items of size 630. Due to alignment requirements
>    2048 were allocated.  If this isn't OK, consider padding
>    your structure to a power-of-two bytes.
>    On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
>    7 items of size 8390. Due to alignment requirements
>    2048 were allocated.  If this isn't OK, consider padding
>    your structure to a power-of-two bytes.
>    On this platform, our allocation granularity is 4096 bytes.
> gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument
> gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument
> gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument
> gr::buffer::allocate_buffer: failed to allocate buffer of size 16780 KB
> gr::buffer::allocate_buffer: warning: tried to allocate
> ............
>
>
>
> On Mon, Mar 31, 2014 at 12:06 PM, Jordan Johnson 
> <[email protected]>wrote:
>
>> I'm willing to wager that's why you disabled them.  :p
>> Just to be sure, the only WAV block I have on is the WAV sink. That being
>> a sink, it shouldn't be making a fuss over a file it hasn't written not
>> being there. I use jack as the audio input through the regular audio source
>> block; no JACK messages that would indicate an issue there, though it
>> doesn't run long enough to even appear as a connection.
>>
>> Looking at the py files, the pys it has in its execute commands are there
>> too.
>>
>> Hmmmmm....
>>
>>
>> On Mon, Mar 31, 2014 at 12:00 PM, Felix W. 
>> <[email protected]>wrote:
>>
>>> I'm not sure if it's the .py file it's looking for or the sound (*.wav)
>>> file you want to transmit. Did you maybe forget to specify one? Happened to
>>> me all the time ;).
>>>
>>>
>>> 2014-03-31 20:42 GMT+02:00 Jordan Johnson <[email protected]>:
>>>
>>>> Patched and everything looks fine. But of course, the ride doesn't end.
>>>> :)
>>>>
>>>> Executing:
>>>> "/home/ushio/Code/gr-drm-stable/flow_graphs/drm_transmitter_64sm_16.py"
>>>> [Errno 2] No such file or directory
>>>>
>>>> Even though in thunar and through ls it is obviously exactly where it
>>>> wants it to be. They are executable and their permissions seem fine. Am I
>>>> doing something wrong? Each transmitter graph now has its own py file that
>>>> it doesn't want to find for some reason.
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 11:25 AM, Felix W. <[email protected]
>>>> > wrote:
>>>>
>>>>> This is actually a GNU Radio bug where XML files are not generated
>>>>> correctly. At the vlen parameter of the hier blocks a $ is missing. This
>>>>> patch from Sebastian Koslowski should fix it:
>>>>> https://github.com/skoslowski/gnuradio/commit/227478f343f50431d238a16d93afd8a40ef9e06e
>>>>>
>>>>>
>>>>> Just apply the patch and create the hier blocks once again. Then it
>>>>> all should work. Tell me, if it does not!
>>>>>
>>>>> Felix
>>>>>
>>>>>
>>>>> 2014-03-31 19:59 GMT+02:00 Jordan Johnson <[email protected]>:
>>>>>
>>>>>> Nope, have not mad any modifications to any of the ones I want to.
>>>>>> Here are some screenshots if this may give you an idea.
>>>>>>
>>>>>>
>>>>>> https://lh6.googleusercontent.com/-598cz4JydqE/Uzmrxd3Y0_I/AAAAAAAAwZs/DnOG6Ol9eFA/w1021-h512-no/Screenshot+-+03312014+-+10%253A52%253A29+AM.png
>>>>>>
>>>>>>
>>>>>> https://lh6.googleusercontent.com/-Os9OqtHLpEE/Uzmrxqbl04I/AAAAAAAAwZw/Ea85203_qyM/w931-h524-no/Screenshot+-+03312014+-+10%253A51%253A40+AM.png
>>>>>>
>>>>>> I recall having a similar issue with some of my FM and ATSC stuff
>>>>>> but....for the life of me cannot remember what the underlying catalyst 
>>>>>> was.
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 31, 2014 at 2:21 AM, Felix W. <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Ok, so this looks like the hierarchical blocks are not properly
>>>>>>> parameterized. In my transmitter, I'm always processing whole vectors of
>>>>>>> specific data types, so each block uses input sizes of
>>>>>>> vector_length*sizeof(data_type). What GRC is reporting is that all MLC
>>>>>>> blocks use vector length 1, therefore the input sizes vary between 1
>>>>>>> (sizeof(char)) and 8 (sizeof(gr_complex)). Please have a look at the MLC
>>>>>>> blocks in GRC and see if all the fields, especially the ones named 
>>>>>>> "Input
>>>>>>> vector length" and "Output vector length" are filled and not marked with
>>>>>>> red. Please also check if the variable "tp" (in the upper left corner,
>>>>>>> right next to the "Options" block) is written in black. I'm assuming you
>>>>>>> didn't change anything in the flow graph so far.
>>>>>>>
>>>>>>> Felix
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Felix W. <[email protected]>
>>>>>>> Date: 2014-03-31 10:20 GMT+02:00
>>>>>>> Subject: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available
>>>>>>> To: Jordan Johnson <[email protected]>
>>>>>>>
>>>>>>>
>>>>>>> About the "no module named drm" error: Obviously the needed library
>>>>>>> is not found. Normally, a "sudo ldconfig" should solve this, but only 
>>>>>>> if it
>>>>>>> can find it. So your library has to be placed somewhere in the standard
>>>>>>> paths like "usr/local/lib", where also the other GNU Radio libraries are
>>>>>>> located. Looking at the man page of "ldconfig" it seems that you can 
>>>>>>> also
>>>>>>> give it a path to your shared library. Maybe that's already enough.
>>>>>>>
>>>>>>> Because you couldn't execute the hierarchical blocks the respective
>>>>>>> files were not generated and this is why they are missing when you open 
>>>>>>> the
>>>>>>> transmitter flow graph. GRC is just telling you that the MLC blocks are
>>>>>>> missing and therefore it can't connect them to the adjacent blocks.
>>>>>>>
>>>>>>> To sum it up: Try to find out where the working GNU Radio files such
>>>>>>> as XML files and shared libraries are placed and install the DRM stuff
>>>>>>> there. Unfortunately, I'm not familiar with the differences between Arch
>>>>>>> and Ubuntu so I'm sorry that I can't give you more detailed 
>>>>>>> instructions.
>>>>>>>
>>>>>>> Keep me posted about your progress!
>>>>>>>
>>>>>>>
>>>>>>> 2014-03-31 9:56 GMT+02:00 Jordan Johnson <[email protected]>:
>>>>>>>
>>>>>>> Shoulda figured. Arch likes to put things in /usr/local/share as
>>>>>>>> opposed to /usr/local.  Has caused problems with some programs in the 
>>>>>>>> past.
>>>>>>>> However, it looks like it put things in several wrong spots. As 
>>>>>>>> running the
>>>>>>>> heir-blocks graphs gets me this:
>>>>>>>>
>>>>>>>> "No module named drm"
>>>>>>>>
>>>>>>>> No missing blocks there, DRM section appears.
>>>>>>>>
>>>>>>>> On top of it, on opening the transmitter flowgraphs, I am
>>>>>>>> confronted with this:
>>>>>>>>
>>>>>>>> >>> Error: Block key "drm_mlc_16qam_vbvc" not found in Platform -
>>>>>>>> grc(GNU Radio Companion)
>>>>>>>> >>> Error: Block key "drm_mlc_64qam_sm_vbvc" not found in Platform
>>>>>>>> - grc(GNU Radio Companion)
>>>>>>>> >>> Error: Block key "drm_mlc_4qam_vbvc" not found in Platform -
>>>>>>>> grc(GNU Radio Companion)
>>>>>>>> >>> Error: Connection between drm_mlc_64qam_sm_vbvc_0(0) and
>>>>>>>> drm_interleaver_vcvc_0(0) could not be made.
>>>>>>>>     source block id "drm_mlc_64qam_sm_vbvc_0" not in block ids
>>>>>>>> >>> Error: Connection between drm_scrambler_vbvb_0(0) and
>>>>>>>> drm_mlc_64qam_sm_vbvc_0(0) could not be made.
>>>>>>>>     sink block id "drm_mlc_64qam_sm_vbvc_0" not in block ids
>>>>>>>> >>> Error: Connection between drm_scrambler_vbvb_0_1(0) and
>>>>>>>> drm_mlc_16qam_vbvc_0(0) could not be made.
>>>>>>>>     sink block id "drm_mlc_16qam_vbvc_0" not in block ids
>>>>>>>> >>> Error: Connection between drm_mlc_16qam_vbvc_0(0) and
>>>>>>>> cell_mapping_vcvc_0(1) could not be made.
>>>>>>>>     source block id "drm_mlc_16qam_vbvc_0" not in block ids
>>>>>>>> >>> Error: Connection between drm_scrambler_vbvb_0_0(0) and
>>>>>>>> drm_mlc_4qam_vbvc_0_0(0) could not be made.
>>>>>>>>     sink block id "drm_mlc_4qam_vbvc_0_0" not in block ids
>>>>>>>> >>> Error: Connection between drm_mlc_4qam_vbvc_0_0(0) and
>>>>>>>> blocks_stream_to_vector_0_0(0) could not be made.
>>>>>>>>     source block id "drm_mlc_4qam_vbvc_0_0" not in block ids
>>>>>>>>
>>>>>>>> ...should I re-make with different locations?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 31, 2014 at 12:32 AM, Felix W. <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Jordan,
>>>>>>>>>
>>>>>>>>> Nice to hear that you can use my code! I just tried to reproduce
>>>>>>>>> your problem on my machine (Ubuntu 12.10, GNU Radio 
>>>>>>>>> v3.7.2.1-263-g78551a56)
>>>>>>>>> but all seemed to be fine.
>>>>>>>>>
>>>>>>>>> So here are some guesses that come to my mind:
>>>>>>>>> Did you make sure to reload the block list if GRC was already open
>>>>>>>>> by using the respective button on the top or did you restart GRC 
>>>>>>>>> inbetween?
>>>>>>>>> You could also check (assuming you are on linux) if the blocks' XML 
>>>>>>>>> files
>>>>>>>>> are placed in '/usr/local/share/gnuradio/grc/blocks' ? The 'install' 
>>>>>>>>> output
>>>>>>>>> also shows where it copies stuff. After the install, you should also 
>>>>>>>>> do a
>>>>>>>>> 'sudo ldconfig' although this should not keep the blocks from showing 
>>>>>>>>> in
>>>>>>>>> GRC.
>>>>>>>>>
>>>>>>>>> Let me know if there are any further problems!
>>>>>>>>>
>>>>>>>>> Felix
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-03-31 6:25 GMT+02:00 Jordan Johnson <[email protected]>:
>>>>>>>>>
>>>>>>>>>> Exciting! This should help one of my projects along nicely.
>>>>>>>>>>
>>>>>>>>>> Problem is, they blocks do not show up....at all. I am using as
>>>>>>>>>> up-to-date version of GNURadio that is available to pacman. The make 
>>>>>>>>>> goes
>>>>>>>>>> fine, make-test passes with flying colors, and install appears fine 
>>>>>>>>>> too; no
>>>>>>>>>> blocks though.  I attempted to place the blocks in the custom block 
>>>>>>>>>> folder;
>>>>>>>>>> still no dice.
>>>>>>>>>>
>>>>>>>>>> If it helps, packages and their versions:
>>>>>>>>>> gnuradio-3.7.2.1-2
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to