I've completed my contribution. It modifies several GNU Radio in-tree
packages.
Expectations:
As described here:
http://gnuradio.4.n7.nabble.com/how-to-implement-auto-correction-of-sample-rate-in-flow-graph-tp45268p45337.html
with difference about correction method (see result).
- sources and sink
posted partial bugfix to github (pull request #122)
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Bug-gr-qtgui-wrong-design-of-variable-type-blocks-for-GRC-category-GUI-Widgets-QT-tp45538p45543.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_
I faced with buggy behavior of 'QT GUI Label' in my GRC graph and
surprisingly found that GRC generates code making prohibited accesses to qt
gui objects from non-gui thread context. I'm not python guru, but I doubt
that python is smart enough to detect access to qt objects from different
threads a
Hi Marcus,
Everything you said I'm already thought about during last days and finally
came to conclusion, that buffer estimation model is the only reliable (it
solves issue directly by its nature) and universal one (many drivers provide
required functions in their API). Since it involves control l
Hi Marcus,
> your citing that thread of 2010 clearly shows you still didn't get the
> problem. Point being: If your source has a different speed than your
> sink, you'll need resampling in Software. This has nothing to do with
> synchronizing. I won't further elaborate on this.
I don't unders
After several days of hard work I figured out what's wrong, and finally
realized how this task should be solved properly. I generalized it in such
way, that it could solve similar problems experienced by anyone who
connecting multiple hardware clocked blocks in single graph (aka, "The
two-clock pro
Oops, seems I'm misunderstanded scheduler behavior. Since each block works in
its separate thread, I just need do blocking in work() function and adjust
max number of output items in my source block ? But there are still problem
with input data jitter. How much time work() function is allowed to bl
I have external device streaming data at fixed sample rate and my GNU Radio
source block for this device, which feeds flow graph containing some
hardware sink operating at same sample rate (e.g. audio sink). My
source-device and that sink-device (e.g. soundcard on PC) aren't
synchronized, i.e. they
> You exactly reproduced what I was trying to say -- the problem is most
> probably that GNU Radio uses the audio device as if it was an actual
> audio device. But it's not. The virtualization breaks the "easy to
> achieve" real-time needed for audio playback.
> Therefore more buffering is nec
> You already proposed a workaround - use a network sink. It jumps
> through a fraction of the loops to get your audio out of the VM into
> your host.
I used purely VM-internal network (loopback interface). Experiments with
network and 'Delay' block clearly demonstrate simple lack of buffering
Martin Braun (CEL) wrote
> If you *directly* connect audio source to sink, you can run into the
> problems you describe -- depending on the backend (my intuition says,
> Jack would handle that better than ALSA, haven't tried).
Yes, I made several experiments, and problem exists only when they co
> As I told you before: That's plainly not true.
> There are a lot of flowgraphs that have both hardware sources and sinks.
> Why your's not working is a mystery to me, because, seriously, audio
> sample rates should pose no problem for a moderately capable PC,
> unless you do something compli
Btw, this restriction frustrating. Someone would like to make useful graph
containing both audio source and sink in single chain, but it's impossible
due to current GNU Radio design.
I think it would be better to implement such scheduler which do
synchronization itself (using software generator or
I realized what's the problem !!! Enlightenment has come accidentally :D
Block performing blocking calls based on time calculations can't schedule
processing correctly, if there are other blocking calls present in cycle. In
other words, two blocks disturb each other, and no matter whether they
tim
> Yes. GNU Radio is a buffered streaming architecture, so as long as the
> production / consumption rates are equal on average, it should work.
> If they vary over time or really differ, then you'll end up with
> over/underruns
This is exactly the problem. Rates are equal, but there are over
>> No, it's just ambiguous terminology. How should we call blocks producing
>> output synchronously with some reference source ?
> We call them 'source block'.
OK.
>> If I'm not user, but also I'm not developer, who am I then ? ;)
>> I reviewed this "developers-internal" document already and
Thank you for fast answer.
Martin Braun (CEL) wrote
> There's an overview of the scheduler:
> http://gnuradio.squarespace.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html
> "Users", as you say, usually don't need more than this to write GNU
> Radio code, and most often don't need to know
Last few days I tried to implement RTP stream source block (based on
sync_block) and found that this simple task is not trivial, as it seems to
be, because GNU Radio scheduler and general data flow are not documented
(for users).
What mecahisms are allowed to be used in order to achieve producing
Current guide
(http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows)
missed one important note, which is non-trivial and cause such unexperienced
users as me to waste a lot of time and nerves fighting obscure DLL
ImportError failures !
On PyQT dependency should be noted, that *you
I've installed GNU Radio from binaries on my Windows machine exactly as
described in
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows
guide. (I used specified versions except some packages which was not
available). After two days of hard fighting this dll hell, I was able to r
20 matches
Mail list logo
