Re: audio sink RuntimeError: audio_oss_sink
See if the settings on this page work - try plughw:0,0 first. https://wiki.gnuradio.org/index.php/Audio_Sink On Thu, Aug 13, 2020 at 6:57 PM aardric wrote: > Hail, > > I am introducing myself to SDR technology and gnuradio through > whatever project documentation I find, dissecting the code and executing > simple experimental flow graphs to test understanding of concepts, > hoping to avoid forum queries (this is my first). Although the audio > sink is not critical to my ultimate use of gnuradio and a bit of a > diversion I will eventually start digging into it. However, I thought to > submit a query on whether there is something obvious I should try in > order to get it working. I am using gnu radio companion 3.8.1.0 (Python > 3.6.10) and feeding the audio sink with a 1 kHz tone from the signal > source block. > > (1) staring with: > :~> aplay -L > null > Discard all samples (playback) or generate zero samples (capture) > default > Default ALSA Output (currently PulseAudio Sound Server) > sysdefault:CARD=PCH > HDA Intel PCH, ALC892 Analog > Default Audio Device > front:CARD=PCH,DEV=0 > HDA Intel PCH, ALC892 Analog > Front speakers > surround21:CARD=PCH,DEV=0 > HDA Intel PCH, ALC892 Analog > 2.1 Surround output to Front and Subwoofer speakers > (...) > hdmi:CARD=PCH,DEV=0 > HDA Intel PCH, HDMI 0 > HDMI Audio Output > hdmi:CARD=PCH,DEV=1 > HDA Intel PCH, HDMI 1 > HDMI Audio Output > hdmi:CARD=PCH,DEV=2 > HDA Intel PCH, HDMI 2 > HDMI Audio Output > hdmi:CARD=PCH,DEV=3 > HDA Intel PCH, HDMI 3 > HDMI Audio Output > hdmi:CARD=PCH,DEV=4 > HDA Intel PCH, HDMI 4 > HDMI Audio Output > > (2) using sysdefault:CARD=PCH for the audio sink device name, > both 44.1 kS/s and 48 kS/s the following runtime error results: > > (3) > gr::log :INFO: audio source - Audio sink arch: oss > audio_oss_sink: sysdefault:CARD=PCH: No such file or directory > Traceback (most recent call last): >File "/gnuradio/examples/audiotest.py", line 136, in > main() >File "/gnuradio/examples/audiotest.py", line 112, in main > tb = top_block_cls() >File "/gnuradio/examples/audiotest.py", line 78, in __init__ > self.audio_sink_0 = audio.sink(samp_rate, 'sysdefault:CARD=PCH', True) >File > "/usr/local/lib64/python3.6/site-packages/gnuradio/audio/audio_swig.py", > line 220, in make > return _audio_swig.sink_make(*args, **kwargs) > RuntimeError: audio_oss_sink > > >>> Done (return code 1) > > (4) Fixing this isn't critical and in time I will get to the bottom of > it; the forum query just removes the possibility of an obvious answer > that most everyone else knows about. My guess is that I have to disable > the Pulse audio server. > > > Rick > > > > >
audio sink RuntimeError: audio_oss_sink
Hail, I am introducing myself to SDR technology and gnuradio through whatever project documentation I find, dissecting the code and executing simple experimental flow graphs to test understanding of concepts, hoping to avoid forum queries (this is my first). Although the audio sink is not critical to my ultimate use of gnuradio and a bit of a diversion I will eventually start digging into it. However, I thought to submit a query on whether there is something obvious I should try in order to get it working. I am using gnu radio companion 3.8.1.0 (Python 3.6.10) and feeding the audio sink with a 1 kHz tone from the signal source block. (1) staring with: :~> aplay -L null Discard all samples (playback) or generate zero samples (capture) default Default ALSA Output (currently PulseAudio Sound Server) sysdefault:CARD=PCH HDA Intel PCH, ALC892 Analog Default Audio Device front:CARD=PCH,DEV=0 HDA Intel PCH, ALC892 Analog Front speakers surround21:CARD=PCH,DEV=0 HDA Intel PCH, ALC892 Analog 2.1 Surround output to Front and Subwoofer speakers (...) hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output hdmi:CARD=PCH,DEV=2 HDA Intel PCH, HDMI 2 HDMI Audio Output hdmi:CARD=PCH,DEV=3 HDA Intel PCH, HDMI 3 HDMI Audio Output hdmi:CARD=PCH,DEV=4 HDA Intel PCH, HDMI 4 HDMI Audio Output (2) using sysdefault:CARD=PCH for the audio sink device name, both 44.1 kS/s and 48 kS/s the following runtime error results: (3) gr::log :INFO: audio source - Audio sink arch: oss audio_oss_sink: sysdefault:CARD=PCH: No such file or directory Traceback (most recent call last): File "/gnuradio/examples/audiotest.py", line 136, in main() File "/gnuradio/examples/audiotest.py", line 112, in main tb = top_block_cls() File "/gnuradio/examples/audiotest.py", line 78, in __init__ self.audio_sink_0 = audio.sink(samp_rate, 'sysdefault:CARD=PCH', True) File "/usr/local/lib64/python3.6/site-packages/gnuradio/audio/audio_swig.py", line 220, in make return _audio_swig.sink_make(*args, **kwargs) RuntimeError: audio_oss_sink >>> Done (return code 1) (4) Fixing this isn't critical and in time I will get to the bottom of it; the forum query just removes the possibility of an obvious answer that most everyone else knows about. My guess is that I have to disable the Pulse audio server. Rick
GNU Radio Project Mission Statement -- Looking for Your Thoughts!
GNU Radioers, as the GNU Radio project matures, we're going to spend some time evolving the actual organization behind it. We'll keep you posted on updates on that, but as a first step, we'd like to define the mission statement of the GNU Radio organization. When people think of GNU Radio, they usually think of the code itself. And that's OK, our code is our prime asset, our crown jewel. Our own website describes it as such: """ GNU Radio is a free & open-source software development toolkit that provides signal processing blocks to implement software radios. It can be used with readily-available low-cost external RF hardware to create software-defined radios, or without hardware in a simulation-like environment. It is widely used in research, industry, academia, government, and hobbyist environments to support both wireless communications research and real-world radio systems. """ The GNU Radio project is more than that, though. We run a conference, we work with industry, academia, students, hobbyists, governments to do all sorts of things: Be part of SDR research, be part of education, do education ourselves. and so on. As opposed to the GNU Radio code, we are looking to formulate a succinct mission statement for the GNU Radio Organization itself. Basically a paragraph or two that describes our purpose. We have some thoughts, but we would like to ask this open-ended question to everyone here to hear your input. If you would like to see other organization's mission statements, the KDE e.V. is a similar organization (albeit much bigger). You can find their purpose in their statutes: https://ev.kde.org/corporate/statutes/ (however, I deliberately didn't paste it here for those who want to think about it. Why are we doing this? Well, as I said, we're trying to grow the organization itself. A mission statement is a very useful tool when engaging in partners (e.g., when we're trying to insert GNU Radio into a publicly funded project), sponsors, or educational institutions. And maybe we'll create an actual organization, or e.V. of our own where we'll need this anyway. We're interested to hear your thoughts and ideas! Cheers, Martin
GSoC 2020: gr-dpd - New BlogPost for Week 10
Hello Community! I have updated the new blogpost for last week's work. Here is the link: https://grdpd.wordpress.com/2020/08/14/week-10-synchronisation-changes-and-gain_phase_calibrate-improves/. Major Week Highlights are: * Synchronised Passing of the 'taps' * Updated gain_phase_calibrate block Upcoming Week Tasks: * Updating the documentation to make gr-dpd module user friendly and easy to understand for newcomers. * Updating the predistorter block to enable both static and training mode operation. Regards, Alekh Gupta NIT Hamirpur
Re: real time voice communication by CPFSK
Thank you for your reply. In my environment, an audio underrun occurred with or without "Throttle". However, updating Ubuntu to 20.04 and gnuradio to 3.8.1.0 solved the problem. It's not perfect yet, but it's a step forward. Thank you and best regards, Hiroki 2020年8月11日(火) 19:26 Marcus Müller : > Hi 相良洸希, > > First of all, if you are still setting things up, now would be a perfect > time to upgrade to Ubuntu 20.04, which brings GNU Radio 3.8, which is > better than 3.7.13.4. > > This sounds like an interesting project! > > I have a couple of observations: > > 1. NEVER use a "Throttle" in the same flowgraph as a hardware sink. > You're running into the two-clock problem, where the Throttle block > internally uses a different rate than your soundcard. Maybe simply > removing the Throttle solves the problem! > > 2. Your English is a pleasure to read, no need to apologize for it > > Best regards, > > Marcus > > PS: Instead of Ruby-forum, I recommend using the official mailing list > archive: > > https://lists.gnu.org/archive/html/discuss-gnuradio/2015-01/msg00158.html > > Ruby-forum just takes the mailing list archive, and displays it as "web > forum", which it really is not, and that has led to very much confusion > in the past. > > On 11.08.20 08:26, 相良洸希 wrote: > > Hello! > > > > I am challenging real time voice communication by CPFSK. > > > > I am creating a flow graph like the one in the photo and testing it, but > > the audio is intermittently played due to audio underrun. > > > > > > I am new to GNUradio and I don't know the cause and solution. What is > > wrong? And is my approach correct? > > > > > > For the time being, I tried changing the buffer size of alsa with > reference > > to this, but it could not be resolved. (I was able to play only when > > samples/symbol=1) > > > > > > > > > > The environment is Ubuntu 18.04 and gnuradio is 3.7.13.4. > > > > > > I'm sorry for my poor English. > > > > thank you for reading! > > > >
