Hello Marcus. I've haven't copy pasted! I made it from a tutorial and it will work on Window 10 machine. :-)
Now i have tried your suggestion and the RuntimeError is till persist. But you lost min the part, about moving the resampler in front of WBFM. I did it and the Runtime error is still presentet.But i'm sure that there is a bug in the debian versin of GNU Radio Companion 3.7.5 when using Rationel Resampler. It's making no sense. I have understood the concept of Decimating and Interpolation. I now have done some test with exactly the same simple setup on Windows 10 and RPi 3 Jessie.
On Windows: Souce: resample 480 k Waveform: Cosine, Freq: 1k-> Rationel Resampler: Decimation 480 (= 1000), Interpolation 48 (=48.000) -> Audio Sink: Sample Rate: 48k It will produce a tone of 1 KHz. Doing precise the same on RPi 3: RuntimeError: audio_alsa_sink Only when Rationel Resampler is set to: Interpolation 48000,It will run, but if Decimation is 480 (= 1000 -> 1000 * 48000) it will sound like a metronome! If i'll set it as it should be: Decimation: 4800 (=1000) and Interpolation: 48 (48 * 1000 = 48 KHz)
It will throw RuntimeError: audio_alsa_sink.I've tried many different settings Rationel Resampler and if Interpolation is not set to 48000, it will create and RuntimeError.
If i do the test on windows with:Source: sample rate: 48k -> Rationel Resampler: Interpolation: 1, Decimation: 1 -> Audio Sink
It will work and procuce 1KHz tone. Doing the same on RPi 3: And it throws a RuntimeError. If I then change Rationel Resampler: Interpolation 48000 It will run without RuntimeError and with no sound! So i'll think this is not about a copy / paste error. All block used in these test, are with the same Types float 32.So i'm quit sure that is something wrong with the Rationel Resampler block i RPi - Jessie version.
Best regards Robin. Den 19-02-2017 kl. 20:39 skrev Marcus Müller:
*high five*, got it to work! So, why the rational resampler?! makes no sense, especially since both interpolation and decimation need to be integers; since it doesn't make sense mathematical, is it possible you did something slightly different on Windows? Resamplers are *only* necessary to convert a signal from one sampling rate to another mathematically, without changing the signal's content. The rate change is interpolation/decimation. If your original signal is already at the right sampling rate, adding a resampler in between will only *break* things. The RuntimeError has something to do with how you configure the audio sink. so, you need to use exactly the same config, ie. 2 inputs, hw:0, sampling rate 48000. It doesn't come from having the wrong kind of resampling before that. GNU Radio blocks really don't care at all about what happens upstream. They get a series of numbers they process. There's no reason for multiple resamplers. Please take this as a constructive criticism: You must stop using a copy and paste approach, and go for an understanding-based approach. So let's work from the ends: We know we have an audio sink that we need to run at 48000 as sampling rate, and in the end, we'll need to connect that to a RTL source that gives us 2 MS/s. So in total, from source to sink, we need a resampling ratio of 2e6/48e3. I'll do it the boring way here, by using a prime factorization of both, to figure out how we can group these: 2e6 = 2 · 10⁶ = 2 · (2·5)⁶ = 5⁶ · 2⁶ 48e3 = 48 · 10³ = 3 · 16 · (2·5)³ = 3 · 2⁴ · 2³ · 5³ = 5³ · 3 · 2⁷ Let's divide these two numbers so that we know what our overall resampling ratio is: 2e6/48e3 = (5⁶ · 2⁶)/(5³ · 3 · 2⁷) and cancelling out everything that's possible to cancel 5³ / (3 · 2) So what we need is a decimation of 5³ = 125 and an interpolation of 6. Awesome! Let's make that happen. We know that we have at least one block that we need to use between RTL source and Audio sink: the WBFM receive. Let's plug that directly into the Audio Sink. That means we know its output rate, because it *must* be the 48k that said audio sink consumes. Ok, let's see, we need to decimate by 5³ in total, so let's put the "Audio Decimation" to 5 here. That leaves us with still 5² to decimate, and 6 to interpolate. (we also can directly calculate that the *input* of the WBFM receive must be 5 · 48kS/s = 240 kS/s). And since we have two channels on our audio sink, connect the both Audio sink inputs to the one autput of WBFM receive. Well, then, let's do that: add a rational resampler that has decimation = 25 and interpolation = 6. Connect its output directly to WBFM receive, and its input to the RTL source. Done! Best regards, Marcus On 19.02.2017 19:42, Robin A. Jensen wrote:Hello again. Now i've a little test. Signal Source: sample rate: 48k, Waveform: Cosine, freq: 1k amplitude: 1 -> Audio Sink: Samp_rate: 48 k, Devicename: hw:0 (with 2 inputs) And that is a succes! There a sound. It will only run with 48k as sample rate. So now we know there are an output for real. :-) But if i put in Rationel Resampler: Interpolation: 1 / 48k, Decimation: 1 and Source is 48k. There is no sound..?? No mather how i fidle around with the values. I've tried with different settings for the Sampler and also Rationel Resampler Base, with no change regard to the output. I find it really strange as the Rationel Resampler is working on a Windows 10. I then whent back to my WBFM setup and remove the resampler and run it direcly from WBFM to Auduo Sink, and then the RuntimeError came back :-( Best regard Robin. Den 19-02-2017 kl. 18:06 skrev Marcus Müller:Hi Robin, Progress! (and you really don't have to try anything in lower- AND uppercase. the names are simply case-sensitive, so use them **exactly** like aplay -L lists them. Everything else can't work. There's really no magic involved here! Stop googling stuff that you copy and paste. You've got a discrete problem on *your* machine, and you can solve it, so copy and pasting device strings that work on other people's computer's is really not that helpful.)It returns: check topology failed on on audio_alsa_sink(8) using ninputs=1, noutputs=0Now that means you're using a device it can find. so: yeah, we're doing something right. I'd really recommend you stick with "pulse", as that will make sure of mixing all the audio streams other programs produce together with yours and you'll not compete for exclusive access to the audio device. It *should* give you at least the same check_topology error. Can you please confirm that? Best regards, Marcus On 19.02.2017 16:42, Robin A. Jensen wrote:Hey Marcus. Have tried that. In documentation for the block: pulse , hw:0,0 , plughw:0,0 , surround51 , /dev/dsp I've tried every single one of them with lowercase and upper case. If i use: hw:0,0 It returns: check topology failed on on audio_alsa_sink(8) using ninputs=1, noutputs=0 If I use: HW:0,0 It returns: RuntimeError: audio_alsa_sink. I've also tried with: HW:0,1 , HW:1,0 , HW:0.1 , HW:1.0 also in lower case. I've been tried to google with different search terms with no luck. That's why I ended up on this mailing list. GNU Radio is downloaded from rpi Jessie repository with apt-get install gnuradio. Best regards Robin. Den 19-02-2017 kl. 16:25 skrev Marcus Müller:Hm, that looks like there's no HW in the list, so that would be an initial debugging success! So, the easiest is probably if you just use "pulse" in the Device Name field. Best regards, Marcus On 19.02.2017 16:15, Robin A. Jensen wrote:Yes of course. Here we go: aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server sysdefault:CARD=ALSA bcm2835 ALSA, bcm2835 ALSA Default Audio Device dmix:CARD=ALSA,DEV=0 bcm2835 ALSA, bcm2835 ALSA Direct sample mixing device dmix:CARD=ALSA,DEV=1 bcm2835 ALSA, bcm2835 IEC958/HDMI Direct sample mixing device dsnoop:CARD=ALSA,DEV=0 bcm2835 ALSA, bcm2835 ALSA Direct sample snooping device dsnoop:CARD=ALSA,DEV=1 bcm2835 ALSA, bcm2835 IEC958/HDMI Direct sample snooping device hw:CARD=ALSA,DEV=0 bcm2835 ALSA, bcm2835 ALSA Direct hardware device without any conversions hw:CARD=ALSA,DEV=1 bcm2835 ALSA, bcm2835 IEC958/HDMI Direct hardware device without any conversions plughw:CARD=ALSA,DEV=0 bcm2835 ALSA, bcm2835 ALSA Hardware device with all software conversions plughw:CARD=ALSA,DEV=1 bcm2835 ALSA, bcm2835 IEC958/HDMI Hardware device with all software conversions If i use @: speaker-test -f 800 -t sinus -r 48000 -c 1-s 1 I'll get a fine sinus tone. So there are sound through the system. Best regards Robin. Den 19-02-2017 kl. 15:48 skrev Marcus Müller:You're right, we should tackle this more systematically. My problem is that I don't have a RPi3 to play around with at hand, so I have to trust you on the "HW:0,0"; it's not a very typical string, through, as most alsa device names are lowercase. Could you share the output of "aplay -L" with us? Best regards, Marcus On 19.02.2017 15:16, Robin A. Jensen wrote:Hello Marcus. Thanks for your reply and your welcomming to the community. I've made the changes as suggested. Also i've made a setup on a Windows 10 machine, to ensure the script runs. With the changes the sound is much better! :-) But when i run the same setup on RPi 3 / Jessie-distro i've end up with the same result, no matter what I do with the Audio sink. I'm using Gnu Radio Companion 3.7.5 The error code is still: ALSA libpcm.c2239:)snd_pcm_open_noupdate) Unknown PCM HW:0,0 <-- 10 times this line gr::log :ERROR: audio_alsa_sink0 - [HW:0,0]: No such file or directory. File "/home/pi/radio/top_block.py", line133, in <module> tb= top_block() File "/home/pi/radio/top_block.py", line82, in __init__ self.audio_sink_0 = audio.sink(48000, "HW:0,0", True) File "/usr/lib/python2.7/dist-packages/gnuradio/audio/audio_swig.py", line 195, in make return _ausio_swig.sink_make(*args, **kwargs) RuntimeError: audio_alsa_sink I know is alwayes is eassy to blame the software, but could it be a bug? As i said. i've tried with all the suggested lines from documentation of the block. Best regards Robin. Den 18-02-2017 kl. 18:17 skrev Marcus Müller:Hi Robin, first of all: Welcome to the GNU Radio community! On 02/18/2017 05:29 PM, Robin A. Jensen wrote:Hello all of you. I've just recieved my RTL-SDR dongle and is all new to this sdr-stuff, so please bear over with me, if i'm at the wrong place. I'm using GNU Radio Companion on a RPi 3 and no mather what i'll do, i can't get the sound to work. If a'im using rtl_fm and aplay, i'll get sound but it won't set on the radiostation.aha, so that's good, the sound system as it does work. You'll probably want to use "aplay -L" to find the possible ALSA device names that you can use in the GNU Radio Audio sink.I'll take on that later. I've createt a small FM Reciever in GNU Radio companion and everytime i'll execute the script i'll get an error: RuntimeError.audio.alsa.sinkHm, I've never seen a GNU Radio error being printed like this; but that might just be me. However, I can't reproduce this error printing shape as hard as I try.I've been all over the internet to find a solution but with no luck. So now i'm have a hope that this mailling list can help me?My suspicion is that your audio device doesn't like the sampling rate your trying to use, or you need to specify a device name (or both). Can you make things work on the PC you use to design these flow graphs? I'd start with a signal source (sampling rate == the sampling rate that you set in your Audio sink), configured to produce a "float" output sine of 1 kHz, directly connected to an Audio sink. If that works, move on. -------------------------------------------------------------------------------- What I say about the flow graph in the following has, as far as I can tell, nothing to do with the error you're getting. Still, there's mistakes in the flow graph that would make it impossible to successfully run it, and thus I'd like to avoid frustration later on by pointing them out know: So, the main issue with your flow graph is that the sampling rate at the audio sink must be what you configured your audio sink for (48 kHz). But: that rate is the result of your SDR's sampling rate (2MS/s), multiplied with all interpolations, divided by all decimations in the path between.My setup is: RTL-SDR Source: samplerate: 2M, frequency 96.5 MHz -> Rationel Sampler: Interpolation 4, Decimation: 1 ->Uh, that means that you have now 8MS/s. That seems unnecessary, since to capture a <100 kHz wide FM channel, you wouldn't even need the 2MS/s you getLow Pass Filter: Sample rate: 2M, Cutoff freq: 100K, Transition Width: 100k ->Which contradicts the 2MS/s used here, so you're actually getting 400kHz passband width, 400kHz transition width. Also, this feels like a prime candidate for including decimation in the filter (because the resulting bandwidth is 200 kHz (if you overlap the two transition widths), and for that you'd only need 200 kS/s of complex digital signal).WBFM Recive: Quadrature: 500K, Audio Decimation: 1 ->This is now off by a factor of 16; are you sure you should be using "interpolation=4,decimation=1" instead of the inverse?Rationel Sampler: Interpolation: 500Certainly not :) 8 MS/s · 500 = 4 GS/sDecimation: 48Aside from that not even having greatest common denominator of 1 with 500 (you can't know that this is important, not blaming you), this would give you an output sampling rate of 4GS/s/48 = 1 GS/s / 12 = 83.333 MS/s. Which isn't even a multiple of 48 kHz, which you use in the audio sink:-> Audio Sink: Sample Rate: 48 KHz, Device Name: HW:0,0 I've found that recipie on a Hack5 video and there it's workingI think there's some error in the way you configured these resamplers. I don't know the Video you're referring to, but the amount of rational resamplers used here alone, paired with the fact that you don't decimate in the WBFM receiver makes me kind of suspicious this might not have been the optimal video to take reference designs from! -------------------------------------------------------------------------------- Best regards, MarcusWith best regards Robin. _______________________________________________ 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 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 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 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 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
